Administration Guide

Database Physical Directories

When a database is created, the database manager 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 directly on devices.

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

The naming scheme used on UNIX platforms is

   specified_path/$DB2INSTANCE/NODEnnnn/SQL00001

The naming scheme used on Intel platforms is

   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 where 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 are creating the database. (On Intel platforms, the subdirectories are created under the root directory on a given volume which is identified by a "drive letter".) These instance and database subdirectories are created within the path specified in 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 Physical Files

The following files are found within the 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 logsecond configuration parameters. The size of the individual files is controlled by the logfilsiz configuration parameter.

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

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

SQLINSLK

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

SQLTMPLK

This file is used to help ensure that a database is only used by 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 copy of SQLSPCS.1, and is created for protection in case SQLSPCS.1 fails. Without one of these files, you will not be able to access your database.

SQLBP.1

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

SQLBP.2

This file is a copy of SQLBP.1 and is created for protection in case SQLBP.1 fails. 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 when performing backups and restoring a backup.

DB2RHIST.BAK

This file is a backup copy of DB2RHIST.ASC.

Notes:

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 commands and the graphical Control Center.
Do not remove these files.
Do not move these files.
The only supported means of backing up a database or table space is through the BACKUP API, including the command line processor and Control Center implementations of that API.

[ Top of Page | Previous Page | Next Page | Table of Contents | Index ]

[ DB2 List of Books | Search the DB2 Books ]