Don’t Upgrade In Place

I briefly considered doing an in-place upgrade. But as I have never done one before, I thought that just maybe an upgrade from 2008 to 2008 R2 would be simple enough to give it a go. I did some reading and talked with my MCM colleagues at SQL Solutions Group (SSG) and the recommendation was unanimous: Don’t do an in-place upgrade.

If for any reason the upgrade fails, you may be left with an instance that won’t come on-line and the rollback is arduous. If the upgrade fails, your best recourse is to restore your system from a full system state backup. Often an upgrade will make changes to the system databases so a restore is in order there as well. As with all the options discussed herein, planning for all contingencies is paramount. Upgrading in place is tempting, but just don’t do it.

How could a remote DBA managed service from

SQL Solutions Group free up technical personnel to

focus on bottom-line projects that impact ROI? Find out. 

So, that left me with choosing from one of the ‘industry standard methodologies’ to migrate SQL Server instances. Which methodology to use is often a matter of preference and/or your specific circumstances.

Methodology #1

Stop access to the source database server, then backup all the databases and copy the full backups to the target and restore them there. This is an easy way to go if you have the downtime. If you have a large amount of data, however, the time becomes prohibitive. You must back up the databases, copy the backups over to the new server, and then restore the databases thereon. Any one or all of these steps can takes hours. I have performed this method successfully several times, but my total data space for all the databases was under 100 GB.

Methodology #2

Stop access to the source database server, detach the databases from the source and attach them to the target. Similar to methodology #1, this is easy if you have the downtime. You detach the databases on the source, copy the .ldfs and .mdfs to the target and reattach. Detaching and attaching the databases is much quicker than backup and restore. But, your copy of the files will take longer since you lose the compression you get with the backups.

Methodology #3

Take one last full backup of all the databases on the source instance and recover them to the target using NORECOVERY. It is important that these are the last full backups since the intent is to complete the recovery using the DIFF backups. If you must create another full backup, make sure to use the ‘copy only’ option so as not to break the backup chain. Do not stop access to the source database during this portion of the migration. When it is time to perform the migration, stop access to the databases and take DIFF backups on the source server and restore the DIFFs on the target. This greatly minimizes the downtime compared to methodologies #1 and #2 because the DIFF backups will be a fraction of the size of the full backups.

Methodology #4

Setup log shipping from the source to the target, and then make the target the master and stop the log shipping. This offers the least amount of downtime but is also the most amount of setup time. To be honest, I have never migrated a server this way, but I know people have done it.

So those were my options when I started preparing to upgrade the 2008 server to 2008 R2. I immediately eliminated methods 1 and 2 because the amount of data was much larger than the downtime window would permit. Since this is an upgrade, Method 4 would not work as the source and target instances need to be of the same version of SQL Server. My choice was pretty obvious, the only option left was method 3…or so I thought.

I was working with the system admins to build the virtual machine that was to become the ‘target’ database server when Methodology #5 popped into my head:

Methodology #5

Shutdown SQL Server on the source instance, move the LUNs from the old server to the new server and attach the databases there. Fast and easy with little downtime if you have done all your setup properly prior to this step (of course). This only works if you are using a SAN and the new database server is on the same SAN.

Maybe this is not a new idea but it was new to me. In all the ‘How To Migrate a SQL Server Instance…’ articles I have read, not one of them mentioned this methodology as an option. I am sure I am not the first to come up with this plan, but it was nothing short of a revelation for me.

Author’s note: I have since talked to other seasoned professionals, and methodology #5 is not a new idea. No surprise there, but it was new to me. I figured that makes it worth blogging about, since maybe it is new to you! 🙂

So, what is involved in preparing the target server for the migration? 

Migration Considerations

Migrate the system databases? If you are not doing an upgrade to a different version of SQL Server, you may choose to copy the system databases from the source server to the target. It is a matter of personal preference whether to copy the system databases or to create them anew. I have heard arguments for and against both options. Regardless, this is not an option in my scenario so I will not delve into that here. A reasonably good step-by-step can be found here.

So, since we are not migrating the system databases, we must make sure that we copy all the pertinent objects from the source system databases to the new.

Create the new server

Create the new server with the same disk configuration as the old one. This is not required and may not be viable, but it is much easier if you can stick with the old configuration. You will have to alter your attach script to reflect the new configuration.

Move the new system databases

Move the new system databases where you want them to reside in the future if you did not create them there during installation. They do not have to reside in the same location as the old ones. If they are on the same drives as your databases, make sure to have a copy of the .mdf and .ldf for each so you can move them back into place once you attach the new LUNs.

Recreate logins

There are numerous tools for this process, but the oldest way to do it is to use sp_help_revlogin. This stored procedure provided by Microsoft for this very purpose has been around since SQL Server 7 (possibly 6.5?) and is still used today. It copies all the logins and passwords and recreates them with the same SID they had on the old machine. Here is the Microsoft support page.

Copy the following by scripting them out on the old instance:

• User defined Stored Procedures and Functions in master. You may possibly have some in model and msdb, so make sure to check and script those as well if needed.
• Permissions on system databases. This is often overlooked, but don’t forget that you may have specific permissions granted on some or all of the stored procedures and functions.
• Linked Servers. Script these out on the old server and recreate them on the new. Remember that scripting of linked servers will not script the passwords. You will need to obtain these and put them in the script manually.
• The easiest way (in my opinion) to do this is to within SSMS. Simply highlight the jobs you want to move over (ctrl-A if you want them all) and right click on the top one and select ‘Script Job as…’
• DB Mail. Make sure to write down your DB Mail settings on the old server so you can activate it on the new server. (Again, the Microsoft technet page is above…and here for convenience).

Or if you like some scripts for DB Mail, go here.

Create a script

Create a script for attaching all the databases on the new server. Here is a script I wrote for creating an attach script. It assumes that the databases will be in the same location as they were on the old server. Run this on the old server (in text mode) and it will create the attach script.

Follow The Script

Source code

