– First you need to create the backup/log shipping directory at the primary and you need to share this folder and add full permissions for the primary dataserver SQL Server AND SQL Agent service accounts and read permissions for the secondary dataserver’s SQL Server AND SQL Agent service accounts.
– You need to repeat this at the destination server giving read access to the primary server sql server service account and read/write to the secondary dataserver’s SQL Agent AND SQL Server service accounts.
– You’ll next need to create the secondary database, this obviously needs to be sized the same as the primary database and make it simple recovery mode.
– You can now fire up the log shipping wizard from the primary dataserver by ticking the log shipping radio button under properties for the database.
NOTE: The wizard is a bit rubbish and should not be used to set up log shipping, but it is useful for generating the various stored procs which need to be run on the primary and secondary dataservers.
– The wizard is fairly self explanatory, You select the Primary dataserver log shipping directory as the backup folder (use network share path). Also and VERY IMPORTANT make sure that you select “No, the secondary database is initialised” in the Initialize Secondary database tab. Also select the secondary logshipping directory(configured in step 2 above) as the “destination folder for copied files” in the Copy Files tab. The final step is to select Standby mode and “disconnect users” from the Restore transaction log tab.
– Click the button “Script Configuration” to output all this information to a new query window and save it, you can then close the wizard.
– First make sure the primary database is set to Full logged mode in properties then back it up into the log shipping directory created earlier.
– Copy this dump across to the secondary server log shipping directory.
– Now from the secondary server load the database previously created from this backup. Make sure you leave this database in RESTORE WITH STANDBY mode! Place the standby file in the secondary server logshipping directory.
– On the primary server run the following commands from the script you generated earlier; sp_add_log_shipping_primary_database to add a primary database. sp_add_schedule to add a schedule for the backup job, sp_attach_schedule and sp_update_job.
– (Optional) On the monitor server, execute sp_add_log_shipping_alert_job to add the alert job.
– On the secondary server, execute the jobs from the script, sp_add_log_shipping_secondary_primary, sp_add_schedule and sp_attach_schedule for the copy and restore jobs, and finally the sp_add_log_shipping_secondary_database followed by 2 sp_update_job procs for copy and restore
– On the primary server, execute sp_add_log_shipping_alert_job and sp_add_log_shipping_primary_secondary to add the required information about the new secondary database to the primary server and get things up and running.
MSSQL has many excellent tools which can be used for discovering performance bottlenecks.
Sp_monitor and dbcc perfmon
To get a snapshot of what the SQL Server is doing then these commands are very usefull.
Run sp_monitor twice with a gap of 30 seconds in between to get a high level overview of how busy the sql server is.
dbcc perfmon will give you much more detailed information on the state of the sql server but the command has been supervised by various SQL Server counters which can be used in the System monitor.
SSMS Reports
Sql Server has a set of excellent reports which are generated from the Dynamic Management Views, these are both at the server and database level. If you right click on the server or an individual database in the SQL Server Management Studio then you can select which report to run. You can even export the report output to a pdf. This will highlight any problems which you can then focus on.
System monitor
To drill down further the first port of call should be system monitor or perfmon, which is started by typing perfmon into the run box.
One excellent feature of this is that you can export to a Counter Log at the same time as running a SQL Profiler session, (discussed later), you can then merge them which will let you see how bad queries affect the CPU, memory etc or vice versa.
The objects to normally check for in system monitor are:
Memory, Network Interface, Physical Disk, Processor, SQLServer:Buffermanager, SQLServer:Databases, SQLServer:Exec Statistics, SQLServer:General Statistics, SQLServer:Latches, SQLServer:Locks, SQLServer:Memory Manager, SQLServer:PlanCache, SQLServer:SQL Statistics and System.
SQL Profiler
The system monitor might highlight the bad performance but you will typically need to drill down a bit further to find the bad queries which are causing the problems. To do this you use SQL Profiler.
First step is to establish a performance baseline as follows;
– Start Profiler, Select file, New trace and connect to the relevant instance.
– Specify a trace name, template(standard) and a location to save the trace file too. Set the maximum fiel size to 50MB and enable file rollover.
– In the events selection tab remove Audit Login, Audit Logout, ExistingConnection and SQL:BatchStarting radio boxes.
– Click on show all columns and select the TextData, NTUserName, LoginName, CPU, Reads, Writes, Duration, SPID, StartTime, EndTime, BinaryData, DatabaseName, ServerName and ObjectName coulumns.
– Click on Column Filters and select the Database name to be the database you are interested in.
– Click Run to start the trace and simultaneously start the System Monitor Counter Log.
Correlating the counter Log with Profiler Trace
– Start Profiler, Select File, Open and select the trace file you created from the Performance baseline previously.
– Next go to File, select Import Performance Data and select the Counter Log file you created simultaneously with the performance baseline trace.
– In the performance Counters Limit Dialog window select Network Interface: Output Queue Length, Processor:% processor Time, System:Processor Queue Length and SQLServer:Buffer Manager:Page life expectancy. Click OK.
– You can then scroll through the trace and find what was happening at peak activity on the Windows machine and also what effect certain commands had on the overall server performance.
