30.06.2013 Views

SQL Server Backup and Restore - Simple Talk

SQL Server Backup and Restore - Simple Talk

SQL Server Backup and Restore - Simple Talk

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

Chapter 9: File <strong>and</strong> Filegroup <strong>Backup</strong> <strong>and</strong> <strong>Restore</strong><br />

IF NOT EXISTS ( SELECT name<br />

FROM sys.filegroups<br />

WHERE is_default = 1<br />

AND name = N'Secondary' )<br />

ALTER DATABASE [File<strong>Backup</strong>sTest] MODIFY FILEGROUP [Secondary] DEFAULT<br />

GO<br />

Listing 9-3: A template for creating a multi-filegroup database.<br />

Crucially, we can now dictate, to a greater or less degree, what data gets put in which<br />

filegroup. In this example, immediately after creating the database, we have stipulated<br />

the SECONDARY filegroup, rather than the PRIMARY filegroup, as the default filegroup for<br />

this database. This means that our PRIMARY filegroup will hold only our system objects<br />

<strong>and</strong> data (plus pointers to the secondary data files). By default, any user objects <strong>and</strong> data<br />

will now be inserted into one of the data files in the SECONDARY filegroup, unless this was<br />

overridden by specifying a different target filegroup when the object was created. Again,<br />

the fact that we have multiple data files means that we can back each file up separately, if<br />

the entire database can't be backed up in the allotted nightly window.<br />

There are many different ways in which filegroups can be used to dictate, at the file level,<br />

where certain objects <strong>and</strong> data are stored. In this example, we've simply decided that the<br />

PRIMARY is for system data, <strong>and</strong> SECONDARY is for user data, but we can take this further.<br />

We might decide to store system data in PRIMARY, plus any other data necessary for the<br />

functioning of a customer-facing sales website. The actual sales <strong>and</strong> order data might be<br />

in a separate, dedicated filegroup. This architecture might be especially beneficial when<br />

running an Enterprise Edition <strong>SQL</strong> <strong>Server</strong>, where we can perform online piecemeal<br />

restores. In this case, we could restore the PRIMARY first, <strong>and</strong> get the database back<br />

online <strong>and</strong> the website back up. Meanwhile we can get to work restoring the other,<br />

secondary filegroups.<br />

We might also split tables logically into different filegroups, for example:<br />

• separating rarely-used archive data from current data (e.g. current year's sales data in<br />

one filegroup, archive data in others)<br />

300

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!