USE master; GO SET NOCOUNT ON IF OBJECT_ID( 'tempdb.dbo.#tmp' ) IS NOT NULL DROP TABLE #tmp; DECLARE @SQLcmd VARCHAR(MAX) ,@DatabaseName VARCHAR(255) ,@PrevDatabaseName VARCHAR(255); SET @SQLcmd = ''; SET @DatabaseName = ';'; SET @PrevDatabaseName = ''; CREATE TABLE #tmp ( DatabaseName SYSNAME NULL ,FileId INT NULL ,FileName VARCHAR(2000) NULL ,SQLcmd VARCHAR(MAX) NULL ); INSERT  INTO #tmp SELECT DISTINCT DB_NAME(dbid) AS DatabaseName ,FileId ,FileName ,CONVERT(VARCHAR(MAX), '') AS SQLcmd FROM master.dbo.sysaltfiles WHERE dbid IN ( SELECT dbid FROM master.dbo.sysaltfiles WHERE SUBSTRING(FileName, 1, 1) IN ( 'G', 'F' ) )  -- Put the appropriate drives here --AND DATABASEPROPERTYEX(DB_NAME(dbid), 'Status') = 'ONLINE' AND DB_NAME(dbid) NOT IN ( 'master', 'model', 'msdb', 'tempdb', 'ditribution' ) ORDER BY DatabaseName, FileId, FileName; UPDATE #tmp SET @SQLcmd = SQLcmd = CASE WHEN DatabaseName <> @PrevDatabaseName THEN CONVERT(VARCHAR(200), 'exec sp_attach_db @DBName = N''' + DatabaseName + '''') ELSE @SQLcmd END + ',@FileName' + CONVERT(VARCHAR(10), FileId) + '=N''' + FileName + '''' ,@PrevDatabaseName = CASE WHEN DatabaseName <> @PrevDatabaseName THEN DatabaseName ELSE @PrevDatabaseName END ,@DatabaseName = DatabaseName FROM #tmp; SELECT 'USE master;' + CHAR(13) + CHAR(10) + 'GO' SELECT SQLcmd FROM ( SELECT DatabaseName, MAX(SQLcmd) AS SQLcmd FROM #tmp GROUP BY DatabaseName ) AS SQLcmd; --DROP TABLE #tmp GO

If you plan on moving the databases to different drives you can easily modify this script to change the attach location.

One Last Important Consideration

When the mdfs and ldfs are connected to the new database instance, they will be upgraded to the new version. This action cannot be undone. If a rollback situation occurs, you cannot simply move the LUNs back to the old server and reattach. Your only option here is to restore the databases you took prior to the upgrade. Before you begin the actual migration, create and save final backups of the databases on the old server.

I suggest you make a FULL backup of all the databases several hours before you block access to the SQL Server instance. As with methodology #3 above, make sure these are the last full backups taken. Then make one last DIFF backup and save them all (fulls and diffs) in a safe place. It is probably a good idea to have a restore script for all the databases pre-defined so that you are not scrambling to recover if this scenario presents itself. Keep in mind that any transactions incurred on the new server will be lost unless you take steps to find the data differences and import them back.

That’s all I have to say about that. This is by no means a complete step-by-step plan to migrate SQL Server, but hopefully it helps in your quest for the seamless migration.

The post A Faster Way to Migrate SQL Server Instances! appeared first on SQL Solutions Group.

If you follow industry trends at all, or if you have been in the situation where you were attempting to hire an experienced DBA, you no doubt are aware of the shortage of qualified DBAs. If not, take a look at these articles: Looming DBA Shortage and DBAs in high demand. The statistic that really caught my eye was in this article, Why DBAs are in Demand from careerbuilder.com, which states, “there are only 14 active candidates for every 100 jobs posted.”

If that doesn’t denote a shortage, I don’t know what does. That leads to an essential question: What is a DBA worth? A shortage like this would tend to give candidates an incredible amount of leverage, and skew salaries higher.

So I was perplexed by a situation that I recently witnessed first-hand at one of my clients. This particular client has been looking to fill two DBA positions (one senior and one intermediate level) for more than six months. They identified a really good senior candidate who wanted the job. I know she was very good because I was involved in the interview process. All they had to do was make her a decent offer and she’d be in. It didn’t happen. While I am saddened that they wouldn’t meet her salary requirement (a reasonable number, all things considered), I am glad she stuck to her guns and didn’t take less than she was worth.

To further confuse their decision not to hire her over a difference of a few thousand dollars, consider this client’s history with DBAs. They’ve had a string of poor to bad DBAs over the last several years. Most recently (six months ago) they had two DBAs I will call Clueless-Inexperienced DBA and Lazy-I’m-too-good-for-this place DBA. Clueless DBA was fired after repeated lapses in judgement that caused large amounts of data loss, and Lazy DBA quit shortly thereafter knowing that she was on the verge of being fired herself.

So along comes the new candidate I’ll call Quality DBA with 10+ years of experience in SQL Server and a proven history of success. And what does the hiring organization do? They let Quality DBA walk because of salary.

Consider this as well: I have been working as the DBA at this client since the demise of Clueless and Lazy, and I have spent a great deal of time fixing this, tweaking that, tuning all of the above, and generally doing all of those things that a DBA is supposed to do. Current status: All the systems are stabilized; all the jobs complete every night; user requests are completed in a timely fashion. None of those things were true before, and I am only contracted for 30 hours a week. Am I some kind of superhero DBA?

I wish. No, I am just a trained, experienced DBA doing what a good DBA is supposed to do. I discussed this with the client and they agreed: I convinced them that what they needed was one really good Sr. DBA rather than two less-than-good DBAs. So… big savings AND a stable, well-managed environment if they would just hire Quality DBA. Slam dunk right? Nope! Arrgh!

I have no statistics to back it up, and I haven’t performed an extensive study, but my personal experience tells me this kind of shortsightedness is happening at many companies around the country (U.S.) and perhaps the world.

So the question that comes up is: Why is this happening?

In my opinion, this is happening because:

• There are people outside of the IT department, namely the Human Resources Department (HR), making salary decisions based on market averages.
• The “market averages” are inconsistent and confusing. I researched averages in my local area and found numbers for a DBA ranging from $80K to $115K (salary.com, indeed.com). Unfortunately the decision makers will see $80K and decide to use that number, or perhaps go even lower.
• The “market average” salaries are for “average” employees. In the situation above, they had two average DBAs making average DBA wages, when all they need is one good DBA.
• To further that thought, DBAs are not doing a good enough job of selling themselves. HR says, “The average salary is…”. The DBA should reply “That’s for an average DBA. Is that really who you want securing your data? I’m not an average DBA, I can do a better job than that.”
• IT managers don’t really understand what a DBA does or how important they are to the company. If they don’t know, how are they going to convince HR?
• We as a community are not doing a good enough job of educating upper management as to what we do, why it matters, and helping define what a DBA is worth. We seem to be happiest when nobody knows what we are doing or why.

These are my opinions and observations, and I am very interested to hear yours. Please reply with your thoughts and if you have any suggestions how we can all work to improve the situation, please tell us that too!

The post What is a DBA Worth? appeared first on SQL Solutions Group.

Could you unplug here?

I’m not complaining. Really, I’m not. I am enjoying my vacation despite the work interruptions. I might be whining a little bit (just a little), but I’ve made my own choices. I could easily get a job making less money at a place where little or no on-call is required. I’ve had jobs like that before. I also knew when I made the career choice to jump from developer to DBA that I was stepping into the wonderful world of IT support.

