"Progressive DB2.DBA system Management, operation and application Case" (New) reading notes 3 variables affecting DB2 environment

"Progressive DB2.DBA system Management, operation and application Case" (New) Reading notes 3

Variables affecting the DB2 environment

Before we had successfully installed the DB2 V9.7 Enterprise Edition with the wizard installed on the Windows platform, now we are not in a hurry to make specific DB2 operations such as creating instances and databases, doing SQL operations, and so on. We should first of all DB2 this product has a general structural understanding, and then the specific operation. This can avoid in the process of operation due to trees trees and blind feeling, but also through each step of the specific operation to deepen the grasp of DB2 overall. To know that DB2 is a very complex (whether functional or product architecture) database management system, from the overall grasp, understanding DB2 is extremely important, must not be able to isolate the DB2 of the various components.

We should first establish the concept of "environment" (sometimes called "system"). "Environment" (or "system") refers to a specific DB2 installation (for example, before we successfully installed DB2, we can say that we have built a DB2 "environment" or "system" on the Windows platform). The use of DB2 is to store, manage, and assist in the analysis and processing of data; The purpose of installing DB2 is to utilize these features of DB2. That is, DB2 this DBMS provides us with a wide range of business data services that provide a powerful "work arena" for people to handle business data, so we call a DB2 installation an "environment". Since this "environment" function is very powerful, we can also use "system" to refer to it.

It is because of the complex and powerful structure of the DB2 environment that it is important to ensure that the environment always works in a normal and orderly manner and always provides the functions that people need. This work is usually done by the DBA. However, the DBA does not do this work in thin air. In fact, DBAs do this by using some of the tools that come with their own DB2 environment. That is, the DB2 environment is part of the business services that are used to provide business data to users, and part of it is used to provision and manage the DB2 environment itself. Because the DB2 environment provides self-management, self-configuring functionality, it enables DBAs to use and invoke this part of the functionality to achieve operational operations.

DB2 Environment Self-configuration tool has three basic: first, operating system environment variable two, DB2 profile registry variable three, configuration file parameters

The following are respectively described:

• Operating system Environment variables:

DB2 is our environment for dealing with business data, and it has built a powerful workspace for us. But don't forget, DB2 this environment is not floating in the air. Just as the building had to be built on land, DB2 the environment was built on a certain operating system. Therefore, the management of DB2 environment can not be separated from the operating system of this large environment. After successfully installing DB2, it should be noted that the environment variables of its operating system are not before the installation, these more operating system environment variables are to be configured later, to adjust the DB2 environment, one of the tools and means.

If all the tables in the DB2 are all stored in the same set, imagine what the situation is. In that case, many different applications will access the target table from the same large set when accessing the data, which is confusing and error-prone. Since all tables are at the same level, it means that all tables get the same DB2 environment. However, these tables are used by many different applications. Different applications have different levels of database environment performance requirements, because all tables enjoy the same DB2 environment performance, in order to meet the highest application database performance requirements, you must put DB2 performance to the highest. This is obviously a huge waste of resources for applications that are not as demanding as the performance of the database environment. This is due to the DB2 environment does not support polymorphism caused by the inconvenience and waste of resources. One solution is to define a DB2 environment configuration information file that corresponds to this table each time a new table is defined, specifying what kind of DB2 environment performance configuration to use when setting up a table. This solution has its drawbacks. The first is very cumbersome and a lot of space to store performance configuration information files. What's more, if you have concurrent access to tables that have different settings for multiple environment configuration information, the only DB2 environment will not know exactly which performance state to run. Therefore, the best solution is to allow different tables to be in different sub-environments, which can run independently of each other and their performance can not only inherit the performance of their parent environment, but also can be individually configured to meet different application needs (that is, the configuration of the child environment can override the configuration inherited from the parent environment, You can also add some configurations that have never been in the parent environment. That's what DB2 actually did. A DB2 installation (an overall large environment) can have many "instances". There can be a large number of "databases" in an "instance". There can be many tables in a "database". This is a data-tiered storage, environment-tiered configuration approach. Since the environment is graded, the tools used to provision the environment should also be graded, with the same level of environment leveling tools corresponding to the same level of sub-environments. So in the real world, the operating system environment variables mentioned above for adjusting the DB2 environment are also graded, and each is assigned only to the sub-environment of the responsible level.

To be prompted here, the instance is often referred to as the "Database Manager", abbreviated to Dma=database Management application. Don't respond to the words "DMA" or "Database Manager" when you don't see them in the future.

