《数据库系统》课程参考资料：DB2系统管理员指南 IBM DB2 Version 8 Administrator Guide（1/3）Planning.pdf_P31-P35

Each database includes recovery logs, which are used to recover from application or system errors. In combination with the database backups, they are used to recover the consistency of the database right up to the point in time when the error occurred The recovery history file contains a summary of the backup information that can be used to determine recovery options, if all or part of the database must be recovered to a given point in time. It is used to track recovery-related events such as backup and restore operations, among others. This file is located in the database directory. The table space change history file, which is also located in the database directory, contains information that can be used to determine which log files are required for the recovery of a particular table space Data that is easily recreated can be stored in a non-recoverable database. Th includes data from an outside source that is used for read-only applications, and tables that are not often updated, for which the small amount of logging does not justify the added complexity of managing log files and rolling forward after a restore operation. Non-recoverable databases have both the logretain and the userexit database configuration parameters disabled. This means that the only logs that are kept are those required for crash recovery These logs are known as active logs, and they contain current transaction data Version recovery using offline backups is the primary means of recovery for a non-recoverable database. (An offline backup means that no other application an use the database when the backup operation is in progress. )Such a the backup image was taken and rollforward recovery is not supported. er database can only be restored offline. It is restored to the state it was in when Data that cannot be easily recreated should be stored in a recoverable database. This includes data whose source is destroyed after the data is loaded, data that is manually entered into tables, and data that is modified by application programs or users after it is loaded into the database. Recoverable databases have either the logretain database configuration parameter set to "RECOVErY, the userexit database configuration parameter enabled, or both Active logs are still available for crash recovery, but you also have the archived logs, which contain committed transaction data. Such a database can only be restored offline. It is restored to the state it was in when the backup imag was taken. However, with rollforward recovery, you can roll the database forward(that is, past the time when the backup image was taken) by using the active and archived logs to either a specific point in time, or to the end of the active Recoverable database backup operations can be performed either offline or online(online meaning that other applications can connect to the database during the backup operation). Database restore and rollforward operations Chapter 1. Basic relational database concepts 21

Each database includes recovery logs, which are used to recover from application or system errors. In combination with the database backups, they are used to recover the consistency of the database right up to the point in time when the error occurred. The recovery history file contains a summary of the backup information that can be used to determine recovery options, if all or part of the database must be recovered to a given point in time. It is used to track recovery-related events such as backup and restore operations, among others. This file is located in the database directory. The table space change history file, which is also located in the database directory, contains information that can be used to determine which log files are required for the recovery of a particular table space. Data that is easily recreated can be stored in a non-recoverable database. This includes data from an outside source that is used for read-only applications, and tables that are not often updated, for which the small amount of logging does not justify the added complexity of managing log files and rolling forward after a restore operation. Non-recoverable databases have both the logretain and the userexit database configuration parameters disabled. This means that the only logs that are kept are those required for crash recovery. These logs are known as active logs, and they contain current transaction data. Version recovery using offline backups is the primary means of recovery for a non-recoverable database. (An offline backup means that no other application can use the database when the backup operation is in progress.) Such a database can only be restored offline. It is restored to the state it was in when the backup image was taken and rollforward recovery is not supported. Data that cannot be easily recreated should be stored in a recoverable database. This includes data whose source is destroyed after the data is loaded, data that is manually entered into tables, and data that is modified by application programs or users after it is loaded into the database. Recoverable databases have either the logretain database configuration parameter set to “RECOVERY”, the userexit database configuration parameter enabled, or both. Active logs are still available for crash recovery, but you also have the archived logs, which contain committed transaction data. Such a database can only be restored offline. It is restored to the state it was in when the backup image was taken. However, with rollforward recovery, you can roll the database forward (that is, past the time when the backup image was taken) by using the active and archived logs to either a specific point in time, or to the end of the active logs. Recoverable database backup operations can be performed either offline or online (online meaning that other applications can connect to the database during the backup operation). Database restore and rollforward operations Chapter 1. Basic relational database concepts 21

