• No results found

Developing your SnapManager data configuration plan

In document SnapManager for SQL Server (Page 124-133)

Developing your SnapManager data configuration plan

After you determine how many LUNs you need for your SnapManager

configuration and what data those LUNs hold, use the information in this section to develop your SnapManager data configuration plan and prepare storage system volumes and LUNs for use with SnapManager. This entails calculating and recording the required sizes for the LUNs, which also determines the sizes of the volumes that contain the LUNs. Use the information you record in your

SnapManager data configuration plan to create or modify the storage system volumes and LUNs on your storage system.

The information you record in your SnapManager data configuration plan could be used if problems arise later with your system. Knowing the volume and drive for each of your LUNs can aid the diagnosis and resolution of many potential issues.

To create your SnapManager data configuration plan, complete the following steps.

Step Action

1 For each LUN you need, record the following information:

Purpose

Size

Volume and qtree

Assigned drive letter or mountpoint

For details about calculating LUN size for a database, see “LUN size calculations” on page 115

Chapter 6: Configuration and volume mount points 113

Assessing volume size

The following topics describe how to estimate the storage requirements on your storage system:

“Storage system volume sizing requirements” on page 113

“LUN size calculations” on page 115

“Overall storage system volume requirements for a transaction log” on page 116

“Criteria for estimating the amount of space required for a transaction log”

on page 116

“Initial sizing guidelines for new environments” on page 117 For more details about how to evaluate your space requirements, see the SnapDrive Installation and Administration Guide for your version of SnapDrive.

Storage system volume sizing requirements

In addition to the space required for your LUNs, free space on the storage system volume is required to store data that changed between Snapshot copies and the active file system of the LUN. The storage system volume also requires space to store metadata. Allowing for this more space ensures that making multiple Snapshot copies does not encroach on the LUN objects in the volume.

When you create storage system volumes to hold LUNs, you must take into account the following SnapDrive requirements:

2 For each volume you need to store LUNs, record the following information:

Location (storage system name)

Purpose

Type (traditional or flexible)

Fractional reserve (%)

Automatic Snapshot copy deletion setting (enabled or disabled)

LUNs contained

Volume autogrow (enabled or disabled) Step Action

114 Developing your SnapManager data configuration plan

To create Snapshot copies, the volume storing the LUN must be at least twice the size of that LUN.

A storage system volume must have at least twice the capacity of all the LUNs it contains.

The volume must have enough free space for the number of Snapshot copies you intend to keep online.

In sizing volumes, take into account how many days’ worth of Snapshot copies are online at the same time.

The first Snapshot copy lock uses disk space equal to the LUN object size itself (therefore, double the requirement). More Snapshot copies increase the amount of required disk space.

Chapter 6: Configuration and volume mount points 115

LUN size calculations

To ensure that you create volumes to meet these requirements, you must calculate the potential size of your LUNs. The following formulas work best to calculate both the SQL Server database size (LUN size) and the volume size.

Example: Given these requirements, the following parameters can be expressed by the formula shown after them:

The initial database size is 100 GB.

The database growth rate is 10 percent per month.

The change rate of the current database is 15 percent per month.

The Snapshot copy requirement is four Snapshot copies per day with a total of 12 Snapshot copies (three days’ worth of Snapshot copies).

The default RAID group size is 72 GB x 9 drives.

You only want to expand the volume every six months.

Performance is important, that wants to prevent the volume from being fragmented over time and is willing to allocate 20 percent free space per disk drive.

Calculations:

1. The database size after growth is about 177 GB (rounded up to 180 GB for the LUN size).

Note

If the database is growing by 10 percent per month, this does not mean that the database is growing by the same 10 GB every month. Rather, the database grows to about 110 GB in the first month (100 GB x 1.1) and 121 GB in the second month (110 GB x 1.1).

In general, the formula is as follows:

<projected future database size>=<present database size> x (<1 + <monthly growth rate percentage in decimal>+<monthly change rate percentage expressed in decimal>)<number of months>

2. Approximately 27 GB of the database changes per month after six months.

3. Minimum space requirements after six months are (180 GB x 2) + (0.15 GB x 12) = 362 GB.

Note

You should round up the final space requirements listed in Step 1 to determine the volume size you want to create. For example, round up 368.4 GB to 370 when you are creating your volume size.

116 Developing your SnapManager data configuration plan

4. A 72-GB disk drive has about 68 GB of usable volume space, and because 20 percent is allocated for permanent free space, then only 54 GB is usable per disk drive. Therefore, 13 disk drives are needed for data and two disk drives are needed for parity.

Overall storage system volume requirements for a transaction log

The storage system volume requirements for a transaction log require an understanding of the following factors:

The rate of transactions that modify database tables

The size of the transactions

The frequency of the transaction log backup Note

The key to sizing correctly is to monitor usage over time.

Example: With a table that contains three columns with two indexes defined on column one and column three, for each update operation that adds one data row, there are at least three operations:

The actual update to the row (including any old data) is logged.