All that said, I still reflect on the best vacation I’ve ever had. I took an Alaskan cruise with my wife and kids. An hour after leaving port all signal to my phone was gone. It was long enough ago that there was no WiFi on the boat, so I was completely unplugged. I turned off my phone, put it in my suitcase, and for seven blissful days I was completely unencumbered with thoughts of work and other worldly concerns. It was reminiscent of the ‘70s. No pager, no mobile phone, no emails, no text messages, no Twitter, no Facebook. Talk to me when I get back. It was awesome.

There are thousands of articles (here is one) on the Internet that discuss the mental, physical, creative, and regenerative benefits of an unplugged vacation, so I won’t regurgitate that here. But, a survey by the U.S. Travel Association found that 40% of Americans are not taking all the vacation time they earn. The survey says that there are many reasons for this, ranging from fear that they will be viewed as a less than dedicated employee to an over-inflated sense of self importance, a.k.a. “Nobody else can do what I do!” Unfortunately there are times when there is more truth to this than there should be.

For instance, I mentioned above that I worked on a client’s system this last week during my vacation. Well, this particular client had both of their DBAs leave the company in the last few months, and, as it turns out, I am actually the only person currently employed at the company who can do what I do. Also, many of us have had bosses who, whether they intend to or not, make you feel like you are being disloyal if you take the vacation that is your due.

So the question is: how do we—the collective “we” known as IT support—unplug and take a real vacation? Can we? I believe the answer to this is yes, we can. However, we have to want it and we have to work at it. If we wait for the company we work for to make it happen, unless we work for a small number of progressively thinking companies (like this one), it is not likely to happen.

Here are some suggestions that may help:

• • Schedule your vacations well in advance. Let everyone know that not only will you be on vacation, but you will be mostly unavailable. Some may have heartburn over this, but stick to your guns as much as possible. Let them know it is important to you.
  • Cross train: Make sure there is somebody else to do what you do when you are not there. We tend to have projects and/or responsibilities that are “ours.” We take ownership and we are often not very good at sharing. Get over it, give it up, and make sure somebody else at your organization can take it over. Sooner or later you’re going to move on and somebody else will have to take it anyway. If you are the sole DBA, see if you can get the company to train a system admin or two on basic DBA tasks like backups and disk space management. This will require documentation on your part.
  • Talk to your boss: As hard as it may be to believe, your boss is a person too! Tell her your desire for some time completely away from your job. Don’t just start complaining and expect her to oblige; go to her with a plan. Show her it can work. Most bosses want you to be happy and will do what they can to work it out.
  • Take small vacations: If it is wholly implausible for you to be unplugged for an entire week, try taking numerous three or four day weekends. You may still have to force the issue to make it happen, but if you can it will be easier to start extending these mini vacations into an entire week.
  • Get lost: Take some vacations in the mountains, or in the desert, or… maybe the South Pole—some place where the answer to the question “Can you hear me now?” is “No.” This will force the issue. If they start talking about getting you a sat phone, look for another job.

I hope you find these suggestions helpful and if you are not already finding ways to unplug you can find a way to do so in the near future. I realize the realities of today’s working environment, but if you don’t give it your best shot, then you’ve got nobody to blame but yourself.

The post Unplug Now! Is it Possible? appeared first on SQL Solutions Group.

The subject for this T-SQL Tuesday is Giving Back. I have been a taker in the SQL community for many years.

In 2012 I went to my first PASS Summit (you know, the year with the nice Ogio bags). I was duly impressed with the quality, quantity, and variety of presentations available for the attendees. I learned so much that I was excited to get back to work (no really, I was excited) so I could implement some of the new things I had learned and fix some of the things I thought I was doing right.

Then I learned that everybody involved was volunteering their time. What? You mean, like, for free? I guess if you had asked me I would have said sure, people at conferences volunteer their time, but these sessions just didn’t feel like the drivel I usually had to endure at conferences. I felt like I had 3 days of awesome training tailored to my needs.

So, what to do? I realized that if all these people were willing to give of their time for my edification, shouldn’t I do the same for others (assuming I had anything worth giving)? How do I become a SQL evangelist like those that I now idolized? The answer was simple: Start small. I started by sharing my new-found knowledge and enthusiasm with my peers. I shared websites and scripts and…well, anything I could think of.

Then I found where and when the local PASS chapter was meeting and started attending regularly. After I felt comfortable in the group, I volunteered to present at some of the monthly chapter meetings. I was rough at first, but then I got better. This last year, I presented at four different SQL Saturdays, 1 local, and the rest out of state. I am finally giving back.

A watershed moment for me this past year was when a director from another department came over and gave me a hand-written note (with a little treat, yum!). The note said how much they appreciated my help and attention to detail, but what they appreciated the most was the mentoring that I provided. Wow! That stayed on my wall for months!

So what do I have planned for this next year? Well, to put it plainly, more, more, MORE of the same. I have already offered to help in the administration of the local PASS chapter (enthusiastically accepted). I also plan on volunteering to present at more SQLSaturdays this year (maybe 8?). My eventual ‘lofty’ goal is to present at PASS Summit, but I don’t want to get ahead of myself.

I am also blogging more regularly and trying to come up with topics that will help others (I always learn more than anybody when I write them). I am sure other things will present themselves to me and hopefully I will have the time to accept the challenge. Fortunately I have a boss who supports me!

The post T-SQL Tuesday #61– Giving Back! appeared first on SQL Solutions Group.

‘Twas the night before the upgrade, when all through the place
Not a backup was working, “there’s not enough disk space”;
The software was compiled and packaged with care,
In hopes that some QA was actually done there.

I called the PM and he proceeded to shout,
“You’re the DBA, you figure it out!”
When out of the lunchroom there arose such a clatter,
I sprang from my chair to see what was the matter.

I ran to the door and what did I see,
The developers having a potluck, they didn’t invite me.
They had smartphones and tablets of every shape and size,
They were typing and texting and avoiding each other’s eyes.

And then I saw the manager, he smiled at me wanly,
I was really kind of irritated that he sat there so calmly.
He was chubby and plump, kind of an ugly old toad
And I laughed when I saw him, this guy was a load.

I told him the problem, but he didn’t seem to care
I incited a response by giving him a glare.
“What’s the problem?” he asked, “I heard it was clustered!”
I said “I’m talking ketchup and you’re talking mustard.”

He scratched his bald head and looked around confused,
I was amazed he could breathe, so little brain being used.
I quickly turned away before I began to snigger,
I still had a problem to fix and it was only growing bigger.

I returned to my desk, I had one more play,
I called the sys admins to see what they’d say.
Their response was expected, they said “It’s a bummer,”
“We won’t have more disk space until sometime next summer!”

As much as I tried, it was plain to see,
That the person to fix this was clearly going to be me.
So donning my rarely seen grumpy DBA face,
I put up my sign “Need help? This isn’t the place!”