Although operating system environment variables can play a role in the provisioning of large environments and sub-environments, the operating system environment variables alone are not enough. Is like a building environment is necessary some unified settings, such as the courtyard layout, each floor corridor structure, the same unit of the layout of the room; But the personalization is also important, and you can't ask all the tenants in a building to buy the same furniture, It is also impossible to require all tenants to have the same furniture layout. So, in addition to operating system environment variables, there is a tool that can be used to provision the DB2 environment, which is "Profile parameters".

• Configuration file Parameters:

As with the operating system environment variables, the configuration file parameters are also sub-level. Different levels of profile parameters are only for provisioning of sub-environments of a sibling. The configuration file parameters are divided into two levels, which are stored in two different configuration files. One is the Database Manager (DMA) level profile parameter (DMA refers to the "instance"), which is stored in the Database Manager configuration file, and the Database Manager configuration file is stored in the disk directory where the corresponding instance resides. The second is the database-level profile parameter, which is stored in the database configuration file and the database configuration file is stored in the disk directory of the corresponding database. The parameters in the different levels of the configuration file are completely different and are not duplicated. Different levels of operating system environment variables are likely to be duplicated. Because the profile parameters are for fully personalized properties in different levels of the child environment. For example, there is heating in the household, and there may be no heating in the corridor, so in the corridor configuration file does not need to set the "Heating temperature" parameter. Further, the sub-environment properties that the operating system environment variable targets can also have properties (inheritance properties) in their parent environment, or they may be properties that are not in their parent environment (personalization properties). The configuration file parameter has only personalization properties for the child environment properties, and no inheritance attributes. Just like after modifying an operating system environment variable, a change to the configuration file parameter after it is modified will require a restart of the corresponding child environment (corresponding instance or database) for the modification to take effect.

There is a very inconvenient phenomenon, that is, if you change the operating system environment variables, you want to make the changes to take effect, you need to restart the computer or server. To address this inconvenience, DB2 has introduced a tool that is the DB2 profile registry.

• DB2 Summary Registry variables:

The DB2 Profile registry variable is simply a collection of many DB2 operating system environment variables, and it does not itself contain any newly defined variables. This must be borne in mind. Modifying the value of a variable by DB2 the profile registry, essentially modifying the value of the corresponding operating system environment variable. A more such mechanism is to solve the restart problem. Operating system environment variables modified through the DB2 profile registry can take effect immediately without rebooting. However, it is important to note that there are individual operating system environment variables can not be included in the DB2 profile registry, for these operating system environment variables can not be modified through the profile registry, can only be modified directly in the operating system, and after the change to restart the effective. You can also specify which operating system environment variables are implanted into the profile registry and which are not implanted. However, it is strongly recommended to include all the operating system variables that can be included in the profile registry and to modify it by the summary registry (try to avoid modifying the operating system environment variables directly on the operating system platform). This will not only minimize the hassle of restarting, but more importantly, it will be beneficial to future remote configuration, it is necessary to know that the operating system environment variables that are not included in the profile registry can only be modified on this machine and cannot be configured remotely! Corresponding to the level of the operating system environment variable, the DB2 profile registry variable has four levels: one is the global level profile registry variable, corresponding to the global level operating system environment variable, is responsible for the overall large DB2 environment, the second is the instance level profile registry variable, corresponding to the instance level operating system environment variables, Responsible for the provisioning of the instance level sub-environment; The third is the instance node level registry variable, corresponding to the instance node level operating system environment variable, which is responsible for provisioning the sub-environment of the database partition (which is used when the database partitioning feature is used). Four is the user Level profile registry variable, corresponding to the user level of operating system environment variables, responsible for specific user-defined personalized provisioning tasks.

DB2 checks the profile registry variables and operating system environment variables in the following order and resolves them to configure the environment:

1. Operating system environment variables not included in the profile registry

2. User Level Profile Registry variables

3. Instance node level overview registry variables

4. Instance level profile registry variables

5. Global level Profile Registry variables

Note that in addition to the four-level summary registry described above, there is also a profile registry called the Instance Profile registry (not confused with the instance-level profile registry). This registry only records the list of all existing instances in the current DB2 environment. It is useful to see which instances have been created in the current DB2 environment when the user runs the Db2list command. Note that this summary registry provides only query functionality, no configuration and modification of any level of environment, just an instance table column for people to view.

"Progressive DB2.DBA system Management, operation and application Case" (New) reading notes 3 variables affecting DB2 environment