Introduction

This article is based on a real life experience of the author while working with database backup and restore during his consultancy work for various organizations. We will go over the following important concepts of database backup and restore.

1. Conventional Backup and Restore
2. Spilt File Backup and Restore
3. Mirror File Backup
4. Understanding FORMAT Clause
5. Miscellaneous details about Backup and Restore

In our example, we will require the following folders:

• C:\Backup\SingleFile
• C:\Backup\MultiFile
• C:\Backup\MirrorFile

Conventional and Split File Backup and Restore

Just a day before working on one of the projects, I had to take a backup of one database of 14 GB. My hard drive lacked sufficient space at that moment. Fortunately, I had two 8 GB USB Drives with me. Now, the question was how to take a backup in two equal sizes, each of 7 GB, so I can fit them on each USB drive. Well, conventional backup takes one large backup in one file. However, SQL Server backup command can take backups in two or more split parts.

Let us see an example of a conventional one-file backup using the AdventureWorks database.

The result is displayed below. Here, the backup is taken in a single file.

Now, let us see how we can split one database into two different database files. This method is very similar to taking a single-file backup. By simply adding an additional DISK option we can split the files backup files.

In the previous example, we can clearly see that backup is split into three equal parts of the original backup file size.

Restoring a backup from a single-file backup is quite easy. Let us go over an example where we restore the AdventureWorks database from a single backup file.

Running the above script will give a successful message.

Now let us see an example where we restore a database from a split file. This method is very similar to restoring a database from a single file; just add an additional DISK option.

Running the above script will give a successful message as shown in the image below.

Make sure that while restoring database, the database is not in use, otherwise it will give an error of database in use. In the event of an error taking place, close all the connections and re-attempt to restore the database.

Mirror Backup of the file

It is quite a common practice to create an exact copy of the backup and store it to several places to deal with any catastrophes which might affect the place where the database is stored. Once a full backup is accomplished DBAs generally copy the database to another location in their network using a third party tools like robocopy or native DOS commands like xcopy.

In SQL Server 2005 and later versions, there is a Mirror command that makes a copy of the database backup to different locations while taking the original backup. The maximum limit of additional locations that can be specified with MIRROR clause is 3.

Mirrored backup can be taken in local computer system as well as in a local network. Let us now see two examples of mirror backup.

Example 1. Single File Backup to Multiple Locations using Mirror

If this command is being run for the first time, it is mandatory to use the WITH FORMAT clause; but for sub sequential runs it is not required. WITH FORMAT reinitializes the backup.

When checked in both the folders ‘SingleFile’ and ‘MirrorFile’, backup files are exactly the same files. As mentioned earlier, four mirror backup can be specified in total.

Example 2. Split File Backup to Multiple Locations using Mirror

We have earlier seen an example where we can have multiple split files of large database backup files. SQL Server Mirror functionality also supports backup of the split files.

All the mirror sets will need the same number of DISK clauses as the original backup media.

Mirrored database backup can be restored using the same method as the original backup. Mirrored backup is in fact an exact replica of the original backup.

Understanding the FORMAT Clause

The FORMAT clause is used to reinitiate a backup media. Although it is a very useful clause it should be used with caution. When the clause is used it erases everything present in backup media. I have noticed that some DBAs are confused while taking a backup on a local disk where they have SQL Server installed. They have a misconception that if the format command is used, it will erase the complete disk including the SQL Server installation. However, the fact is that SQL Server format clause is quite different from OS format. The effect of SQL Server format clause is limited to a folder or path specified in the DISK clause.

In our example, when the FORMAT clause is specified, it will format only folders like C:\Backup\MultiFile\ or C:\Backup\SingleFile.

Related Errors

Error 3010
Invalid backup mirror specification. All mirrors must have the same number of members.

This error can show up while taking a mirrored database backup along with a regular backup; and DISK and MIRROR TO DISK do not match accurately.

The following image demonstrates how the error takes place.

To fix the error, match the members of DISK and MIRROR TO DISK to each other.

Error 3215
Use WITH FORMAT to create a new mirrored backup set

This error can spring up when a new backup is initiated and an existing media header needs to be reset for all headers on the backup media. If there is already a backup on the media, it will display this error and prevent backup from being overwritten. To fix this error, use WITH FORMAT as shown in an earlier example.

Miscellaneous details about Backup and Restore

When no options are specified, BACKUP DATABASE takes only full backups. Before taking the first log backup, full database backup is necessary to take one full backup. Backups created on later versions of SQL Server cannot be restored to earlier versions of SQL Server. The user needs permissions of sysadmin or db_owner or db_backupoperator roles to perform backup operation.

Reference : Pinal Dave (http://blog.sqlauthority.com), DNS

During a recent consultancy project, I was asked to review a Database Backup plan. While going through the plan, I noticed that there was no backup for the master database. When I questioned this, the DBA informed me that it was not necessary. I was startled and couldn’t resist explaining to him that the master database contains all the logon accounts details, as well as all the system-level database configuration. He was a little astounded and asked me to tell him at what intervals he should backup the master database. The discussion that followed was very thought provoking and I would like to share the major points with you:

• The master database is the most important database of all and the most recent version of the backup should be available in the case of disaster.
• Backup of the master database should be made for:
  • Changing server-level configuration settings;
  • Changing database-level configuration settings; and
  • Changing any logon accounts details.

On further observation of his master database, I found that he has some system maintenance Stored Procedure created in the master database. This should not be the case. The master database should not contain any user-created objects. Users should not be required to modify or create anything in the master database. The real purpose of the master database is for the SQL Server to maintain itself. Users only need to make backups and restore when needed.

Do you backup your master database? Please leave your comments here.

Reference : Pinal Dave (http://blog.SQLAuthority.com)

Posted in Best Practices, Pinal Dave, SQL, SQL Authority, SQL Backup and Restore, SQL Query, SQL Server, SQL Tips and Tricks, SQLServer, T SQL, Technology ]]> http://blog.sqlauthority.com/2009/08/12/sql-server-backup-master-database-interval-master-database-best-practices/feed/ 14 pinaldave http://blog.sqlauthority.com/2009/07/16/sql-server-four-different-ways-to-find-recovery-model-for-database/ http://blog.sqlauthority.com/2009/07/16/sql-server-four-different-ways-to-find-recovery-model-for-database/#comments Thu, 16 Jul 2009 01:30:26 +0000 pinaldave http://blog.sqlauthority.com/?p=5915 ]]>

Perhaps, the best thing about technical domain is that most of the things can be executed in more than one ways. It is always useful to know about the various methods of performing a single task. Today, we will observe four different ways to find out recovery model for any database.

Method 1

Right Click on Database >> Go to Properties >> Go to Option. On the Right side you can find recovery model.

Method 2

Click on the Database Node in Object Explorer. In Object Explorer Details, you can see the column Recovery Model.

Method 3

This is a very easy method and it gives all the database information in one script.

SELECT name AS [Database Name],
recovery_model_desc AS [Recovery Model]
FROM sys.databases
GO

Method 4

This method provides only one database at a time.

SELECT 'ADVENTUREWORKS' AS [Database Name],
DATABASEPROPERTYEX('ADVENTUREWORKS', 'RECOVERY')
AS [Recovery Model]
GO

My recommendation

Of all the above methods, I prefer Method 3. It is accurate and can be used in T-SQL code. Besides, I can use it for many other purposes as well.

I would like to know which one is your favorite method .