I began searching for files I could readily delete,
Hopefully a process I could repeatedly repeat.
I searched and searched, I poked and prodded
Looking for files that were useless and rotted.

Finally I found it, a folder full of crap
That didn’t belong there, I could delete it in a snap.
There were pictures and videos and documents aplenty,
By my last count there were 14,520.

The files were ancient, 7 or 8 years, some older,
I could with a clear conscience delete the whole folder.
I opened a picture to see what was there,
I saw a familiar face, but in those days he had hair.

Right click “delete” and the folder was demolished,
I’d done a good job, one more apple polished.
I looked in the trash bin, the folder I detected
I emptied it quickly so it couldn’t be resurrected.

I dashed to the lunch room to find my bald friend
To give him the sad news of his folders unfortunate end.
But it was he that was laughing when my story was done
There was a twinkle in his eye, he was really having fun.

He said, “Oh man you’re in trouble, you’re now cannon fodder,
Those pix are the CEO’s, I married his daughter!”
So I returned to my desk to pack up my stuff,
This fateful night was over, I’d already had enough.

As I walked out the door, you could clearly hear me say,
“To all a good night, here’s a copy of my updated résumé.”

The post ‘Twas the night before the upgrade… appeared first on SQL Solutions Group.

This is the second installment in a continuing series of articles on things to look for and change that will help your query optimizer perform at its best.  If you missed part one, you can read it here.

Okay, now that you know about trusted vs. non-trusted check constraints, let’s talk about foreign keys. What are foreign keys? They are another type of constraint, right? Just like check constraints, if they are not handled correctly the query optimizer will stop trusting them. The scenario is similar to check constraints but is, in my experience, more prevalent and usually has a greater negative impact.

Non-Trusted Foreign Keys

How many times have you been attempting a large data load, and to speed things up you disabled the foreign keys?  Data loads are much faster if it doesn’t have to keep checking each row for referential integrity (RI), right? Or, more likely is the scenario that you’ve found that you can’t load the data because something is contrary to the foreign key constraint. Just disable that pesky FK and now you can load the data no problem. Re-enable the foreign key(s) and voilà, everything works. Isn’t that convenient? Well, just as with check constraints, this scenario causes the query optimizer to no longer trust the foreign key. Just as with check constraints, if you disable a foreign key and don’t use the WITH CHECK option when you enable it, the foreign key becomes not trusted.

Okay, maybe you’ve never done this, but I guarantee you it is happening all over the SQL map. I have yet to find a company that didn’t have a fair number of non-trusted foreign keys in their production environment.

Let’s see what the ramifications are.

Source code

USE AdventureWorks2012;
 
SELECT name, is_not_trusted FROM sys.foreign_keys WHERE is_not_trusted = 1;

Presumably no rows will be returned from this query if you haven’t been messing with your foreign keys in AdventureWorks. Picking a foreign key at random, let’s disable/enable it without the WITH CHECK option:

Source code

-- Break it
 
ALTER TABLE [Person].[Person] NOCHECK CONSTRAINT [FK_Person_BusinessEntity_BusinessEntityID]
 
GO
 
ALTER TABLE [Person].[Person] CHECK CONSTRAINT [FK_Person_BusinessEntity_BusinessEntityID]
 
GO

Enabling the foreign key without the WITH CHECK option will enable the foreign key constraint, but the data will not be verified for integrity.

Source code

-- Check it
 
       SELECT name, is_disabled, is_not_trusted FROM sys.foreign_keys
 
       WHERE name = 'FK_Person_BusinessEntity_BusinessEntityID';

And it should be no surprise that the result is:

The foreign key is no longer trusted by the optimizer. Oops! So if we query the data now, what does the query optimizer do?

Source code

-- Query it
 
SET NOCOUNT ON;
 
       SET STATISTICS XML ON;
 
       GO
 
 
 
SELECT Person.* FROM Person.Person Person
 
       JOIN Person.BusinessEntity be ON Person.BusinessEntityID = be.BusinessEntityID;
 
 
 
       SET STATISTICS XML OFF;
 
       SET NOCOUNT OFF;
 
       GO

The stats and execution plan we generated:

Table 'Person'. Scan count 1, logical reads 3820, physical reads 2, read-ahead reads 3826

Table 'BusinessEntity'. Scan count 1, logical reads 98, physical reads 1, read-ahead reads 96

        SQL Server Execution Times:

        CPU time = 218 ms,  elapsed time = 2785 ms.

Note that there is a scan of both the Person and BusinessEntity tables.

Now, let’s make the foreign key trusted by enabling the foreign key again using the WITH CHECK option:

Source code

 -- Fix it
 
ALTER TABLE [Person].[Person] WITH CHECK CHECK CONSTRAINT [FK_Person_BusinessEntity_BusinessEntityID]
 
GO

The WITH CHECK option will cause SQL Server to check all the data to verify that it does not conflict with the foreign key constraint.

NOTE: If the tables involved are large this may take some time and you may not want to do it during normal operational hours

Source code

-- Check it
 
       SELECT name, is_disabled, is_not_trusted FROM sys.foreign_keys
 
       WHERE name = 'FK_Person_BusinessEntity_BusinessEntityID';

Now the result is:

The foreign key is now trusted by the optimizer. So if we query the data now, what does the query optimizer do?

Source code

 -- Query it
 
SET NOCOUNT ON;
 
       SET STATISTICS XML ON;
 
       GO
 
 
 
SELECT Person.* FROM Person.Person Person
 
       JOIN Person.BusinessEntity be ON Person.BusinessEntityID = be.BusinessEntityID;
 
 
 
       SET STATISTICS XML OFF;
 
       SET NOCOUNT OFF;
 
       GO

The stats and execution plan we generated:

Table ‘Person’. Scan count 1, logical reads 3820, physical reads 2, read-ahead reads 3826

SQL Server Execution Times:

   CPU time = 156 ms,  elapsed time = 2310 ms.

Wow, look at that! The Person table has been completely dropped from the query and there is no merge either. The query optimizer trusted the foreign key and therefore did not have go check the data in the Person table to verify that the data met the criteria.  The difference is visible even in these small tables, it could be significant if these were large tables.

And here is the T-SQL script that will find all your non-trusted foreign keys:

Source code

EXEC sp_MSforEachDB N'
 
USE [?];
 
SELECT fk.name, fk.is_not_trusted, ''Database Table'' = ''?'' + ''.'' + sch.name + ''.'' + obj.name
 
FROM sys.foreign_keys fk
 
JOIN sys.all_objects obj ON fk.parent_object_id = obj.object_id
 
JOIN sys.schemas sch ON fk.schema_id = sch.schema_id
 
WHERE fk.is_not_trusted = 1'

Conclusion

The case for checking your foreign keys for the is_not_trusted flag has been made, and now that you know what the ramifications are, get out there and do it!  You may not be the one causing the problem, but if you’re not the only person working on an instance, somebody WILL disable foreign keys to speed up data loads, or to get around bad data.

