“I’ll Wiki you my pretty… and your little script too!!”

So I submitted my first Wiki article over at SQLServerPedia:

Restoring a User Database to a Different Environment

and I have to admit that when I first started thinking about it I was quite concerned about how to do it, whether the script is “wiki worthy”, am I the only one who would find this useful, etc… So let’s talk about it

How to do it – Well look no further then Brent Ozar to provide an amazing how to video: How to Write and Edit Articles

Is my script “Wiki-Worthy” – This is the great thing about a wiki… even if your script is a just basic script to make your job easier what it provides is a building block for others to take and grow into something that turns into a more robust solution. 

Would Anyone Else Find This Useful – Do YOU find your script useful?  So what makes you think you’re so special that others wouldn’t find it useful or maybe they have a similar script that doesn’t do as much as what your script does… maybe it does more and now someone can edit your wiki article to include their contributions.

At the end of the day a wiki article is a great way to not only give something back to the community but it also provides an excellent mechanism to have others edit and contribute their 2 cents into the script or discuss how they solve a similar problem.  If SQL Server has taught me anything it’s taught me that there are a million ways to solve a problem and the way that YOU solve your problem might work but there might be a better solution out there.

Now if you’ve thought of submitting a wiki article to SQLServerPedia… now is the time.  SQLServerPedia is giving away an all expenses paid trip to the PASS Summit for new writers that have never been to the Summit before…  Details Here

See you in Seattle!!

Enjoy!!

Please know what Recovery Mode your databases are in and your recovery requirements and then back them up accordingly.

Too often I see databases that are in a Full or Bulk Logged recovery mode but do not have transaction log backups running.  If you’re not performing transaction log backups there really is no good reason to be in a Full or Bulk Logged Recovery Mode.

Below is a script that you can run against a single instance or if you use a Central Management Server ( See Brent Ozar’s post on CMS) that you can use as a starting point to provide information on your databases, what recovery mode then are in, and their most recent Full, Differential, and Transaction Log Backup Date/Time.  I’ve also included the databases “Updateability” and “UserAccess” as these settings would play a role in your backup strategy.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

SELECT 	A.dbid, A.name as [DatabaseName], 
		CONVERT(sysname,DATABASEPROPERTYEX(A.name, 'Recovery')) AS [RecoveryMode],
		(	SELECT	max(backup_finish_date) 
			FROM	msdb.dbo.backupset 
			WHERE	[type] = 'D' and 
					database_name = A.name) AS [LastFullBackupDateTime],
		(	SELECT	max(backup_finish_date) 
			FROM	msdb.dbo.backupset 
			WHERE	[type] = 'I' and 
					database_name = A.name) AS [LastDiffBackupDateTime],
		(	SELECT	max(backup_finish_date) 
			FROM	msdb.dbo.backupset 
			WHERE	[type] = 'L' and 
					database_name = A.name) AS [LastLogBackupDateTime],
		CONVERT(sysname,DATABASEPROPERTYEX(A.name, 'Updateability')) Updateability,
		CONVERT(sysname,DATABASEPROPERTYEX(A.name, 'UserAccess')) UserAccess
FROM 	master.dbo.sysdatabases A WITH(NOLOCK)
WHERE 	A.name NOT IN ('tempdb')
GROUP BY A.dbid, A.name
ORDER BY A.name

Policy Based Management is also a great way to alert you on databases that do not have an appropriate backup configuration but if you’re not quite “there” yet this is a good place to start until you bridge that gap.

 
Here is a quick description of each Recovery Mode’s backup capabilities:

Simple Recovery Mode

• Full Backups – Yes
• Differential Backups – Yes
• Transaction Log Backups are NOT available because transactions are truncated from the transaction log usually after each checkpoint

Bulk-Logged Recovery Mode

• Full Backups – Yes
• Differential Backups – Yes
• Transaction Log Backups – Yes (but Bulk Operations like BCP, Bulk Insert, etc are minimally logged)

Full Recovery Mode

• Full Backups – Yes
• Differential Backups – Yes
• Transaction Log Backups – Yes

Enjoy!!

If a database fails in the enviroment and no backup is there to recover from does it make a sound?

Well no… but the users are heard for miles hahaha

Below is a nice quick sanity check showing all the dbs that have NOT been backed up for X days or have never been backed up at all. 

DECLARE @num_of_days INT

