Search results matching tags 'SSMS' and 'DBA'

Tools and Processes for “Fitting it all in”

BuckWoody — Mon, 18 Jan 2010 14:42:05 GMT

Most data professionals I’ve met work in two modes: we plan for our day, and we react to the situations around us. I’m staring at my list of things that I need to do today right now, which is my planned work. Of course, I have no idea how much of that will really get done – it’s optimistic to be sure. On the other hand I have several systems I manage, and at any moment one of them or the people that interface with them may “change state” such that I need to give them some attention.

So how do I meld the two? Sometimes it can be quite difficult. I’m constantly working through my list in my mind, re-arranging what I’m focusing on based on what I perceive as the highest need. There are, however, some tools that I use each day to help me manage the workflow.

I use Outlook for tracking everything, since it has a task list (my primary tracking), a calendar, mail and so on. Also I can share the information, it’s on-line so I can see it anywhere, and I can even take it offline onto the plane this week when I fly out of town.

For the “ad-hoc” work, I rely on a script library, which I keep as SQL Server Management Studio projects. I keep those scripts and projects backed using Microsoft Live Mesh, which synchronizes those files (along with a few other critical files and my IE Favorites) across not only my laptop and primary systems, but even with my Virtual Machines.

Also for my SQL Server systems I use the Standard Reports I’ve blogged about here. I also use Greg Larsen’s Database Dashboard, and a series of PowerShell scripts that work across my systems, alerting me to any problems. Of course I’m using SQL Server Agent Jobs quite a bit, and I also use Alerts and some Perfmon automation for my monthly baselining.

So – is this your experience as well? Do you get driven by both planned and unplanned work? What tools and processes do you use to keep it all straight with your SQL Server Instances?

Wizards are evil – wait, no they aren’t!

BuckWoody — Mon, 14 Dec 2009 15:55:00 GMT

SQL Server contains many “Wizards. Wizards are simply programs that collect information based on user choices. The Wizard’s screens explain each step and the choices on that screen. Based on those answers collected from the user, the Wizard performs some task. What could possibly be wrong with helping a user this way? Well, plenty.

Wizards hide complexity from the user, which can prevent them from learning the process behind the Wizard. Wizards can also enable the user to choose the wrong options too easily – especially if the user doesn’t read the screens.

For instance – in the example that’s always mentioned, the Maintenance Wizard, the screens present not only “Shrink Database” (which you should never do) but it presents both REBUILD and REORGANIZE options for the Indexes. Of course, Microsoft isn’t sure which you need to do, but some users select both – which isn’t necessary.

And then from time to time there’s a bug in the code and the Maintenance Wizard doesn’t work properly. For this reason, some experts have recommended that we remove all of the Wizards.

But I don’t agree. I think Wizards have their place – given two conditions. Number one, they always need to work. And number two, the users need to read the options carefully so that they make the right choices. The Wizards do a good job of making sure the process can be scripted, and many of them drop you off (like the Maintenance Wizard) with a package that can be changed later. So don’t give up on the Wizards. Let’s fix them. In fact, tomorrow I’ll talk about an idea brewing in my head, and it involves actually increases the number of Wizards!

Code that Writes Code

BuckWoody — Wed, 25 Nov 2009 14:01:40 GMT

I have scripts that re-create my databases for testing and development purposes. But sometimes I want to take the data from a set of tables and move it as well – I could use SSIS, or a SELECT INTO statement, but what if I want to “re-set” the data to a point in time? In other words, load it with some “base data”?

I thought this might be a good place to demonstrate “code that writes code”. No, it isn’t that big of a deal – most DBAs know how to do this, but in the interest of those who don’t, I thought I would share.

So the end result I want in this case is to have a bunch of INSERT statements that contain my base data from a table where that data already exists. I could script out the table from SSMS and use the replacement parameter feature to fill out each record individually:

I have a table in one of my databases that I right-clicked to show the INSERT statement:

-- Person

INSERT

INTO [WAVS].[dbo].[Person]

([PersonName]

,[Street]

,[CityStateZip]

,[PersonType])

VALUES

(<PersonName, varchar(150),>

,<PersonStreet, varchar(100),>

,<PersonCityStateZip, varchar(255),>

,<PersonPersonType, varchar(100),>)

I can use the CTRL-SHIFT-M keys to replace the VALUES part with the values I want.