The post What the FK? Your Foreign Keys May Not Be Performing Like They Should appeared first on SQL Solutions Group.

It may come as a surprise to you to find out that at its core, the SQL Server Query Optimizer is like a jealous lover. How so? The optimizer doesn’t trust the constraints on your data until you prove to it that your data is trustworthy! Why do you care? Because if the optimizer doesn’t trust your constraints then it feels the need to check the data to make sure it is right. This article discusses how the constraints get on the query optimizer’s bad side, how to find the wayward constraints, what effect having non-trusted constraints has on a query, and how to bring them back into the optimizer’s good graces.

Non-Trusted Constraints

How do your constraints become non-trusted constraints? It’s simple. If you disable a constraint, and then do not specify the WITH CHECK option when you enable it, SQL Server does not check the data to make sure it meets the criteria of the constraint. Some people do this intentionally to enter data into a table that is contrary to the constraint (a bad practice), but more often, they simply did not know to use the WITH CHECK option when enabling. When this happens (intentionally or not), the SQL optimizer no longer trusts your data. Remember, she is a jealous lover (I’m a guy, so I’m going with “she” here). When your data is out of her watchful eye for even just a minute she won’t trust the data again until she can see for herself that the data deserves her trust. Your constraint is branded as untrustworthy… or slightly less dramatically, the constraint is denoted as a non-trusted constraint by the is_not_trusted column in sys.check_contraints = ‘1’.

Let’s look at an example by looking at good ‘ol AdventureWorks to see if you have any non-trusted check constraints.

Source code

USE AdventureWorks2012;
GO
SELECT name, is_not_trusted FROM sys.check_constraints WHERE is_not_trusted = 1;

Presumably, this should return no rows if you haven’t been messing around with AdventureWorks constraints (She will know!). Now let’s disable and re-enable a constraint without the WITH CHECK option.

Source code

ALTER TABLE [Person].[Person]  NOCHECK CONSTRAINT [CK_Person_EmailPromotion]
GO
ALTER TABLE [Person].[Person] CHECK CONSTRAINT [CK_Person_EmailPromotion]
GO
SELECT name, is_not_trusted FROM sys.check_constraints
WHERE name = 'CK_Person_EmailPromotion';

The select now returns:

Well, there you go. Now the optimizer is all up in your query plans (we’ll see those later), checking your data because she no longer trusts that it is consistent. How do we calm her frazzled sensibilities? You guessed it (I hope). We allow SQL Server to check and verify that the data is correct by re-enabling the constraint utilizing WITH CHECK:

Source code

ALTER TABLE [Person].[Person] WITH CHECK CHECK CONSTRAINT [CK_Person_EmailPromotion]
GO

The select now returns:

Note: The WITH CHECK option causes SQL Server to read all the data in the table for the affected column. If the table in question is very large it may take a while, and you may not want to do it on a production server during normal operational hours.

So why doesn’t SQL Server trust the constraint if the data is not checked when you enable it? Because while the constraint is disabled you could enter data that is contrary to the constraint. In the above example, the constraint ‘CK_Person_EmailPromotion’ defines that the column EmailPromotion on the Person table must be >= 0 or <= 2.

Source code

ALTER TABLE [Person].[Person]  WITH CHECK ADD  CONSTRAINT [CK_Person_EmailPromotion] CHECK  (([EmailPromotion]>=(0) AND [EmailPromotion]<=(2)))
GO

So, if you did this:

Source code

ALTER TABLE [Person].[Person]  NOCHECK CONSTRAINT [CK_Person_EmailPromotion]
GO
UPDATE [Person].[Person] SET EmailPromotion = 3 WHERE BusinessEntityID = 1;
ALTER TABLE [Person].[Person] CHECK CONSTRAINT [CK_Person_EmailPromotion]
GO

You would have data in the table that does not comply with the constraint (EmailPromotion = 3). The optimizer is right not to trust your data. If you try to enable the constraint using WITH CHECK now,  it fails.

Now you have to fix the data and then you can enable the constraint using WITH CHECK.

Source code

UPDATE [Person].[Person] SET EmailPromotion = 0 WHERE BusinessEntityID = 1;
 
ALTER TABLE [Person].[Person] WITH CHECK CHECK CONSTRAINT [CK_Person_EmailPromotion]
 
GO

As I mentioned earlier, this has consequences for the optimizer and your query plans. Let’s check it out. If we run the following select statement while the CK_Person_EmailPromotion constraint is trusted (is_not_trusted = 0):

Source code

SET STATISTICS IO,TIME ON;
SET STATISTICS XML ON;
GO
SELECT FirstName, LastName FROM Person.Person WHERE EmailPromotion = 3

We get the following statistics:

SQL Server parse and compile time:

CPU time = 0 ms, elapsed time = 0 ms.

SQL Server parse and compile time:

CPU time = 0 ms, elapsed time = 0 ms.

SQL Server Execution Times:

CPU time = 0 ms,  elapsed time = 0 ms.

And here is the Query Plan.

If we now run the same query while the CK_Person_EmailPromotion constraint is NOT trusted (is_not_trusted = 1), our statistics look like this:

SQL Server parse and compile time:

CPU time = 0 ms, elapsed time = 16 ms.

SQL Server parse and compile time:

CPU time = 0 ms, elapsed time = 0 ms.

Table ‘Person’. Scan count 1, logical reads 3820, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

SQL Server Execution Times:

CPU time = 16 ms,  elapsed time = 11 ms.

And our Query Plan now has an Index Scan in it:

Notice that the 2^nd query with the non-trusted constraint has a clustered index scan with 3820 logical reads. The 1^st query with the trusted constraint has zero logical reads and no index scan. Why? Well, if you remember the constraint stipulated that the value of the EmailPromotion column had to be >= 0 and <= 2. The query is looking for all rows with an EmailPromotion = 3. When the optimizer trusts your constraint it knows that none of the rows will meet that criteria, so it doesn’t even bother to look. However, if the optimizer doesn’t trust your constraint, it has to scan every row to see if any have the value of 3, a value that clearly could be there (since we added one) if the constraint is not trusted. This is a simple example on a small table but you can see where this could be costly on a larger table.

Here is a nice T-SQL script that will find all your non-trusted constraints:

Source code

EXEC sp_MSforeachdb N'
USE [?];
SELECT chk.name, chk.is_not_trusted, [Database Table] = ''?'' + ''.'' + sch.name + ''.'' + obj.name
FROM sys.check_constraints chk
JOIN sys.all_objects obj ON chk.parent_object_id = obj.object_id
JOIN sys.schemas sch ON chk.schema_id = sch.schema_id
WHERE chk.is_not_trusted = 1'

Conclusion