An entry is created for the first index that needs to be updated.

An entry is also created for the second index that needs to be updated.

Note

There might be extra entries created if a new index page or data page needs to be created to accommodate the row in the table.

Criteria for estimating the amount of space required for a transaction log

The quantity of what is logged is dependent on the underlying table structure and the database activity on the SQL Server.

If the database already exists, then the current transaction log size can be used as-is or the transaction log activities can be monitored from the performance monitor with some SQL Server database metrics:

Log file size (in KB)

Log file used size (in KB)

Log bytes flushed per second

Chapter 6: Configuration and volume mount points 117

Initial sizing guidelines for new environments

If you have set up a new environment, you might want to consider the following initial sizing guidelines and monitor the used size before and after the transaction log is backed up.

Note

The following recommendations are also applicable when you specify the size of the SnapInfo directory.

The recommendations are as follows:

The transaction log volume size should be 20 percent of the initial database size.

The minimum transaction log size is 1 MB (default).

The maximum transaction log size is 100 MB.

Note

The insert, update, and delete functions increases a transaction log file’s size.

118 Developing your SnapManager data configuration plan

Overview of the database migration procedure

The following steps summarize the migration of SQL Server database files:

1. The operator uses the Configuration wizard to specify the databases to be migrated and the LUNs to which the databases are to be migrated.

Note

If the databases you intend to backup and restore using SnapManager are already on LUNs, and their configurations meet the requirements for operating with SnapManager, then you do not need to migrate them. Instead, use the Configuration wizard only to set up the SnapInfo directory. No databases will be taken offline or copied.

Note

SnapManager for SQL 5.0 provides the capability to back up a read-only database. Use the Configuration wizard to migrate the read-only database.

However, you cannot select the Run UPDATE STATISTICS option for the read-only database. During the migration process, SnapManager for SQL skips this option only for the read-only database. After migration, you can restore and backup the read-only database like any other normal database.

2. If you specified databases to be migrated to LUNs, the Configuration Wizard does the following:

a. Detaches the specified databases.

b. Copies the databases to the specified LUNs and sets up a SnapInfo directory.

SnapManager detaches SQL Server user databases before migrating them to LUNs.

SnapManager also stops the SQL Server while migrating SQL Server system databases to LUNs.

Migrating SQL Server databases causes them to be taken offline during the copy operation.

In a Windows cluster, if you migrate a database file to a LUN that does not have dependency set on the SQL Server cluster resource,

SnapManager places all resources directly or indirectly dependent on that LUN into an offline state while it adds the dependency on the cluster resource.

c. Attaches the databases.

Chapter 6: Configuration and volume mount points 119

If a database copy or a database attach fails, SnapManager attaches the original database file to the SQL Server.

d. Deletes the old database files (if this was specified).

3. The Configuration wizard sets up the SnapInfo directory structure per your specifications:

Single SnapInfo Directory: Specify one SnapInfo directory for all SQL Server instances and their associated databases.

Advanced SnapInfo Directories: For each SQL Server instance, specify a default SnapInfo directory for all the databases owned by that instance.

If you have multiple databases that reside on one or two LUNs, specify a common SnapInfo directory for those databases.

If you want to place the SnapInfo directory for an individual database on a LUN other than in the default location for that SQL Server instance, the Configuration Wizard supports the creation of that SnapInfo directory as well.

4. The Configuration wizard reminds the operator to immediately back up the migrated databases.

Prerequisites for migrating

databases to LUNs

Before you migrate your SQL Server databases, you must verify that your environment is in the proper state.

You must use SnapDrive to create the following LUNs:

One or more LUNs for the SQL Server database

One or more LUNs for the SnapInfo files

For resource planning information, see Chapter 6, “Preparing to Migrate SQL Server Databases,” on page 94. For detailed instructions about creating LUNs, see the SnapDrive Installation and Administration Guide for your version of SnapDrive.

The databases to be migrated must not be in use. This includes both system databases and user databases.

For information about how to select that users are not connected to a database, see your SQL Server documentation.

The SQL Server databases to be migrated and the LUNs to which they will be migrated must conform to SnapManager requirements, which include the following:

120 Developing your SnapManager data configuration plan

The LUNs used for the SQL Server database files cannot store any files other than those placed there by the SnapManager Configuration Wizard.

The LUN used for the SnapInfo director cannot store any files other than those placed there by the SnapManager Configuration Wizard.

For more information, see “SQL Server database configurations to avoid” on page 97.

Migrating system and resource databases

Use the Configuration wizard to move the system databases to LUNs. While the Configuration wizard is migrating SQL Server system databases to LUNs, the SQL Server is stopped by SnapManager.

Migrating SQL Server databases causes them to be taken offline during the move operation.

Run the SnapManager Configuration wizard to move the master database.

SnapManager for SQL also moves the resource database to the location where the master database is migrated.

Chapter 7: Using the SnapManager Configuration Wizard 121

7

In document SnapManager for SQL Server (Page 124-133)