Reference : Pinal Dave (http://blog.SQLAuthority.com)

I maintain a spreadsheet of questions sent by users and from that I single out a topic to write and share my knowledge and opinion. Unless and until I find an issue appealing, I do not prefer to write about it, till the issue crosses the threshold. Today the question that crossed the threshold is – what is the difference between NORECOERY and RECOVERY when restoring database.

The fact is that one can easily go to MSDN and learn the difference, so I head myself to MSDN and read the difference. This is what the Book On Line suggests here.

NORECOVERY specifies that roll back not occur. This allows roll forward to continue with the next statement in the sequence.
In this case, the restore sequence can restore other backups and roll them forward.
RECOVERY (the default) indicates that roll back should be performed after roll forward is completed for the current backup.
Recovering the database requires that the entire set of data being restored (the roll forward set) is consistent with the database. If the roll forward set has not been rolled forward far enough to be consistent with the database and RECOVERY is specified, the Database Engine issues an error.

Book On Line has very clearly explained the same subject and provides succinct explanation of the difference.

In other words -

While doing RESTORE Operation if you restoring database files, always use NORECOVER option as that will keep database in state where more backup file are restored. This will also keep database offline also to prevent any changes, which can create itegrity issues. Once all backup file is restored run RESTORE command with RECOVERY option to get database online and operational.

It is also important to be acquainted with the restore sequence of how full database backup is restored.

First, restore full database backup, differential database backup and all transactional log backups WITH NORECOVERY Option. After that, bring back database online using WITH RECOVERY option.

Following is the sample Restore Sequence

RESTORE DATABASE DATABASE FROM full_database_backup WITH NORECOVERY;
RESTORE DATABASE DATABASE FROM differential_backup WITH NORECOVERY;
RESTORE LOG DATABASE FROM log_backup WITH NORECOVERY;
-- Repeat this till you restore last log backup
RESTORE DATABASE DATABASE WITH RECOVERY;

I hope now it is very clear to you all what is restore sequence and the difference between recovery options.

Reference : Pinal Dave (http://blog.SQLAuthority.com)

I assume you all know that there are three types of Database Backup Models, so we will not discuss on this commonly known topic today. In fact, we will just talk about how to restore database that is in full recovery model.

In general, databases backup in full recovery mode are taken in three different kinds of database files.

1. Full Database Backup
2. Differential Database Backup
3. Log Backup

What really perplexes most people is differential database backup.

Let me narrate here a real story. One of the DBAs in local city once called me up and laughingly said that he has just found something not smart about SQL Server Product Team in terms of database backup. I just could not believe this negative remark against SQL Server Product Team so I asked him to explain me what is it. He told me that in his opinion it is an extra step when it is about Differential Database backup. I asked him how he restores his database. He replied that he starts with first full database backup and then sequentially all log backups and differential database backups. He continued his explanation and said that he has figured something interesting; that is, if he does not restore all the differential database backups and only restores log backups it just works fine. According to him this is an unnecessary step.

Well, I am extremely happy to say he is wrong. He has totally failed to understand the concept of differential database backup. I called up another friend in his company and told him this story and he found it funny too! He suggested that he will explain to my friend that he needs to do all differential backups first and then all log backups after the last differential backup. I was again amazed and didn’t know what to do. He was wrong too!

After interacting with many DBAs I have realized that it is quite confusing to most of the people how differential database is useful and many are not aware of the correct method to restore full recovery model. Before I start explaining please understand the following diagram where I have demonstrated time line when a backup was taken.

Let us remember the golden rule for restore first.

‘After restoring full database backup, restore latest differential database backup and all the transaction log backup after that to get database to current state.’

From the above-listed rule, it is very clear that there is no need to restore all the differential database backups when restoring databases. You can only restore the latest Differential database backup. Differential database backup is the backup of all the changes made in database from last full backup; it is cumulative itself. That is the reason why the size of next differential database backup is much more than the previous differential database backup. All differential database backups contain all the data of previous differential database backups. You just have to restore the latest differential database backup and right after that install all the transaction database backups to bring database to the current state.

If you do not want to have differential database backup and have all the transaction log backups, in that case, you will have to install all the transactional database backups, which will be very time consuming and is not recommended when disastrous situation is there and getting server back online is the priority. In this way, differential database backups are very useful to save time as well as are very convenient to restore database. Instead of restoring many transaction database logs, which needs to be done very carefully without missing a single transaction in between, this is very convenient.

In our example, there are multiple paths to get server to the current state.

Path 1 (SLOWEST) : Full Database Restore >> Log Backup 0_1 >> Log Backup 1_1 to all remaining logs.

Path 2 : Full Database Restore >> Differential Database Backup 1 >> Log Backup 1_1 to all remaining logs.

Path 3 (FASTEST) : Full Database Restore >> Differential Database Backup 2 >> Log Backup 2_1 to all remaining logs.

Let me know if my explanation is clear to you all. If there is any confusion regarding how full database backup restore works then do inform me.

Reference : Pinal Dave (http://blog.SQLAuthority.com)

Standby servers - Standby Server is a type of server that can be brought online in a situation when Primary Server goes offline and application needs continuous (high) availability of the server. There is always a need to set up a mechanism where data and objects from primary server are moved to secondary (standby) server. This mechanism usually involves the process of moving backup from the primary server to the secondary server using T-SQL scripts. Often, database wizards are used to set up this process.

We will now glance at the various types of standby servers.

Hot Standby – Hot Standby can be achieved in SQL Server using SQL Server 2005 Enterprise Edition and the later enterprise versions. SQL Server 2005 has introduced Mirroring of database that can be configured for automatic failover in a disaster situation. In the case of synchronous mirroring database is replicated to both the servers simultaneously.  This is a little expensive but provides the best high availability. In this case, both primary and standby servers have same data all the time.

Warm Standby – In Warm Standby automatic failover is not configured. This is usually set up using Log Shipping or asynchronous mirroring. Sometimes warm standby is lagging by a few minutes or seconds, which results into loss of few latest updates when primary server fails and newer server needs to be failed over. Sometimes warm server that is lagging by a few transactions is brought back to the current state by applying recent transaction log.

Cold Standby – Code Standby servers need to be switched manually, and sometimes all the backups as well as the required OS need to be applied. Cold Standby  just physically replaces the previous server.

I am curious to know what do you all think about this these three types of standby servers. I am eager to know what kind of server setup you have at your workplace. If you can share these details, it will be very useful to all the readers. If I find your information interesting, I will create a new blog post with due credit to you.

Reference : Pinal Dave (http://blog.SQLAuthority.com)

This article revolves around a trivial yet common issue. There might be a set of people for whom the current topic might appear to be insignificant. But I have been asked this question innumerable times, particularly from   people who are frequenting using forums or have blog related to storage and highly availability, which instigated me to write this article.

Here goes this frequently asked question.

Question: Is it possible to restore database if one of the files of .mdf (primary data file) or .ndf (secondary data file) is missing?

Answer: In one word the answer is NO. All the .mdf and .ndf files are mandatory to attach or restore database successfully.  Even though  you have all the transactions stored in .ldf you will not be able to restore the database completely.

I hope this answer removes the cloud of doubt hovering over my targeted readers.

Reference : Pinal Dave (http://blog.sqlauthority.com)

Posted in Database, Pinal Dave, SQL, SQL Authority, SQL Backup and Restore, SQL Data Storage, SQL Error Messages, SQL Query, SQL Server, SQL Tips and Tricks, T SQL, Technology ]]> http://blog.sqlauthority.com/2009/04/10/sql-server-restore-or-attach-database-without-ndf-or-mdf-is-not-possible/feed/ 3 pinaldave http://blog.sqlauthority.com/2009/04/05/sql-server-mirrored-backup-and-restore-and-split-file-backup/ http://blog.sqlauthority.com/2009/04/05/sql-server-mirrored-backup-and-restore-and-split-file-backup/#comments Sun, 05 Apr 2009 01:30:04 +0000 pinaldave http://blog.sqlauthority.com/?p=4670 ]]>

Introduction

This article is based on a real life experience of the author while working with database backup and restore during his consultancy work for various organizations. We will go over the following important concepts of database backup and restore.

1. Conventional Backup and Restore
2. Spilt File Backup and Restore
3. Mirror File Backup
4. Understanding FORMAT Clause
5. Miscellaneous details about Backup and Restore

Conventional and Split File Backup and Restore

Just a day before working on one of the projects, I had to take a backup of one database of 14 GB. My hard drive lacked sufficient space at that moment. Fortunately, I had two 8 GB USB Drives with me. Now, the question was how to take a backup in two equal sizes, each of 7 GB, so I can fit them on each USB drive. Well, conventional backup takes one large backup in one file. However, SQL Server backup command can take backups in two or more split parts.

Read Complete Article here.

Reference : Pinal Dave (http://blog.SQLAuthority.com)

It goes without saying that Database Backup is the most important task for any Database Administrator (DBA). Naturally, large organizations always have a team of DBAs who execute Database Backup tasks. No matter how big or small an organization is, the importance of database backup remains the same across the board. It’s a common practice in several organizations to upload the backup to their remote location for additional safety. I totally vouch for this safety measure of having their additional backup on remote/satellite location. This redundancy comes in handy whenever a catastrophe of not having proper backup surfaces abruptly.

While I was searching online for a very simple solution for one of my clients, I came across a small-sized but feature-rich application from SqlBackupAndFTP.com. This practical application has been created by Pranas.NET (http://pranas.net) I have made extensive use of this tool for some time now and undoubtedly, this tool is very impressive by all standards!

To put it simply, SQLBackupAndFTP is MS SQL Server backup software. This tool performs several tasks such as running scheduled backups of SQL Server or SQL Server Express databases, zipping the backups, storing them on a network or on a FTP server, removing old backups, and finally, sending an e-mail confirmation on job’s success or failure. Besides, SQLBackupAndFTP Free is freeware, which is free from any spyware. Best of all, this ingeniously simple tool is extremely affordable for all. You just need to install it on the server and you can get up and running really fast.

Given below are some important tasks which this tool can perform using daily scheduler:
•    Backup SQL Server Database
•    Zip the backups
•    Encrypt the backups
•    FTP the backups to remove FTP server
•    Move file to local area network
•    Send final status of tasks in email.

Let us now see how we can take backup and move it to the desired folder.

Image 1: First, connect to the desired server.

Image 2: As you can see, all the settings are very easy as described in the following image. Pay attention to these very simple, one screen settings. From database selection to job scheduling, you can configure everything from this page itself.

Image 3: This screen describes all the steps that are being performed. User can easily view the status of all the jobs – either success or failure – on this page.

Image 4: The following screen displays the settings for advanced users who have to deal with large database.

Image 5: This screen displays email regarding final status of tasks, which is sent to the user after task completion.

Now, a question that might baffle your mind is – how this tool is better than maintenance tasks available in SQL Server. Well, here goes the answer. Maintenance tasks are easy to set up for backups; however, SQLBackupAndFTP have integrated solution for encryption, FTP and email which make it superior to maintenance tasks in every aspect.

I would like to present my unbiased view about this tool. At the same time, I want to give my readers a broad perspective about backup tools in general.  On comparing this tool with other backup tools I have experienced that it is not the fanciest tool to manage backups or check their health. This is one tool that smoothly performs the job in a few steps compared to native SQL Server backup, which takes numerous steps to execute the same job.

SQLBackupAndFTP is best suited for developers/DBAs who just want to ensure that they have schedule job that takes care of backup and moves them to appropriate place. In fact, it is ideal for any SQL Server database where backups need to be sent every day to a remote FTP server. It saves maintenance time on any SQL Server version. Besides, it is especially useful for SQL Server Express 2005 and SQL Server Express 2008, as they lack built in tools for backup.

This tool is compatible with almost all the known SQL Server versions. It works with SQL Server 2008 (all versions) and many of the previous versions.

While testing this tool, I noticed that there are few limitations. It does not support differential or transaction backups. I also found that this tool only works on local SQL Server instances and cannot connect to another SQL Server on LAN. When I contacted support, I came to know that they are planning to release its updated version in April 2009, which will not have any such limitations.

I strongly recommend this tool to all the DBAs. They must try it as it is absolutely free and does exactly what it promises. You can download your free copy of the tool from here.

Please share your experience about using this tool. I am eager to receive your feedback regarding this article.

Reference : Pinal Dave (http://blog.sqlauthority.com)

As I am doing lots of experiments on my SQL Server test box, I sometime gets too many files in SQL Server data installation folder – the place where I have all the .mdf and .ldf files are stored. I often go to that folder and clean up all unnecessary files I have left there taking up my hard drive space. I run following query to find out which .mdf and .ldf files are used and delete all other files. If your SQL Server is up and running OS will not let you delete .mdf and .ldf files any way giving you error that file already in use. This list also helps sometime to do documentation of which files are in being used by which database.

SELECT name, physical_name AS current_file_location
FROM sys.master_files

Following is the output of files used by my SQL Server instance.

Reference : Pinal Dave (http://blog.SQLAuthority.com)

Posted in Pinal Dave, SQL, SQL Authority, SQL Backup and Restore, SQL Documentation, SQL Query, SQL Scripts, SQL Security, SQL Server, SQL System Table, SQL Tips and Tricks, T SQL, Technology ]]> http://blog.sqlauthority.com/2009/02/17/sql-server-find-current-location-of-data-and-log-file-of-all-the-database/feed/ 2 pinaldave http://blog.sqlauthority.com/2009/02/15/sql-server-reasons-to-backup-master-database-why-should-master-database-backedup/ http://blog.sqlauthority.com/2009/02/15/sql-server-reasons-to-backup-master-database-why-should-master-database-backedup/#comments Sun, 15 Feb 2009 01:30:06 +0000 pinaldave http://blog.sqlauthority.com/?p=2582 ]]>

The most interesting thing about writing blog at SQLAuthority.com is follow up question. Just a day before I wrote article about SQL SERVER – Restore Master Database – An Easy Solution, right following it, I received email from user requesting reason for importance of backing up master database.

Master database contains all the system level information of server. Information about all the login account, system configurations and information required to access all the other database are stored in master database. If master database is damaged, it will be difficult to use any other database in SQL Server and that makes it most important database of the SQL Server.

Let us understand the important of the master database using an example. We will take example of SQL Server DBA and follow his timeline. Make sure to understand it correctly, as I have small question at the end of the timeline.

9:00 AM – DBA takes backup of the master database.
10:00 AM – DBA creates new Database named AfterMaster.
11:00 AM – DBA restores the master database backup taken at 9:00 AM.
12:00 PM – I have following two questions for the DBA :

Question 1) What will be the state of the database AfterMaster? If AfterMaster database will be in active state after restoring master database?
Question 2) What should be the next step after restoring master database?

Let us understand the answer of question.

Answer 1) Once master database is restored it will have no record of AfterMaster database in its system database and it will not recognize it.
Answer 2) If master database is restored from backup all the operation which are done after last master database backup should be repeated in order to bring SQL Server in the current operational state. In our case, the database files (ldf and mdf) of AfterMaster database will still exists on server. They should be reattached to the server. You can search about how to attach mdf and ldf file at Search@SQLAuthority.com.

It is clear from our example that master database contains user login, files, filegroups and server wide settings.

In summary, it is extremely important to take backup of the master database.

Reference : Pinal Dave (http://blog.SQLAuthority.com)

Today we will go over two step easy method to restore ‘master’ database. It is really unusal to have need of restoring the master database. In very rare situation this need should arises. It is important to have full backup of master database, without full backup file of master database it can not be restored.

It is necessary to start SQL Server in single user mode before master database can be restored. It is very easy to start SQL Server server in single user mode. Follow the tutorial SQL SERVER – Start SQL Server Instance in Single User Mode.

Once SQL Server instance is running in single user mode, immediately connect it using sqlcmd and run following command to restore the master database.

RESTORE DATABASE master FROM DISK = 'C:\BackupLocation\master.back' WITH REPLACE;
GO

I have tested it couple of times and it has worked fine for me. If you encounter any error please leave a comment and I will do my best to solve it.

Reference : Pinal Dave (http://blog.SQLAuthority.com)

Ahmedabad SQL Server User Group Meeting was organized on November 29, 2008 at famous C.G. Road in Ahmedabad. We had great response and wonderful back to back technical sessions. The highlight of whole meeting was participation of UG President Jacob Sebastian - SQL MVP from New York.

Meeting started with introduction and welcome to all the members from SQL Server MVP – Pinal Dave and followed by technical session of “SQL Server 2008 – Backup and Compression” by Pinal Dave. This session was very special because not every database user is aware of the special feature of SQL Server 2008 and how it can improve the life of SQL Administrator.

Download the PDF of the SQL Server Presentation

[Please leave a comment in this thread if you are interested in SQL script which I had used in this demo presentation.]

I am very much encouraged as a User Group Leader because one of the member of UG Tejas Shah presented his very first technical session today. Tejas Shah delivered excellent session of “Introduction to Service Broker”. It is very new subject and UG members liked it.

The most awaited session was presented by SQL Server MVP – Pinal Dave where he discussed “How to become MVP?”. Pinal explained the advantages and responsibility of becoming MVP. There were many questions regarding this subject. I think UG members and SQL enthusiastic were really into learning how to become MVP. I did my best to answer all the questions which I had received. Community Service is the short answer of this subject.

Pinal Dave shared his experience of attending MVP Open Day 2008, Goa. There were nearly 15 brand new photographs of the Open Day. To know more about MVP Open Day 2008 please visit following article.

SQLAuthority News – Author Visit – South Asia MVP Open Day 2008 – Goa – Group Photo

UG president Jacob who is New York participated in this meeting using GoToMeeting and discussed his experience of attending PASS conference. This was very special as this was first time when we had live presentation using Audio Video community tools.

Well last but not least, we had our ice creams. Ice Cream was from Havmore and flavor was ‘lonavali’. Let me know if you have any suggestions. Again, if you are interested in participating in UG meetings, please let me know. It is free and good networking with other tech developers.

Pinal Dave UG Introduction

Pinal Dave Technical Session

Tejas Shah on Service Broker

UG Group Photos

Reference : Pinal Dave (http://blog.SQLAuthority.com)

Today is special day for SQL Server enthusiastic as we will have SQL Server User Group Meeting today in Ahmedabad. Today in User Group we will have UG President Jacob Sebastian (MVP) participating from New York and UG Vice President Pinal Dave (MVP) will talk about “How to become MVP?”

Agenda for today’s meeting is as following:

Agenda:
1) Introduction by Pinal Dave
2) Direct from New York – Live Meeting by Jacob Sebastian- SQL Pass Roundup and Other News
3) Technical Session by Pinal Dave – Compressed Backup and Restore Techniques
4) Technical Session by Tejas Shah – What is Service Broker?
5) Information Session by Pinal Dave – What is MVP? - MVP Open Day 2008 – Goa
6) Question and Answers
7) Ice Cream

