BACKUP and RESTORE in SQL Server -- Full Backups

This article covers the basics of full backup backups and restores in SQL Server. The examples are from SQL Server 2005 however it applies to SQL Server 2000 and SQL Server 2005. This is a very basic article covering full database backups, database restores and the simple and full recovery models. 

In a typical installation SQL Server stores its data in two files. One has an MDF extension and stores the data itself and the other has an LDF extension and stores the transaction log. You can configure SQL Server to have multiple data files and multiple transaction log files if you'd like but that's beyond the scope of this article. When SQL Server processes a transaction it goes through the following steps:

1. It writes what it's going to do to the transaction log.
2. It makes the change to the data file. This change is typically made on the in-memory copy of that portion of the data file.
3. It writes to the log that the transaction is committed.
4. The CHECKPOINT process writes the portion data file associated with the transaction to disk. This might happen anywhere from seconds to minutes after the step above.
5. It writes to the log that the transaction is "hardened".

The simplest type of backup is the Full Backup. The screen shots below are from SQL Server 2005's Management Studio (SSMS). SQL Server 2000's Enterprise Manager (EM) is very similar. In SSMS you right click on the database and choose Tasks -> Backup to bring up the window shown below.
At a minimum you need to verify three things on this screen. First, that the correct database is selected. Second, that the backup type is set to FULL. Finally you need to choose the backup file name. On the Options tab you can specify whether SQL Server should replace or append the backup to the backup file. Keep in mind that the backup file is relative to where SQL Server is installed and not where you're running SSMS.



If you want to issue a backup statement yourself you can use SSMS to script it out for you. Click the Script button at the top of the dialog box and SSMS will generate this SQL statement for you:

BACKUP DATABASE [AdventureWorks] TO  
 DISK = N'\\nas\Backup\L40\SQL2005

\AdventureWorks_backup_200702120215.bak' 
 WITH NOFORMAT, NOINIT, 

NAME = N'AdventureWorks-Full Database Backup', 
 SKIP, NOREWIND, NOUNLOAD,  STATS = 10

You can see how these options map back to the dialog box. The NOINIT clause is what says to append the backup to the existing backup file. The other option is INIT which will overwrite the backup file. The BACKUP statement will create a single file with a BAK extension that contains what is in your data file and log file. You can backup the database while SQL Server is running and people can still use the database. It might be a little bit slower depending on your disk throughput.
Restoring a database is a little more complicated. Right-clicking on Databases in SSMS bring up a dialog box like this:



I've already changed the database name to AdventureWorksNew. I clicked the From Device radio button and navigated to my backup file. If you're restoring on the same computer where the original database resides you can just leave the From Database radio button selected and choose the database. It will automatically select the backup. Clicking on the options tab brings us to the second part of the dialog:



Notice that it wants to restore the two file names right on top of the file names for AdventureWorks. SQL Server won't actually let you do that unless you check the "Overwrite the existing database" checkbox above. You'll need to edit those filenames to change the name. If I script this statement out it gives me this:

RESTORE DATABASE [AdventureWorksNew] 
 FROM  DISK = N'\\nas\Backup\L40\SQL2005

\AdventureWorks_backup_200702120215.bak' 
 WITH  FILE = 1,  
 MOVE N'AdventureWorks_Data' TO

 N'C:\Data\MSSQL.1\MSSQL\Data\AdventureWorksNew_Data.mdf',  
 MOVE N'AdventureWorks_Log' TO 

N'C:\Data\MSSQL.1\MSSQL\Data\AdventureWorksNew_Log.ldf',  
 NOUNLOAD,  STATS = 10

Notice the MOVE commands have the new file name that I typed in.
One thing to be aware of is the SQL Server Recovery Model. If you right-click on a database and choose Properties and then click the Options tab you'll see the recovery model as the second item listed. The two main settings for this are Simple and Full. In Simple Recovery SQL Server doesn't keep transactions in the transaction log that have already been "hardened" to disk. They are automatically removed and the space in the file is reused. In Full Recovery mode SQL Server keeps every transaction in the transaction log file until you explicitly backup the transaction log. Simple Recovery mode is better for developers or servers that are only backed up nightly. In Full Recovery mode you'll need to do transaction log backups which I'll cover in a future article. If you see your database growing larger and larger the most likely cause is a growing transaction log. To resolve this, change the recovery model to Simple, backup the database and then shrink the database. 
You can shrink the database by right-clicking on the database and choosing Tasks -> Shrink -> Database and then clicking OK.
When you create a database, SQL Server starts with a copy of the "model" database. If you set the Recovery Model of the "model" database to Simple all future databases will start out in Simple Recovery mode.

Error Message when dumping to hard drive backup device

 

Justin writes "When I dump to a hard drive backup device, several of my database backups fail with the following information (in the event log of NT 4.0) . . .

Event ID: 17055
Source: MSSQLServer
Type: Information
Category: Kernel
Description: 3266: The Microsoft Tape Format (MTF) soft filemark database on backup device 'POD01_DUMP' cannot be read, inhibiting random access.