must always be performed offline. During an online backup operation, rollforward recovery ensures that all table changes are captured and reapplied if that backup is restored. If you have a recoverable database, you can back up, restore, and roll individual table spaces forward, rather than the entire database. When you back up a table space online, it is still available for use, and simultaneous updates are recorded in the logs. When you perform an online restore or rollforward operation on a table space, the table space itself is not available for use until the operation completes, but users are not prevented from accessing tables in other table spaces. Related concepts: v “Crash Recovery” in the Data Recovery and High Availability Guide and Reference v “Version Recovery” in the Data Recovery and High Availability Guide and Reference v “Rollforward Recovery” in the Data Recovery and High Availability Guide and Reference v “Data Links server file backups” in the Post V8 GA v “Failure and recovery overview” in the DB2 Data Links Manager Administration Guide and Reference Related reference: v “Recovery History Retention Period configuration parameter - rec_his_retentn” in the Administration Guide: Performance v “DB2 Data Links Manager system setup and backup recommendations” in the DB2 Data Links Manager Administration Guide and Reference Security To protect data and resources associated with a database server, DB2® uses a combination of external security services and internal access control information. To access a database server, you must pass some security checks before you are given access to database data or resources. The first step in database security is called authentication, where you must prove that you are who you say you are. The second step is called authorization, where the database manager decides if the validated user is allowed to perform the requested action, or access the requested data. Related concepts: v “Authentication” on page 23 v “Authorization” on page 24 22 Administration Guide: Planning

Authentication Authentication of a user is completed using a security facility outside of DB2. The security facility can be part of the operating system, a separate product or, in certain cases, may not exist at all. On UNIX® based systems, the security facility is in the operating system itself. The security facility requires two items to authenticate a user: a user ID and a password. The user ID identifies the user to the security facility. By supplying the correct password (information known only to the user and the security facility) the user’s identity (corresponding to the user ID) is verified. Once authenticated: v The user must be identified to DB2® using an SQL authorization name or authid. This name can be the same as the user ID, or a mapped value. For example, on UNIX based systems, a DB2 authid is derived by transforming to uppercase letters a UNIX user ID that follows DB2 naming conventions. v A list of groups to which the user belongs is obtained. Group membership may be used when authorizing the user. Groups are security facility entities that must also map to DB2 authorization names. This mapping is done in a method similar to that used for user IDs. DB2 uses the security facility to authenticate users in one of two ways: v DB2 uses a successful security system login as evidence of identity, and allows: – Use of local commands to access local data – Use of remote connections where the server trusts the client authentication. v DB2 accepts a user ID and password combination. It uses successful validation of this pair by the security facility as evidence of identity and allows: – Use of remote connections where the server requires proof of authentication – Use of operations where the user wants to run a command under an identity other than the identity used for login. DB2 UDB on AIX® can log failed password attempts with the operating system, and detect when a client has exceeded the number of allowable login tries, as specified by the LOGINRETRIES parameter. Related concepts: v “Security” on page 22 Chapter 1. Basic relational database concepts 23

Authorization Authorization is the process whereby DB2 obtains information about an authenticated DB2 user, indicating the database operations that user may perform, and what data objects may be accessed. With each user request, there may be more than one authorization check, depending on the objects and operations involved Authorization is performed using DB2 facilities. DB2 tables and configuration files are used to record the permissions associated with each authorization name. The authorization name of an authenticated user, and those of groups to which the user belongs, are compared with the recorded permissions. Based comparison DB2 decides whether to allow the requested access There are two types of permissions recorded by DB2: privileges and authority levels. A privilege defines a single permission for an authorization name, enabling a user to create or access database resources. Privileges are stored in the database catalogs. Authority levels provide a method of grouping privileges and control over higher-level database manager maintenance and utility operations. Database-specific authorities are stored in the database catalogs; system authorities are associated with group membership, and are stored in the database manager configuration file for a given instance Groups provide a convenient means of performing authorization for a collection of users without having to grant or revoke privileges for each user individually. Unless otherwise specified, group authorization names can be In general, group membership is considered for dynamic sQl and purposes used anywhere that authorization names are used for authorization purposes non-database object authorizations(such as instance level commands and utilities), but is not considered for static SQL. The exception to this general case occurs when privileges are granted to PUBLIC: these are considered when static SQL is processed. Specific cases where group membership does not apply are noted throughout the DB2 documentation, where applicable Related concepts Authorization and privileges"in the SQL Reference, Volume 1 Privileges, authorities, and authorization"in the Administration Guide: implementation 24 Administration Guide: Planning

Authorization Authorization is the process whereby DB2® obtains information about an authenticated DB2 user, indicating the database operations that user may perform, and what data objects may be accessed. With each user request, there may be more than one authorization check, depending on the objects and operations involved. Authorization is performed using DB2 facilities. DB2 tables and configuration files are used to record the permissions associated with each authorization name. The authorization name of an authenticated user, and those of groups to which the user belongs, are compared with the recorded permissions. Based on this comparison, DB2 decides whether to allow the requested access. There are two types of permissions recorded by DB2: privileges and authority levels. A privilege defines a single permission for an authorization name, enabling a user to create or access database resources. Privileges are stored in the database catalogs. Authority levels provide a method of grouping privileges and control over higher-level database manager maintenance and utility operations. Database-specific authorities are stored in the database catalogs; system authorities are associated with group membership, and are stored in the database manager configuration file for a given instance. Groups provide a convenient means of performing authorization for a collection of users without having to grant or revoke privileges for each user individually. Unless otherwise specified, group authorization names can be used anywhere that authorization names are used for authorization purposes. In general, group membership is considered for dynamic SQL and non-database object authorizations (such as instance level commands and utilities), but is not considered for static SQL. The exception to this general case occurs when privileges are granted to PUBLIC: these are considered when static SQL is processed. Specific cases where group membership does not apply are noted throughout the DB2 documentation, where applicable. Related concepts: v “Authorization and privileges” in the SQL Reference, Volume 1 v “Privileges, authorities, and authorization” in the Administration Guide: Implementation v “Security” on page 22 24 Administration Guide: Planning

Chapter 2 Parallel database systems Data partitioning a database partition is a part of a database that consists of its own dat ment DB2 extends the database manager to the parallel, multi-node environ ndexes, configuration files, and transaction logs. A database partition is sometimes called a node or a database node A single-partition database is a database having only one database partition. All data in the database is stored in that partition. In this case database partition groups, while present, provide no additional capability a partitioned database is a database with two or more database partitions Tables can be located in one or more database partitions. When a table is in a database partition group consisting of multiple partitions, some of its rows are stored in one partition, and other rows are stored in other partitions. Usually, a single database partition exists on each physical node, and the processors on each system are used by the database manager at each database partition to manage its part of the total data in the database Because data is divided across database partitions, you can use the power of multiple processors on multiple physical nodes to satisfy requests for nformation. Data retrieval and update requests are decomposed automatically into sub-requests, and executed in parallel among the applicable database partitions. The fact that databases are split across database partitions is transparent to users issuing SQL statements User interaction occurs through one database partition, known as the Partition as the application, or in the case of a remote application, the o coordinator node for that user The coordinator runs on the same databas database partition to which that application is connected. Any database partition can be used as a coordinator node DB2 supports a partitioned storage model that allows you to store data across several database partitions in the database. This means that the data is physically stored across more than one database partition, and yet can be accessing data in a partitioned database do not need to be aware of theusers accessed as though it were located in the same place. Applications and hysical location of the data. c Copyright IBM Corp. 1993-2002

Chapter 2. Parallel database systems Data partitioning DB2® extends the database manager to the parallel, multi-node environment. A database partition is a part of a database that consists of its own data, indexes, configuration files, and transaction logs. A database partition is sometimes called a node or a database node. A single-partition database is a database having only one database partition. All data in the database is stored in that partition. In this case database partition groups, while present, provide no additional capability. A partitioned database is a database with two or more database partitions. Tables can be located in one or more database partitions. When a table is in a database partition group consisting of multiple partitions, some of its rows are stored in one partition, and other rows are stored in other partitions. Usually, a single database partition exists on each physical node, and the processors on each system are used by the database manager at each database partition to manage its part of the total data in the database. Because data is divided across database partitions, you can use the power of multiple processors on multiple physical nodes to satisfy requests for information. Data retrieval and update requests are decomposed automatically into sub-requests, and executed in parallel among the applicable database partitions. The fact that databases are split across database partitions is transparent to users issuing SQL statements. User interaction occurs through one database partition, known as the coordinator node for that user. The coordinator runs on the same database partition as the application, or in the case of a remote application, the database partition to which that application is connected. Any database partition can be used as a coordinator node. DB2 supports a partitioned storage model that allows you to store data across several database partitions in the database. This means that the data is physically stored across more than one database partition, and yet can be accessed as though it were located in the same place. Applications and users accessing data in a partitioned database do not need to be aware of the physical location of the data. © Copyright IBM Corp. 1993 - 2002 25