Administration Guide

Database Directories

When a database is created, DB2 creates a separate subdirectory to store control files (such as log header files) and to allocate containers to default table spaces. Objects associated with the database are not always stored in the database directory; they can be stored in various locations, including devices.

The database is created in the instance that is defined by the DB2INSTANCE environment variable, or in the instance to which you have explicitly attached (using the ATTACH command). For an introduction to instances, see Using Multiple Instances of the Database Manager .

The naming scheme used on UNIX based systems is:

   specified_path/$DB2INSTANCE/NODEnnnn/SQL00001

The naming scheme used on OS/2 and the Windows operating systems:

   D:\$DB2INSTANCE\NODEnnnn\SQL00001

where

• specified_path is the optional, user-specified location to install the instance.
• NODEnnnn is the node identifier in a partitioned database environment. The first node is NODE0000.
• "D:" is a "drive letter" identifying the volume on which the root directory is located.

SQL00001 contains objects associated with the first database created, and subsequent databases are given higher numbers: SQL00002, and so on.

The subdirectories are created in a directory with the same name as the database manager instance to which you are attached when you create the database. (On OS/2 and the Windows operating systems, the subdirectories are created under the root directory for a volume that is identified by a "drive letter".) These instance and database subdirectories are created within the path specified on the CREATE DATABASE command, and the database manager maintains them automatically. Depending on your platform, each instance might be owned by an instance owner, who has system administrator (SYSADM) authority over the databases belonging to that instance.

To avoid potential problems, do not create directories that use the same naming scheme, and do not manipulate directories that have already been created by the database manager.

Database Files

The following files are associated with a database:

File Name

Description

SQLDBCON

This file stores the tuning parameters and flags for the database. Refer to Administration Guide: Performance for information about changing database configuration parameters.

SQLOGCTL.LFH

This file is used to help track and control all of the database log files.

Syyyyyyy.LOG

Database log files, numbered from 0000000 to 9999999. The number of these files is controlled by the logprimary and the logsecond database configuration parameters. The size of the individual files is controlled by the logfilsiz database configuration parameter.

With circular logging, the files are reused and the same numbers remain. With archive logging, the file numbers increase in sequence as logs are archived and new logs are allocated. When 9999999 is reached, the number wraps.

By default, these log files are stored in a directory called SQLOGDIR. SQLOGDIR is found in the SQLnnnnn subdirectory.

SQLINSLK

This file helps to ensure that a database is used by only one instance of the database manager.

SQLTMPLK

This file helps to ensure that a database is used by only one instance of the database manager.

SQLSPCS.1

This file contains the definition and current state of all table spaces in the database.

SQLSPCS.2

This file is a backup copy of SQLSPCS.1. Without one of these files, you will not be able to access your database.

SQLBP.1

This file contains the definition of all buffer pools used in the database.

SQLBP.2

This file is a backup copy of SQLBP.1. Without one of these files, you will not be able to access your database.

DB2RHIST.ASC

This file is the database history file. It keeps a history of administrative operations on the database, such as backup and restore operations.

DB2RHIST.BAK

This file is a backup copy of DB2RHIST.ASC.

Notes:

1. Do not make any direct changes to these files. They can only be accessed indirectly using the documented APIs and by tools that implement those APIs, including the command line processor and the Control Center.

2. Do not move these files.

3. Do not remove these files.

4. The only supported means of backing up a database or a table space is through the sqlubkp (Backup Database) API, including the command line processor and Control Center implementations of that API.