If you’re not checking your constraints for the is_not_trusted flag , you should be. This is especially true if you have developers that have access to your production databases. Developers WILL disable constraints to speed up data loads, or to get around bad data. I like to think that we as DBAs would know better, but I am sure we’ve all done it too (not me!). Now that you know what the ramifications are, get out there and find those wayward constraints and bring them back into the optimizer’s good graces. She won’t be jealous if you are always on the up and up!

The post Query Optimizer Tips and Tricks Part 1: Trusted vs. Non-Trusted Constraints appeared first on SQL Solutions Group.

Source code

USE AdventureWorks2012;
GO
SP_HELPFILE  -- to get the logical file names and current physical file locations
USE master;
GO
SP_DETACH_DB 'AdventureWorks2012';
GO
-- Move the physical data/log files to the new location
SP_ATTACH_DB 'AdventureWorks2012', 'D:\MSSQL\DATA\AdventureWorks2012_Data.mdf','F:\MSSQL\LOG\AdventureWorks2012_log.ldf';
GO

Or you can use the ALTER DATABASE method:

Source code

ALTER DATABASE [AdventureWorks2012] MODIFY FILE (NAME = [AdventureWorks2012_Data], FILENAME = 'D:\MSSQL\DATA\AdventureWorks2012_Data.mdf');
ALTER DATABASE [AdventureWorks2012] MODIFY FILE (NAME = [AdventureWorks2012_Log], FILENAME = 'F:\MSSQL\LOG\AdventureWorks2012_log.ldf')
ALTER DATABASE [AdventureWorks2012] SET OFFLINE
-- Move the physical data/log files to the new location
ALTER DATABASE [AdventureWorks2012] SET ONLINE

Whichever method you prefer, these work great when you are moving databases, especially if just a handful.

But, what if you are moving 120 databases from numerous disk drives which may or may not be well documented? This was the situation we were recently presented with at a customer site where they had acquired new SAN storage that they wanted to utilize. The 120 databases were spread across 7 different disk drives in an undocumented disarray, and a few had already been created on or moved to the new drives. So how to proceed?

First, we built a table that had all the information in it that we needed to do some analysis, and then to generate a move script. What did we need to know?

• What databases are to be moved?
• Where they are currently located?
• Where they are to be moved to?
• How much disk space is required?

So the table needed to have the following information in it for each database:

• Database id
• File id for each database file
• Filename (logical file names)
• Physical Filename
• Original Location (fully qualified physical filename)
• Original directory
• New location
• New directory
• File type (‘ROWS’ = data, ‘LOG’ = logs)
• Size in MB (for each file)
• Database status (read only, offline etc.)

In this real world scenario, the disk locations were predefined by the customer.  If you are given a choice, you would like to put your data, log and tempdb files on disparate disks. Fortunately, the locations provided for this migration met that criteria.

We defined the locations where we wanted to move our database files as follows:

Source code

-- Define the drives you wish to move the data files to. Do not put '\' on the end.
DECLARE	 @systemDBData		VARCHAR(100) = 'G:\MSSQL\SYSTEM_DATA'
	,@systemDBLog		VARCHAR(100) = 'F:\MSSQL\SYSTEM_LOG'
	,@tempDBData		VARCHAR(100) = 'E:\MSSQL\TEMPDB_DATA'
	,@tempDBLog		VARCHAR(100) = 'E:\MSSQL\TEMPDB_LOG' 
	,@userDBData		VARCHAR(100) = 'G:\MSSQL\USER_DATA'
	,@userDBLog		VARCHAR(100) = 'F:\MSSQL\USER_LOG'

We also defined all the disks that we wanted to search for existing database file by creating an array of disks as follows:

Source code

DECLARE	 @fromDrive		TABLE(Drive CHAR(1))
--Insert the Drive(s) You want to check for database files
INSERT INTO @fromDrive (Drive) VALUES ('C'),('D'),('E'),('F'),('G'),('I'),('M')

So now we were ready to gather all the data into our table. Not only does this table provide data for pre-move analysis and to create our move script, but it also provides a log of sorts.

Source code