SET    @num_of_days = 1 

SELECT     A.name, MAX(B.backup_finish_date) AS 'LastBackupDateTime'

FROM   master.dbo.sysdatabases A WITH(NOLOCK)  LEFT OUTER JOIN

   msdb.dbo.backupset B WITH(NOLOCK) ON A.name = B.database_name

WHERE  (B.TYPE = 'D' OR B.TYPE IS NULL)

GROUP BY A.name

HAVING (MAX(B.backup_finish_date) < GETDATE() - @num_of_days OR MAX(B.backup_finish_date) IS NULL) 

ORDER BY A.name



Enjoy!!


DECLARE @StartDateTime DATETIME = GETDATE()
BACKUP DATABASE <<DatabaseName>>  TO DISK = 'D:\NotCompressed.bak' WITH INIT, COPY_ONLY
SELECT DATEDIFF(ms, @StartDateTime, GETDATE())

SET @StartDateTime = GETDATE()
BACKUP DATABASE <<DatabaseName>>  TO DISK = 'D:\Compressed.bak'  WITH INIT, COPY_ONLY, COMPRESSION
SELECT DATEDIFF(ms, @StartDateTime, GETDATE())

BACKUP SIZE (my sample db): 129 MB (uncompressed) vs. 35 MB (compressed).

Compression ratio varies depending on what type of data there is in the database (ie string data tend to compress better than other data).

BACKUP EXECUTION TIME (my sample db): 8 seconds (uncompressed) vs. 4 seconds (compressed).

Keeping in mind that this is a small sample database but on a much larger scale these types of savings would be huge.

RESTORE EXECUTION TIME (my sample db): 11 seconds (uncompressed) vs. 6 seconds (compressed).

This is the one that suprised me… I thought there would be more overhead with uncompressing the backup file that would cause the restore time to be longer but the only measure that I saw was that the CPU utilization was alot higher on the compressed backup.

Full Backup – This is like it sounds a full copy of the databases. Full backups take the most time to complete but they are also the easiest form of backup to recover from. A full backup is required before you can do any other type of backup. If you run full backups once daily in the case of failure your potential data loss is ~ 24 hours (depending on time of failure).

Differential Backup – This is a backup of everything that has happened in your database since the last full backup. Differential backups are smaller and faster then a full backup but in order to recovery from a differential backup you need to restore the full backup first and then the differential backup. If you run differential backups every 6 hours your potential data loss is ~ 6 hours (depending on time of failure).

Transaction Log Backup – This is a backup of everything that has occured since the last full or differential backup or since the last transaction log backup.  Transaction log backups are usually very small and very fast to complete but the recovery time required to restore from a transaction log backup is longer then the other backup types.  In case of failure you would need to restore your full backup, any differential backups (if applicable), and then every transaction log taken since the last full (or differential backup). If you run transaction log backups every 15 minutes your potential data loss is ~ 15 minutes (depending on time of failure).

Bottom line… if you have a database that has it’s recovery mode set to BULK_LOGGED or FULL recovery mode you should be backing up your transaction log periodically.

Enjoy

DECLARE @num_of_days INT

CREATE TABLE #DatabaseListNotSimple (dbid INT IDENTITY(1,1), DatabaseName VARCHAR(50)) 

INSERT INTO #DatabaseListNotSimple

SELECT name AS ‘DatabaseName’

FROM MASTER.dbo.sysdatabases WITH(NOLOCK)

WHERE (CONVERT(VARCHAR(50),DATABASEPROPERTYEX(name,‘Recovery’))= ‘FULL’ OR

CONVERT(VARCHAR(50),DATABASEPROPERTYEX(name,‘Recovery’))= ‘BULK_LOGGED’) AND

name <> ‘model’ 

SELECT A.DatabaseName, MAX(B.backup_finish_date) AS ‘LastLogBackupDateTime’

FROM #DatabaseListNotSimple A LEFT OUTER JOIN

msdb.dbo.backupset B WITH(NOLOCK) ON A.DatabaseName = B.database_name

WHERE (B.TYPE = ‘L’ OR B.TYPE IS NULL)

GROUP BY A.DatabaseName

HAVING (MAX(B.backup_finish_date) < GETDATE() - @num_of_days OR

MAX(B.backup_finish_date) IS NULL) 

DROP TABLE #DatabaseListNotSimple

GO