SQL Server Tacklebox- P19 doc

Figure 3.19: Setting up initial restore of secondary database for Log Shipping.. 3 – The migratory data The next and final, "Restore Transaction Log", tab is very important.. You will wa

Figure 3.19: Setting up initial restore of secondary database for Log Shipping

Figure 3.20: Setting up Copy Files options for Transaction Log Shipping

3 – The migratory data

The next and final, "Restore Transaction Log", tab is very important This is where you set the database state to either "No Recovery" or "Standby" mode You will want to use Standby mode if you are planning on using the target database as

a reporting database, while still allowing subsequent logs to be applied The other important option is "Disconnect users in the database when restoring backups", seen in Figure 3.21 Without this important option, the log restore would fail because the database would be in use

Figure 3.21: Checking Standby Mode and Disconnect Users

Once all of the backup and restore options are set, you can choose whether or not you want to use the log shipping monitoring service Essentially, this is an alerting mechanism in case there are any issues with the log shipping process I do not typically set up the monitoring service, though it may be useful in your

Figure 3.22: Log Shipping setup completed

With log shipping setup and configured for Standby mode, you have conquered two very important DBAs tasks:

• Separating source data from transaction data for reporting to reduce the risk of contention with online processes on production

• Assuring a secondary backup of the source data in case there is disaster

As I mentioned earlier, however, there are downsides to log shipping, such as the difficulty in creating indexes on the target and assigning specific permissions to users (both hard to do when the database is read only)

There is one final trick I will leave you with for log shipping and security You can assign a login and user on the source, so that the user is created in the database, and then delete the login on the source but not the database user Next, create the login on the target system, preferably a Windows account which will always sync

up login to user If it is a SQL authenticated account you are trying to align on the target, you will need to insure that the account Security ID (SIDs) are the same This is where you will want to use the ultra-handy sp_help_revlogin stored procedure (http://support.microsoft.com/kb/246133) Because user permission assignment is a logged transaction in the source database, it will move with the next log restore and the user and login on the target system will align Thus, you have no access on the source and the access you desire on the target

3 – The migratory data

Summary

In this chapter, we covered several tools that will facilitate the migration of data from a source to a target, or multiple targets Data is moved for several reasons, the main ones being either for Disaster Recovery, High Availability, or to offload reporting from the source to increase performance of an application There are as many reasons to move data as there are ways and means Fortunately, you and I,

as DBAs, can make informed decisions that will ultimately equate to cost savings for the companies we work for Speaking of saving money, the next chapter is devoted to storing all of this migratory data It is sometimes challenging to capacity plan for new projects, and even more challenging, as your SQL infrastructure grows, to force adherence to standards that would mitigate many storage issues I will show you how I try to do this daily, in the next compartment

of our SQL Server tacklebox

C HAPTER 4: M ANAGING DATA

GROWTH

When I look back over my career as a SQL Server DBA, analyzing the kinds of issues that I have had to resolve, usually under pressure, nothing brings me out in

a colder sweat than the runaway data, log or TempDB file I would estimate that for every time I've had to deal with an emergency restore, including point in time restores using transaction log backups, I've probably had to deal with a hundred disk capacity issues Overall, I would estimate that such issues account for around 80% of the problems that a DBA team faces on a weekly basis

Occasionally, the cause of these space issues is just poor capacity planning In other words, the growth in file size was entirely predictable, but someone failed to plan for it Predictable growth patterns are something that should be analyzed right at the start, preferably before SQL Server is even installed In my experience, though, these space issues are often caused by bugs, or failure to adhere to best practices

In this chapter, I'll delve into the most common causes of space management issues, covering model database configuration, inefficient bulk modifications, indexes and TempDB abuse, and how to fix them I will finish the chapter by describing a query that you should store securely in your the SQL Server

tacklebox, SizeQuery I use this query on more or less a daily basis to monitor

and track space utilization on my SQL Server instances Used in conjunction with the DBA repository to query multiple SQL Servers, it has proved to be an invaluable reporting tool

I have given a name to the time in the morning at which a DBA typically staggers

in to work, bleary eyed, having spent most of the previous night shrinking log files and scouring disks for every precious Gigabyte of data, in order to find enough

space to clear an alert That name is DBA:M (pronounced D-BAM), and it's

usually around 9.30AM My main goal with this chapter is to help fellow DBAs avoid that DBA:M feeling