IF OBJECT_ID( 'DBA.dbo.MOVE_Servername_Log' ) IS NOT NULL DROP TABLE DBA.dbo.MOVE_Servername_Log
SELECT
masterFiles.database_id,
masterFiles.FILE_ID,
db.name AS DatabaseName,
masterFiles.name AS FileName,
RIGHT(masterFiles.physical_name,CHARINDEX('\',REVERSE(masterFiles.physical_name))-1) AS PhysFileName,
masterFiles.physical_name AS OriginalLocation,
LEFT(masterFiles.physical_name,LEN(masterFiles.physical_name) –
CHARINDEX('\',REVERSE(masterFiles.physical_name))) AS OriginalDir,
CASE
WHEN masterFiles.type_desc = 'ROWS' AND db.name IN('master', 'model', 'msdb', 'distribution')
THEN @systemDBData + '\' +
RIGHT(masterFiles.physical_name,CHARINDEX('\',REVERSE(masterFiles.physical_name))-1)
WHEN masterFiles.type_desc = 'LOG' AND db.name IN('master', 'model', 'msdb', 'distribution')
THEN @systemDBLog + '\' +
RIGHT(masterFiles.physical_name,CHARINDEX('\',REVERSE(masterFiles.physical_name))-1)
WHEN masterFiles.type_desc = 'ROWS' AND db.name = 'tempdb'
THEN @tempDBData + '\' +
RIGHT(masterFiles.physical_name,CHARINDEX('\',REVERSE(masterFiles.physical_name))-1)
WHEN masterFiles.type_desc = 'LOG' AND db.name = 'tempdb'
THEN @tempDBLog + '\' +
RIGHT(masterFiles.physical_name,CHARINDEX('\',REVERSE(masterFiles.physical_name))-1)
WHEN masterFiles.type_desc = 'ROWS'
THEN @userDBData + '\' +
RIGHT(masterFiles.physical_name,CHARINDEX('\',REVERSE(masterFiles.physical_name))-1)
ELSE @userDBLog  + '\' +
RIGHT(masterFiles.physical_name,CHARINDEX('\',REVERSE(masterFiles.physical_name))-1)
END AS NewLocation,
CASE
WHEN masterFiles.type_desc = 'ROWS' AND db.name IN('master', 'model', 'msdb', 'distribution')
THEN @systemDBData
WHEN masterFiles.type_desc = 'LOG' AND db.name IN('master', 'model', 'msdb', 'distribution')
THEN @systemDBLog
WHEN masterFiles.type_desc = 'ROWS' AND db.name = 'tempdb' THEN @tempDBData
WHEN masterFiles.type_desc = 'LOG' AND db.name = 'tempdb' THEN @tempDBLog
WHEN masterFiles.type_desc = 'ROWS' THEN @userDBData
ELSE @userDBLog
END AS NewLocationDir,
masterFiles.type_desc AS FileType,
masterFiles.size * 8 / 1024 AS Size_MB,
fdrv.Drive AS FromDrive,
' ' AS ToDrive,
CASE
WHEN DATABASEPROPERTY(db.name,'isReadOnly') = 1 THEN 'isReadOnly'
WHEN DATABASEPROPERTY(db.name,'isOffline') = 1 THEN 'isOffline'
WHEN DATABASEPROPERTY(db.name,'isSuspect') = 1 THEN 'isSuspect'
WHEN DATABASEPROPERTY(db.name,'isInRecovery') = 1 THEN 'isInRecovery'
WHEN DATABASEPROPERTY(db.name,'isInLoad') = 1 THEN 'isInLoad'
WHEN DATABASEPROPERTY(db.name,'isNotRecovered') = 1 THEN 'isNotRecovered'
ELSE 'isAvailable'
END AS DatabaseAvailable
INTO DBA.dbo.MOVE_Servername_Log
FROM sys.master_files masterFiles
JOIN sys.sysdatabases db ON masterFiles.database_id = db.dbid
JOIN @fromDrive fdrv ON LEFT(masterFiles.physical_name, 1) = fdrv.Drive
ORDER BY masterFiles.name
UPDATE DBA.dbo.MOVE_Servername_Log SET ToDrive = LEFT(NewLocation,1)
IF OBJECT_ID( 'DBA.dbo.MOVE_Servername_Log' ) IS NOT NULL DROP TABLE DBA.dbo.MOVE_Servername_Log
SELECT
    masterFiles.database_id,
    masterFiles.file_id, 
    db.name AS DatabaseName,
    masterFiles.name AS FileName, 
    RIGHT(masterFiles.physical_name,CHARINDEX('\',REVERSE(masterFiles.physical_name))-1) AS PhysFileName,
    masterFiles.physical_name AS OriginalLocation,
    LEFT(masterFiles.physical_name,LEN(masterFiles.physical_name) – 
        CHARINDEX('\',REVERSE(masterFiles.physical_name))) AS OriginalDir,
    CASE 
        WHEN masterFiles.type_desc = 'ROWS' AND db.name IN ('master', 'model', 'msdb', 'distribution')
            THEN @systemDBData + '\' + 
            RIGHT(masterFiles.physical_name,CHARINDEX('\',REVERSE(masterFiles.physical_name))-1)
        WHEN masterFiles.type_desc = 'LOG' AND db.name IN ('master', 'model', 'msdb', 'distribution')
            THEN @systemDBLog + '\' + 
             RIGHT(masterFiles.physical_name,CHARINDEX('\',REVERSE(masterFiles.physical_name))-1)
        WHEN masterFiles.type_desc = 'ROWS' AND db.name = 'tempdb'
            THEN @tempDBData + '\' + 
            RIGHT(masterFiles.physical_name,CHARINDEX('\',REVERSE(masterFiles.physical_name))-1)
        WHEN masterFiles.type_desc = 'LOG' AND db.name = 'tempdb'
            THEN @tempDBLog + '\' + 
            RIGHT(masterFiles.physical_name,CHARINDEX('\',REVERSE(masterFiles.physical_name))-1)
        WHEN masterFiles.type_desc = 'ROWS'
            THEN @userDBData + '\' + 
            RIGHT(masterFiles.physical_name,CHARINDEX('\',REVERSE(masterFiles.physical_name))-1) 
        ELSE @userDBLog  + '\' + 
            RIGHT(masterFiles.physical_name,CHARINDEX('\',REVERSE(masterFiles.physical_name))-1) 
    END AS NewLocation,
    CASE 
        WHEN masterFiles.type_desc = 'ROWS' AND db.name IN ('master', 'model', 'msdb', 'distribution') 
            THEN @systemDBData
        WHEN masterFiles.type_desc = 'LOG' AND db.name IN ('master', 'model', 'msdb', 'distribution')
            THEN @systemDBLog
        WHEN masterFiles.type_desc = 'ROWS' AND db.name = 'tempdb' THEN @tempDBData
        WHEN masterFiles.type_desc = 'LOG' AND db.name = 'tempdb' THEN @tempDBLog
        WHEN masterFiles.type_desc = 'ROWS' THEN @userDBData
        ELSE @userDBLog
    END AS NewLocationDir,
    masterFiles.type_desc AS FileType, 
    masterFiles.size * 8 / 1024 AS Size_MB,
    fdrv.Drive AS FromDrive, 
   ' ' AS ToDrive,
    CASE
        WHEN DATABASEPROPERTY(db.name,'isReadOnly') = 1 THEN 'isReadOnly'
        WHEN DATABASEPROPERTY(db.name,'isOffline') = 1 THEN 'isOffline'
        WHEN DATABASEPROPERTY(db.name,'isSuspect') = 1 THEN 'isSuspect'
        WHEN DATABASEPROPERTY(db.name,'isInRecovery') = 1 THEN 'isInRecovery'
        WHEN DATABASEPROPERTY(db.name,'isInLoad') = 1 THEN 'isInLoad'
        WHEN DATABASEPROPERTY(db.name,'isNotRecovered') = 1 THEN 'isNotRecovered'
        ELSE 'isAvailable'
    END AS DatabaseAvailable
INTO DBA.dbo.MOVE_Servername_Log
FROM sys.master_files masterFiles
JOIN sys.sysdatabases db ON masterFiles.database_id = db.dbid
JOIN @fromDrive fdrv ON LEFT(masterFiles.physical_name, 1) = fdrv.Drive
ORDER BY masterFiles.name
UPDATE DBA.dbo.MOVE_Servername_Log SET ToDrive = LEFT(NewLocation,1)

Once the table was created we could do some analysis on how much disk space was being moved to each drive:

Source code

-- Get disk space totals ----------------------------------------------------------
SELECT ToDrive, CASE FileType WHEN 'ROWS' THEN 'DATA' ELSE FileType END AS FileType, SUM(size_MB) AS MBPerDrive
    FROM DBA.dbo.MOVE_Servername_Log
    WHERE FromDrive != ToDrive
    GROUP BY ToDrive, FileType
UNION
SELECT ToDrive, 'All' AS FileType, SUM(size_MB) AS MBPerDrive
    FROM DBA.dbo.MOVE_Servername_Log
    WHERE FromDrive != ToDrive
    GROUP BY ToDrive
UNION
SELECT '---- Total' AS ToDrive, 'All' AS FileType, SUM(size_MB) AS MBPerDrive
    FROM DBA.dbo.MOVE_Servername_Log
    WHERE FromDrive != ToDrive
ORDER BY ToDrive DESC,FileType DESC

Once the analysis was done, we were ready create our move script. Since we were moving both system and user databases, we wanted to script and move them separately.  We decided to use the ALTER DATABASE method rather than the DETACH/ATTACH method described above. So, for the system database files, the commands would be as follows:

Source code

ALTER DATABASE [master] MODIFY FILE (NAME = master,
    FILENAME = 'G:\SQL_MDF_SYSTEM_DATA\master.mdf' )
ALTER DATABASE [master] MODIFY FILE (NAME = mastlog,
    FILENAME = 'F:\SQL_LDF_SYSTEM_DATA\mastlog.ldf' )

Then shutdown SQL Server, copy the physical files to the new locations, and restart SQL Server.

IMPORTANT: Before moving any database files, make sure that the SQL Server Services login has permissions in each of the directories.

The user databases will be similar but rather than taking SQL Server down, you take each of the databases offline, move the physical files, then bring the databases back online. You may have to create or download a script for killing connections, but that is not provided here.

Source code

ALTER DATABASE [AdventureWorks2012] MODIFY FILE (NAME = [AdventureWorks2012_Data], FILENAME = 'G:\SQL_MDF_DATA\AdventureWorks2012_Data.mdf' )
ALTER DATABASE [AdventureWorks2012] MODIFY FILE (NAME = [AdventureWorks2012_Log], FILENAME = 'F:\SQL_LDF_DATA\AdventureWorks2012_log.ldf' )
ALTER DATABASE [AdventureWorks2012] SET OFFLINE

For the script creation, we created a temporary table with database name, sort order (so commands display in correct order), and the actual script command. Also, we wanted to script out the robocopy commands for the physical moves, so we defined a log file:

Source code

-- Define the location and name of the robocopy log
DECLARE	 @robocopyLog		VARCHAR(100) = 'G:\MSSQL\robocopy.log'

The script was built as follows:

Source code

-- Build System DB move script ------------------------------------------------------------------------
INSERT INTO ##Script(Sort,Script) VALUES (0,'--------- Begin System Database Move Script ---------------')
 
INSERT INTO ##Script(DatabaseName, Sort,Script)
    SELECT DISTINCT DatabaseName, 1,'    ALTER DATABASE ' +  QUOTENAME(DatabaseName) + ' MODIFY FILE (NAME = ' + FileName + ', FILENAME = ''' +  NewLocation + ''' )'
    FROM DBA.dbo.MOVE_Servername_Log
    WHERE OriginalLocation <> NewLocation
        AND DatabaseAvailable = 'isAvailable'
        AND database_id <= 4
 
INSERT INTO ##Script(Sort,Script) VALUES (2,'-----------------------------------------------------------')
INSERT INTO ##Script(Sort,Script) VALUES (3,'-- COPY Physical files. Run the following commands in a CMD window. Run as Administrator!')
INSERT INTO ##Script(Sort,Script) VALUES (4,'-----------------------------------------------------------')
INSERT INTO ##Script(DatabaseName, Sort, Script)
    SELECT DISTINCT DatabaseName, 5,'    robocopy "' 
        + OriginalDir + '" "' 
        + NewLocationDir + '" "' 
        + PhysFileName + '" /COPYALL /NJS /LOG+:"' 
        + @robocopyLog + '"'
    FROM DBA.dbo.MOVE_Servername_Log
    WHERE OriginalLocation <> NewLocation
        AND DatabaseAvailable = 'isAvailable'
        AND database_id <= 4
 
INSERT INTO ##Script(Sort,Script) VALUES (6,'------------------- End System Script ---------------------')
-- END Build User DB move script -----------------------------------------------------------------------
 
-- Build User DB move script ---------------------------------------------------------------------------
INSERT INTO ##Script(Sort,Script) VALUES (7,'------------ Begin User Database Move Script --------------')
 
INSERT INTO ##Script(DatabaseName, Sort,Script)
    SELECT DISTINCT DatabaseName, 8,'    ALTER DATABASE ' +  QUOTENAME(DatabaseName) + ' MODIFY FILE (NAME = [' + FileName + '], FILENAME = ''' +  NewLocation + ''' )'
    FROM DBA.dbo.MOVE_Servername_Log
    WHERE OriginalLocation <> NewLocation
        AND DatabaseAvailable = 'isAvailable'
        AND database_id > 4
 
INSERT INTO ##Script(DatabaseName, Sort,Script)
    SELECT DISTINCT DatabaseName, 8,'    ALTER DATABASE ' +  QUOTENAME(DatabaseName) + ' SET OFFLINE'
    FROM DBA.dbo.MOVE_Servername_Log
    WHERE OriginalLocation <> NewLocation
        AND DatabaseAvailable = 'isAvailable'
        AND database_id > 4
 
INSERT INTO ##Script(Sort,Script) VALUES (9,'-----------------------------------------------------------')
INSERT INTO ##Script(Sort,Script) VALUES (10,'-- COPY Physical files. Run the following commands in a CMD window. Run as Administrator!')
INSERT INTO ##Script(Sort,Script) VALUES (11,'----------------------------------------------------------')
INSERT INTO ##Script(DatabaseName, Sort, Script)
    SELECT DISTINCT DatabaseName, 12,'    robocopy "' 
        + OriginalDir + '" "' 
        + NewLocationDir + '" "' 
        + PhysFileName + '" /COPYALL /NJS /LOG+:"' 
        + @robocopyLog + '"'
    FROM DBA.dbo.MOVE_Servername_Log
    WHERE OriginalLocation <> NewLocation
        AND DatabaseAvailable = 'isAvailable'
        AND database_id > 4
 
INSERT INTO ##Script(Sort,Script) VALUES (13,'----------------------------------------------------------')
INSERT INTO ##Script(Sort,Script) VALUES (14,'-- Bring the databases back online.')
INSERT INTO ##Script(Sort,Script) VALUES (15,'----------------------------------------------------------')
INSERT INTO ##Script(DatabaseName, Sort, Script)
    SELECT DISTINCT DatabaseName, 16,'    ALTER DATABASE ' +  QUOTENAME(DatabaseName) + ' SET ONLINE'
    FROM DBA.dbo.MOVE_Servername_Log
    WHERE OriginalLocation <> NewLocation
        AND DatabaseAvailable = 'isAvailable'
        AND database_id > 4
 
INSERT INTO ##Script(Sort,Script) VALUES (17,'--------------------- End User Script --------------------')
-- END Build User DB move script -----------------------------------------------------------------------

Now that the script has been created in the ##Script table, you can extract it by running the following SELECT statement to a text output in SSMS:

Source code

SELECT Script
FROM ##Script
ORDER BY Sort, DatabaseName, Script

So in conclusion, moving multiple databases is not difficult if the task is approached with caution and plenty of forethought. The scripts and details defined herein provide one methodology for completing the task, but ultimately it is up to you to choose how you want to make this move. As always, proceed with caution!

The post Moving Databases to New Drives: A Real-world Case Study Involving 120 Databases appeared first on SQL Solutions Group.