Basically, this error message reads like a tape drive problem, but I am dumping my files to hard drive using the "Dump Database....with INIT" commands within a job to do it. Technet has nothing to say on the matter, except to indicate that this an error of severity type 10, and I have also checked with other SQL sources to no avail.

After a couple of emails back and forth on this for more details the answer actually came from Spyder (Brent). Apparently the backup process was interrupted and this caused the BAK file to become corrupt. This also made it impossible to restore from the BAK file which was another reported symptom. The BAK files were deleted and recreated and all works fine now. Credit to Spyder.

 

 Posted By Bill Graziano

Getting started with SSIS - Part 1: Introduction to SSIS

Jan 4 2012 12:00AM by neham   

SSIS is a tool used for ETL. Before we talk on SSIS, let me walk you through what is ETL.
ETL stands for Extract Transform and Load. These are simple day to day words we use in our daily lives. The figure below depicts ETL in real world scenario.

E - Extract data from various homogeneous or non-homogeneous source systems. Data could be stored in any of the following forms though not limited to them: Flat file, Database, XML, Web queries etc. When we can have sources of such variety, the job of extraction is to fetch the data from these sources and make it available for the next step.
T - Transform Data: As already discussed that the data are coming from various sources and we cannot assume that the data is structured in the same way across all the sources. Therefore, we need to transform the data to a common format so that the other transformations can be done on them. Once we have the data we need to perform various activities like:

• Data cleansing
• Mandatory check
• Data type check
• Check for foreign key constraints
• Check for business rules and apply business rules
• Creation of surrogate keys
• Sorting the data
• Aggregating the data
• Transposing the data
• Trim the data to remove blanks.

The list can go on as the business requirements get complex day by day and hence the transformations get complex. While transformations are on, we need to log the anomalies in data for reporting and corrective action to be taken.
L Load Data: Once the transformations are done and the data takes the form as per the requirement, we have to load the data to the destination systems. The destinations can also be as varied as the sources. Once the data reaches the destination, it is consumed by other systems, which either stores it as historical data, generate reports out it, build modes to take business decisions etc.
SSIS stands for SQL Server Integration Services. Microsoft introduced Business Intelligence Suite, which includes SSIS, SSAS (SQL Server Analysis Server) and SSRS (SQL Server Reporting Services). Now what’s this Business Intelligence (BI)? Let me take some time to explain that. As the name suggests, it helps Business run across the globe. It provides the business with data and ways to look into the data and make business decisions to improve the business.
So how do the 3 products work in the BI world or how are they organized? To start any business analysis we need data, and as I explained earlier, ETL would be used here to get the data from varied sources and put the data to tables or create Cubes for data warehouse. To do this, we make use of SSIS. Once we have the data with us, SSAS comes into picture to organize the data and store them to cubes.
Next, we need to report the data so that it makes sense to the end user. This is where SSRS comes into picture for report generation.
The order of SSIS and SSAS could change, as both can come first. Having said this, SSIS makes the backbone of this entire domain as all the data is assembled using SSIS.
Now we dive in to what exactly SSIS is. Is it another coding language? The answer to the question is NO. SSIS is not another coding language. In fact very little coding is required in SSIS that too in very few cases. SSIS is a tool used for ETL. It is based on the paradigm shift where we need to focus more onto the business requirement and less on the actual coding to achieve the goals.
SSIS is a visual tool with drag and drop feature, which enables us to create SSIS, packages to perform ETL in a very short amount of time. The development time is widely reduced as compared to legacy systems where each aspect of ETL had to be coded and then of course, tested. Once the package is created, the visual look is good enough to give us an idea of what the ETL is doing.
SSIS provides us many tasks and transforms which help us build our ETL packages. A few examples would be Execute SQL Task which enables us to execute any T-SQL script from SSIS, Send Mail Task which enables us to send mail to any recipient. Likewise, there are lots of tasks and transforms available in SSIS to take care of most of the ETL scenarios that you can think of.
Note: I will explain what is Tasks and transforms in later chapters.
However, what if I have a scenario that cannot be accommodated in the existing tasks and transforms? SSIS has an answer to that too. In that case you can use the entire .NET library and code in either C# or VB to achieve your requirement. Though such scenarios would be very few and even if required will be of very basic nature where you need to know the basics of any programming language to get going. Let’s say that you are not satisfied with the logging provided by SSIS, you can always go ahead and write code to log the errors or activities the way you choose. Taking this a step further, if you want this new type of logging in many packages, you could convert your code to create a custom component and add it to all SSIS packages. It will now work as any other task or transform for you. Is that not great!!!
Note: C# is available only in SSIS 2008 and not 2005.
Let us peep into a simple SSIS package and get to know how SSIS looks....

This is how an SSIS package looks and feels. I will get into the details of what you see above in the coming chapters.

Post by :::::Jan 4 2012 12:00AM by     neham