Contraste de las hipótesis específicas

The early 1980’s opened the door for relational database management systems (RDBMSs). Since then, these have become so popular that most line-of-business applications being implemented today use RDBMSs. Some people predict that by the end of the century, relational databases will have been superseded by object databases. However, whether or not this prediction turns out to be accurate is of no immediate importance to those of us who must back up the data used by today's applications.

RDBMSs share a common set of principles and, conceptually, similar logical and physical structures. Let us look at their fundamental structures, as shown in Figure 86: tables, table spaces, log files, and control files. Please note that although all RDBMS products are based on the same set of principles, they do not all use the same terminology or structures. For example, a table space in Informix is called a dbspace, and there is no table space concept in Sybase or Microsoft SQL Server. Log files in Oracle are called redo logs, while in Sybase they are called transaction logs.

It is important to understand the basic structures of RDBMSs so that you can put an effective backup and recovery strategy in place. You need to back up more than the database itself to ensure a successful recovery.

This book-formatted version is valid only for the date of publication.

The most recent version of this material is maintained on the ITSO Internet Web pages at:

http://www.redbooks.ibm.com/solutions/systemsmanagement/tsm/c_database.html Important: On-line Version Available!

Figure 86. Fundamental structure of a database

15.1.1 Tables

RDBMSs hold their data in the form of two-dimensional tables (sometimes also referred to as relations). These two-dimensional tables are easy for users to understand and manipulate. They also allow different users and applications to view and process the same data in different ways without requiring complex structures.

15.1.2 Table spaces

Table spaces are logical concepts that many RDBMSs use. When a user creates tables in an RDBMS that supports table spaces, the tables are created within a table space.Table spaces provide a convenient way of separating the user's view of data from some of the practical considerations associated with storing that data on disk. In many UNIX environments, table spaces can be implemented using either files or raw devices.

A table space provides the link between the logical view of a database that the user sees and the data files that the database uses to hold the data.

15.1.3 Log files

Most RDBMSs maintain details of updates to databases in log files. If, for some reason, a transaction that makes a change to the database fails to complete successfully, the RDBMS recovery procedure will use the log file to detect that an update may be only partially complete and to undo any changes that the

transaction made to the database.

RDBMSs use log files to record the changes made to databases. Log files often can be used to maintain database consistency in the event of an error or failure.

Different RDBMS suppliers use different terms for log files.

tables

control files log files

database

tables table spaces

Tivoli Storage Manager and databases 163 Some RDBMSs support the use of log files to perform forward recovery, also referred to as roll-forward recovery. Forward recovery takes advantage of the fact that log files hold details of all changes that have been made to the database, and therefore you do not necessarily need to undo changes, but instead can reapply changes. Log files can be used for forward recovery for both online and offline backup techniques.

Please note that RDBMSs have very complex schemes to manage log files, which we have somewhat oversimplified here. RDBMSs typically have multiple sets of log files to ensure the proper recording of database transactions. Most RDBMSs have a set of online log files as well as offline (or archived) log files.

Online log files are used to record the current database transaction activity, and at some point-in-time when the online logs become full, they become offline logs and are moved to another location. Typically backup applications backup the offline log files.

15.1.4 Control files

Each RDBMS needs to hold information about the physical structure of the database, such as which physical files are used by each table space and which is the current log file. We call this information control data. Some RDBMSs (for example, Oracle) hold this data in separate files. Others (for example, Informix and Sybase) hold it within the database itself.

We use the term control files to refer to files that hold control data. For those RDBMSs that hold control data in separate files, you need to define policies for backing up and restoring those files.

15.1.5 Initialization parameter and configuration files

All RDBMSs provide a range of options. Some are set permanently, and others can be modified even when a database is in use (running). Some options allow you to tune the performance of the database; others allow you to specify how you want logging, for example, to be implemented. It is often more convenient to specify the options you require when you start up the database. Most RDBMSs allow you to specify (at database startup time) a file that contains a list of how you want these options set initially. We call these files initialization parameter files.

Sometimes we abbreviate and call them initialization files or parameter files.

Installations may have multiple databases, and these databases may have multiple initialization parameter files. One reason for having multiple initialization parameter files for a single database might be to optimize performance for different circumstances. For example, you may decide to allocate one set of values when the database is used for batch processing and another set when it is used for online transactions. Although some of the options are set differently for each situation, many will be the same. Some RDBMSs allow you to specify options that are common to multiple initialization parameter files in configuration files. Instead of repeating all options and their values in each of the initialization parameter files you can select the configuration file that contains the options that you want to use.

You need to define policies for backing up and restoring both initialization parameter files and configuration files.