But I already had a copy of that “base” data before I turned the database over to the testers. Before I give it to them, I run code like this on each table – this one is for the Person table above (note that there should only be two lines here):

SELECT

'INSERT INTO [WAVS].[dbo].[Person] ([PersonID], [PersonName], [Street], [CityStateZip], [PersonType]) VALUES (' + CAST([PersonID] AS VARCHAR(5))+ ', ''' + [PersonName]+ ''', ''' + [Street]+ ''', ''' + [CityStateZip] + ''', ''' + [PersonType] + ''')'

FROM

[WAVS].[dbo].[Person]

When I run this code, I get these statements:

INSERT INTO [WAVS].[dbo].[Person] ([PersonID], [PersonName], [Street], [CityStateZip], [PersonType]) VALUES (1, 'Buck Woody', '123 Here Street', 'Covington, WA 98042', 'Vet')
INSERT INTO [WAVS].[dbo].[Person] ([PersonID], [PersonName], [Street], [CityStateZip], [PersonType]) VALUES (2, 'Jane Doe', '231 Function Ave', 'Redmond, WA 98052', 'Vet')
INSERT INTO [WAVS].[dbo].[Person] ([PersonID], [PersonName], [Street], [CityStateZip], [PersonType]) VALUES (3, 'Diane Wilson', '34251 Appt 3 7th Street', 'Seattle, WA 98061', 'Vet')
INSERT INTO [WAVS].[dbo].[Person] ([PersonID], [PersonName], [Street], [CityStateZip], [PersonType]) VALUES (4, 'John Kelso', '89734 Country Lane', 'Covington, WA 98042', 'Farmer')
INSERT INTO [WAVS].[dbo].[Person] ([PersonID], [PersonName], [Street], [CityStateZip], [PersonType]) VALUES (5, 'Marjorie Christian', '9893452 Changein Lane', 'Maple Valley, WA 98072', 'Farmer')
INSERT INTO [WAVS].[dbo].[Person] ([PersonID], [PersonName], [Street], [CityStateZip], [PersonType]) VALUES (6, 'Joanne Lister', '98904 Mapelwood Drive', 'Spokanne, WA 98045', 'Zoo Worker')

All I have to do is copy those statements into my “initialization” scripts just after the table creations, and then I can run them at will to create my new database (I know I can take a backup – I have reasons for not doing that).

There are two keys for writing code that writes code: The first is to simply use the single tick (') to write out what the end code should say (INSERT INTO, in my case) and then to use multiple ticks (''') when you want the code to contain the ticks themselves. This “escapes” the characters so that you can embed them. If you use SSMS to write your queries, the color coding will look as mine does above. You’ll also need to remember to CAST or CONVERT any data types that don’t concatenate (+) together well. In my case I had to CAST an integer value – but that’s OK, since it is only printing to the screen and I don’t include the ticks, the INSERT works fine.

You can use this method not only with INSERTS, but with lots of operations. And you can also even fire off the code once you create it – but that’s another post :)

Changing the Primary Key After You Have Data

BuckWoody — Tue, 24 Nov 2009 13:25:22 GMT

Yesterday I blogged about changing a Primary Key (PK) during the design phase, and before you have data in the database. Even then, it’s not trivial to change the data type or column(s) that make(s) up the PK. When you have data in that Primary Key and/or you have Foreign Keys (FK) that point to a PK field, this becomes a much more involved process.

First, you MUST take a complete backup of the system, and you MUST do this work on a development system. You’re going to be manipulating base data, and in the worst kind of way. Why do I say that?

There are three kinds of data problems. One is physical data corruption, and once you restore it (I don’t trust repair with data loss) then you know where the “good” data stops and starts. You know that the FKs are pointing to the right PKs, and that the data is readable.

The second kind of data problem is “incorrect” entry, meaning that you put in “Buck Woodie” when you meant “Buck Woody”. This is also often correctable, as your Declarative Referential Integrity (DRI) will still keep that record together. It’s a simple matter to locate and correct.

But the third kind of data problem is the worst. In this kind, the FKs point to the wrong PK, or not at all. Or perhaps some of the FK data is missing. The reason this is the worst is that the data cannot be trusted – did Buck Woody really pay for that purchase or was that payment from a different record? If the links are incorrect, everything will look fine, but it won’t be correct.

So in the situation where you want to change the PKs when you already have data, one of the steps is to re-point the FKs to the proper PKs. Get this wrong and you’ll have “dirty data”. The only recourse there is to restore the backup and start over.

I’m assuming that you have a REALLY GOOD reason to make this change, and that you’ve taken that backup and you’re on a test system. As Hannibal Lector would say: “Okeedokee – here we go.”

I’ll describe two possible choices. In the first, understand and document the PK and FK relationships for each table. Then create queries that tie out the INSERTS for that data in the correct order, and include all fields for both tables, including the PKs in the parent table and the FKs in the child tables.

With those INSERT statements made, drop the PK and FK constraints on all of the tables using the script I mentioned yesterday. Make your change to the data type (or field) in the tables. Then edit the INSERT statements to have the new value types, ensuring that the “sets” or records are kept together by keeping the FK’s pointing to the right PKs. Then re-apply the PK and FK constraints, watching for errors. With backups and scripts, you can make corrections along the way.

The second method works much as the first, with the exception of using the INSERT statements. You can use SSIS or a third-party transfer process to actually move the data and change the data type or values “in flight”, although this requires more thought and planning in my experience.

In any case, you should test the results thoroughly and ensure that you’re getting the data you expect. Communicate what you’re doing, and be ready to fall back to your backups at the first sign of trouble.

Oh – since SQL Server 2005, you’ve been able to “relax” constraints to insert data. That won’t help you here, since you’re changing the entire key for whatever reason. That’s only meant to allow you to get data in when the key doesn’t change.

OK – feel free to comment on this post, since there are other ways I didn’t cover. But if you’re reading my material or any of the comments, make sure you test it yourself – I might have missed something, no one is perfect, your situation may vary. Once again, you can see why I value a good design and ERD so highly – that way you never have to get here to begin with!

New Features Announced In SQL Server 2008

andyleonard — Thu, 13 Mar 2008 10:23:00 GMT

Buck Woody, Microsoft SQL Server Program Manager, recently posted a list of enhancements in the works for SQL Server 2008 RTM in the SQL Server MVP newsgroup. The usual suspects were included in the list: Policy-Based Management (formerly DMF), Resource Governor, Multi-Server Query, PowerShell, and IntelliSense - but there are also some interesting additions that I'd not heard about until reading his post.

The big addition: Activity Monitor, described in the post thus:

The new Activity Monitor was written from the ground up with the perspective of the DBA needing to chase down a performance problem in real time. Modeled after the new Windows Resource Monitor, DBAs can quickly see the active sessions, wait states, file I/O, and long running queries in a command console like UI.

I'm excited! I currently lug around a collection of scripts (... that I keep promising to add to an application one day) to check hither and yon for performance gotchas.

Another addition: Database Diagram / Table Designer Safety Additions which add safety checks "for operations that that would drop an object or cause data loss."

You will also be able to launch Profiler "from a Query Editor Results window to the SPID of the query." This sounds very interesting. If I'm reading this right I'll be able to execute sp_who2, obtain the SPID of a long-running query, right-click (or something) and start a Profiler trace pre-configured to capture activity of this SPID. You can also launch the SPID-centric Profiler from Activity Monitor. I will be using that a lot!

New right-click options in the Query Results Window will allow users to "select a range of rows in the Results Grid and copy the headings as well. Also, you can select individual cells and copy them with headers if you wish." This sounds like the copy functionality we have in SSIS Grid Data Viewers. I can tell you from expereience this is handy feature. It's very useful to be able to copy a few multi-selected rows - including row headers (especially when you're working with a couple hundred columns!) - and paste them into Excel for analysis.

A new "Info Bar" provides pre-validated navigation cues in many screens.

The Open Table feature limits the number of rows returned. Has this ever happened to you? You right-click a table in SSMS and select Open Table only to hog server resources just so you could take a peek at the data? It's happened to me... (Thank you, thank you, thank you!)

There are also a few changes to ShowPlan - mostly related to XML / graphics interchange. I remember seeing some of this in early SQL Server 2005 pre-releases but I believe it was cut from the 2005 RTM. Nice to see these options - they're great for documenting issues.

Performance Studio will contain a host of performance tuning reports - another exciting feature! The whole Data Collection database has me stoked - have you seen this feature in CTP6? It's pretty cool.

Last but not least, the team has decided to include - drum roll please - the T-SQL debugger in SSMS!

I can hardly wait to see these in action, and it's very cool of the SQL Server Team to give us visibility into these planned features along with permission to blog about them (thanks Buck!).

:{> Andy