Make sure to reach at location at sharp 6:00 PM as we will start on time and you do not want to miss the session by any of leading speaker. I will share few of the special images of MVP Open Day 2008 held at Goa.

SQL Server User Group Meeting – November 2008

Location : 401, TIME SQUARE, CG road, Op Bazar Calcutta, Ahmedabad, India

Date and Time : November 29, 2008 6:00 PM onwards (6:00 PM sharp)

Hope to see all of you there.

If you with to attend the meeting, please register your name by sending an email to jacob.reliancesp[at]gmail.com latest by Saturday 12 Noon.

Reference : Pinal Dave (http://blog.SQLAuthority.com)

SQL Server stores history of all the taken backup forever. History of all the backup is stored in msdb database. Many times older history is no more required. Following Stored Procedure can be executed with parameter which takes days of history to keep. In following example 30 is passed to keep history of month.

USE msdb
GO
DECLARE @DaysToKeepHistory DATETIME
SET @DaysToKeepHistory = CONVERT(VARCHAR(10), DATEADD(dd, -30, GETDATE()), 101)
EXEC sp_delete_backuphistory @DaysToKeepHistory
GO

Reference: Pinal Dave (http://www.SQLAuthority.com)

Pro SQL Server 2005 Replication (Definitive Guide) (Hardcover)
by Sujoy Paul (Author)

Link to Amazon (This is not affiliate link)

Quick Review:
This is good book for any novice developer to start in the world of database replication implementation and maintenance. Replication is important part of highly availability and one book covers all the concept and methodology at one place.

Detail Review:
Replication is the process of sharing information so as to ensure consistency between redundant resources, such as software or hardware components, to improve reliability, fault-tolerance, or accessibility. Database replication can be used on many database management systems, usually with a master/slave relationship between the original and the copies. The master logs the updates, which then ripple through to the slaves. The slave outputs a message stating that it has received the update successfully, thus allowing the sending of subsequent updates.

This books talks about different replication types and methods. This book explains different scenarios where types of replication can be used. Sujoy Paul (SQL Server – MCP) explains the concept with many screenshots and simple examples. This book is not limited to replication types only but it also covers replication between heterogeneous databases and other objects.

Pros :

• Lots of screen shots
• Lots of explanation of how different procedures works
• Good coverage of different kind of replications
• Step by Step guidance
• Complete coverage of any methodology
• Truly useful to novice programmers

Cons:

• No discussion about potential errors can come across during replication process
• Some of the screen shots are hard to read (Apress should look into this matter)
• Some of the chapters are very blurry

Overall, this is great book for any novice developer who is beginning in the world of replication. Though this book covers many screenshots and material directly from Book On Line this is great collection of all the concept at any place. I have personally used this book when I was new DBA and have learned replication basics from this book.

Stars: 4 Stars

Summary: This a comprehensive single source of information will save lots of time as there is no need to go through multiple books to implement and maintain replication solutions.

Reference : Pinal Dave (http://blog.SQLAuthority.com)

Imran Mohammed continues to help community of SQL Server with his very enthusiastic writing and deep understanding of SQL Server architecture. Let us read what Imran has to say about how Transaction Log works and Shrinking of Log works.

Question from lauraV

Please help me understand. I am taking a full backup once a day, and transaction logs once every hour. Why is my LDF file not retaining a “normal” size? It continues to grow. I do not want to break the chain and use truncate only, though I have done this and it fixes the problem. I would very much like to understand the underlying problem.
thank you in advance

I suggest to all my readers to read the answer from Imran, this really explains what really goes on behind the scene of Transaction Log. I have highlighted some of the important keylines and keywords in his answer to lauraV.

Answer from Imran Mohammed

@LauraV.

You did not mention which version of SQL Server you are using, Either 2000 or 2005, ( would be easy for us to narrow our answer to questions)

When ever you take transactional log backup, no matter if you scheduled it or if you take it manually, SQL Server by default will empty transactional log. Meaning after the transactional backup ( Be Careful NOT FULL BACKUP) SQL Server will remove inactive transactions from logfile.

Which means your transaction file is empty after you take transactional log backup, Empty doesnot mean your logfile became small, NO. the size of the log file will still be the same but it will be empty, all you have to do is shrink logfile, run below command,

USE database_name
DBCC shrinkfile (logfilename, 1)

and it will shrink the log file to its minimum size possible,

In SQL Server 2000:

Right click database name -> all task -> backup -> in the dialog box, select transactional backup, and click on options ( at the top left side of the box) you will see “remove inactive entries from Transactional log”.

This means when you take transactional Log backup, SQL Server is removing all inactive entries from SQL Server log file. This is default setting.

In SQL Server 2005:

Right Click database name->task ->Backup in the Dialog box, select backup type Transactional backup, and click options tab (at left side up) and under Transaction log section you will see “Truncate the Transaction log”.

Which mean when SQL Server 2005 performs transactional backup it truncates logfile. This is also default setting.

NO matter if you use SQL Server 2000 or SQL Server 2005, SQL Server by default (can be changed) will truncate log after performing Transactional backup.

So simple solution will be shrink log file after you take transactional log backup. You dont have to do it manually You can send this as a response to this transactional bacup job, when ever this job succeed, response to that would be run this script

USE databasename
DBCC shrinkfile ( logfile_name, 1)

That might work.

I will take one more minute to explain what is this active and inactive transaction in the logfile . Please correct me if I am wrong.

This is how SQL Server works,

Note from Pinal – Following 4 paragraph is the most interesting part of whole discussion.

When a transaction comes to SQL Server, it first comes to transactional log buffer, and then it is hardened to disk ( log file, .ldf ) and then it is written to data file ( .mdf). Then we say the transaction is committed or it is inactive, because the transaction performed all the actions that it should.

On the other hand, when a transaction comes to SQL Server and it is entered into log buffer and also in transactional log, but not yet entered in data file, its still in the process, then we will say this transaction as active transaction.

One important point to think is, all the inactive transactions in the log file ( transactions which completed their tasks and are entered in data file) are also present in data file, and SQL Server is smart enough to think, inactive transactions are already in data file and also, they have been backed up( by transactional log backup) hence it thinks, this is the time to get rid of this data and it removes all the inactive transactions.

But for Active transactions, which are either incomplete or could not complete because of disaster ( sudden power failure….) will be stored in transactional log and will be called acive transactions untill they are entered in data file.

This will be little bit confusing…

Read more about this in books online.

Hope this helps.
Imran.

Reference : Pinal Dave (http://blog.SQLAuthority.com)

Just a day ago I received question from reader who just installed SQL Server 2008. After installation user did not find any samples database along with installation. User want to install samples database which he is very much used to.

Sample database are now moved to Microsoft’s opensource site of Codeplex. Visit following link to visit the Sample Database page.

CodePlex SQL Server Sample Database

There are two different method to setup sample database. 1) Running SQL Script 2) Restoring Database Backup. There are few common steps in both the process. We will see the common process first and then after see both the method to setup sample database in detail.

Common Steps:

Download the .msi package from codeplex based on your operating system and your SQL Server version. I have used Adventureworks DB version of 2005 as that is what was question from user. If you download version of 2008 it can only be installed in version of 2008.

Most of the images are self explanatory so I will let images explain most of the details.

Above image displays the location where Sample Database is installed. Please note the location of same database as “C:\Program Files\Microsoft SQL Server\100\Tools\Samples\AdventureWorks OLTP“

Method 1 : Using T-SQL Script

Open SQL Server Management Studio and open the file instawdb from the location where sample database are extracted “C:\Program Files\Microsoft SQL Server\100\Tools\Samples\AdventureWorks OLTP“.

Now make sure that you find variable @data_path and change its values to the location of the database. This is very important task otherwise your database will be created with empty tables.

Once script is successfully ran, following resultset will be returned.

Check AdventureWorks database in object explorer.

Method 2 : Restoring Database Backup

This method requires to create empty database initially and then after restoring it from backup. Please pay attention to radio buttons and checkbox on the screen as it is very important to select right options when restoring database.

Location of Database backup is where sample database are extracted “C:\Program Files\Microsoft SQL Server\100\Tools\Samples\AdventureWorks OLTP“.

Following screen is most important, make sure to select options displayed in the screen or database will not be restored.

Check AdventureWorks database in object explorer.

If you want to install AdventureWorks database version 2008, the methods works fine. There are additional sample database are available in the same package and they can be installed in similar way. If you want to install Northwind database follow my previous article SQL SERVER – 2005 NorthWind Database or AdventureWorks Database – Samples Databases – Part 2.

Let me know what is your experience while setting up sample database with SQL Server 2008. Additionally, let me know what you think about this in depth explanation of process of setting up sample database.

Reference : Pinal Dave (http://blog.SQLAuthority.com)

]]> http://blog.sqlauthority.com/2008/08/10/sql-server-2008-download-and-install-samples-database-adventureworks-2005-detail-tutorial/feed/ 42 pinaldave http://blog.sqlauthority.com/2008/07/27/sql-server-mssqlsystemresource-resource-database/ http://blog.sqlauthority.com/2008/07/27/sql-server-mssqlsystemresource-resource-database/#comments Sun, 27 Jul 2008 01:30:55 +0000 pinaldave http://sqlauthority.wordpress.com/?p=738 ]]>

Just a day ago I received following email

“Dear Pinal,

While I was exploring my computer in directory C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data I have found database mssqlsystemresource. What is mssqlsystemresource?

Thanks,

Joseph Kazeka”

Simple question like this are very interesting. mssqlsystemresource is Resource Database. It is read only database and contains system objects (i.e. sys.objects, sys.modules and other sys schema objects). Resource database does not contain any of user data.

The purpose of resource database is to facilitates upgrading to new version of SQL Server without any hassle. In previous versions whenever version of SQL Server was upgraded all the previous version system objects needs to be dropped and new version system objects to be created. With additional of resource database when SQL Server is to be upgraded to new version resource database has to be simple replaced as file system level (using OS). If new version is creating problems rolling back can be done very easily, just replace resource database with previous version.

For each SQL instance there is only one resource file. Resource file location should be same as master database. This databse is hidden from the user. It can not be viewed in Object Explorer or with the use of sp_helpDb or any other way. SQL Server itself can not backup this database. This database has to be backed up using filesystem backup.

Another interesting fact about Resource Database is its fixed ID 32767. Run following T-SQL script to see some of the properties of the Resource Database.

SELECT SERVERPROPERTY('ResourceVersion')
AS [Resource Version];
GO
SELECT SERVERPROPERTY('ResourceLastUpdateDateTime')
AS [Resource Last Update DateTime];
GO
SELECT OBJECT_DEFINITION(OBJECT_ID('sys.objects'))
AS [SQL Definitions];
GO

Reference : Pinal Dave (http://blog.SQLAuthority.com)

ERROR : 9004 An error occurred while processing the log for database.
If possible, restore from backup.
If a backup is not available, it might be necessary to rebuild the log.

If you receive above error it means you are in great trouble. This error occurs when database is attempted to attach and it does not get attached. I have solved this error using following methods. Hope this will help anybody who is facing the same error.

Microsoft suggest there are two solution to this problem.

1) Restore from a backup.

• Create Empty Database with same name and physical files (.ldf and .mdf).
• Shut down SQL Server.
• Replace the files which you want to attach with this new empty database files.
• Start SQL Server.
• Database will be in suspect mode which means so far everything going as it should be.
• Next is to put database in emergency mode. ALTER DATABASE <DatabaseName> SET EMERGENCY will change the database status to emergency.
• A database which is in emergency mode can be repaired with allowing some data loss. DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS will do the task.
• In this process some of the data may be lost but database will in working condition with most of the data retrieved from log.

2) Rebuild the log.

• Create database using CREATE DATABASE FOR ATTACH_REBUILD_LOG.
• This may fix the problem right away if database which is attempted to be attach is shut down properly. If database is corrupt it will be not restored correctly.
• Next DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS should be ran to bring back the database operational. This may loose some data but it may bring back database in working condition.
• In this option as log is rebuilt SQL Server does not use log file to retrieve any data. In this process none of the log operation like transaction rollback will work.

I prefer to use the first method if it works. First method has worked sevral time without any issue. Syntax of the CREATE database can be found on Book Online for further guidance.

Reference : Pinal Dave (http://blog.SQLAuthority.com)