What's the best network storage for databases?


This article can also be found in the Premium Editorial Download "Storage magazine: .NET server storage: Friendly or not?."

Download it now to read this article plus other related content.

Mapping tablespaces to storage
The size of the database and the hours it needs to be live can decide what storage and recovery methods to use. As the size of a database grows, its backup window decreases proportionately. It's not possible on many databases to conduct a cold backup copy; as a result a number of technologies have to be implemented to ensure a hot backup. While the database vendors and backup companies have done a lot of work to make database backup and recovery more reliable, generally speaking it can still be a difficult, dicey process.

Database systems are logically organized as tablespaces. It's well beyond the scope of this article to discuss database organization other than to highlight the fact that tablespaces are the logical containers that hold the information in a database. Storage designs that map tablespaces to unique storage locations or SAN addresses allow storage management tools to be used and processes to be built that don't have to deal with the internal complexity of the database, but instead can work on large pieces of the databases as discrete entities.

Tablespaces can be mapped directly to LUNs using either raw partition or file system storage. To map a tablespace to a LUN using a file system, the file system will be created to manage the LUN's address space, even if it only has a single user file in it (the tablespace file). This way, if each tablespace in

Requires Free Membership to View

a database occupies its own dedicated LUN, block-level storage management tools such as backup and mirroring can be applied to create redundant copies of the tablespace without impacting the performance or operations of other tablespaces in the database.

In general, it's a good idea to leave plenty of storage capacity available for growth of the tablespaces. Even so, there will come a time when a database tablespace runs out of storage capacity and you will need to add more space. This is a situation where you may be better off using larger storage subsystems that supports many LUNs. With larger subsystems, it's easy to assign additional capacity simply by addressing the new LUN through an existing connection in the SAN. If you don't have the ability to add a LUN in an existing subsystem port, then you'll need to use additional switch and subsystem ports. For this reason, it's always a good idea to have capacity expansion ports reserved in your switches.

After the network addressing and connectivity issues are settled, the new storage space can be integrated with the database in one of two basic ways. The first way is to virtualize the storage by adding the new capacity to the old and then grow the size of the file system. Second, you can create an empty, new, larger raw partition or file system and copy all the data into it, turning off the old partition or file system when you are done.

Managing database storage through the log files
Whether or not the database uses a file system, there may still be log files that are written to a file system. These log files are used by database administrators to re-assemble the database should some disaster occur, which could cause the database to stop suddenly without a proper system shutdown process. Log files are also used to update a remote copy of the database by playing back the contents of the log file and updating the remote copy of the database. The key is ensuring that the log file contains all the changes made since the last version was completed and that all log files can be safely stored in case they are needed.

There are usually multiple log files that are used in a regular rotation. When the first one fills, the next one starts to fill and when that one fills, the next one starts, and so on. Eventually, the cycle wraps and the first log file is overwritten. This approach gives administrators time to backup and copy the log files on a regular schedule.

Because log files contain complete update information about the database and because they can be used so many different ways, it's always a good idea to give database log files special attention. One way to do this is to dedicate a LUN to the log files. This makes the log file data much easier to locate and it also allows specialized file and storage management techniques, including special backup processes and mirroring. For instance, the log files can be mirrored to a remote location where they can be applied to a remote copy of the database. If the mirroring process fails, the log files can be copied from backup tapes or replicated through another process to the remote site.

The point is that the detailed tablespace I/O doesn't have to be mirrored as long as the log files can be copied consistently without errors. This can have a huge impact on remote mirroring operations. The time involved in mirroring all tablespace I/O operations can significantly slow down the performance of the database. Instead, mirroring and replicating the log files significantly cuts down on the communications costs as well as maintaining expected performance levels.

This was first published in August 2002

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: