The processor (sometimes referred to as the CPU) is generally the most expensive resource in a system. As such, they should be used as efficiently and fully as possible. In a highly-utilized, well-tuned system, the processor is in use at least 80% of the time. If yours is already above that level, you must either upgrade your processor or find a more efficient way to do the job. For example, rewrite your application program, or investigate the structure of your data or SQL statements. Refer to Chapter 5, Improving Data Access Performance.
Your system's performance is directly affected by how well the database manager and your operating system share a common pool of storage between different processes.
For example, agent structures, buffer pools, locks, and packages all require storage. In general, the more storage allocated to a specific component, the faster it will perform (within limits). However, you can only allocate storage from the limited amount available in your database machine or partition. You need to trade-off the requirements of each component in order to balance the entire system.
For example, if DASD I/O is a performance bottleneck during regular operation and locking is not, consider using less storage for locks and more for the DASD buffer pools. For more information, refer to Real and Virtual Storage. (This is a good example of how performance issues interrelate. By increasing the number of buffers in the pool you decrease your DASD I/O during regular operation, but increase it during checkpoint processing. If checkpoint processing was a problem you have just made it worse. Refer to Choosing the Checkpoint Interval.)
The database manager moves data to and from DASD as required. How efficiently it does that has a significant impact on the overall performance of your application server. How much real storage is available, the size of the buffer pools, and how often a checkpoint is performed all determine how often the database manager needs to move data between itself and DASD.
You can also improve the performance of the DASD I/O subsystem by using DASD caching, Virtual Disks (see Virtual Disk Support for VSE/ESA for Internal Dbspaces or Virtual Disk Support for VM/ESA for Internal Dbspaces), or the DB2 DSS Support (see Chapter 6, Data Spaces Support for VM/ESA).
How you manage DASD storage affects performance in four ways:
For more information, refer to DASD Storage.
The database manager uses agents and pseudo agents to allow concurrent use of its resources. It uses agent structures to divide processor time between multiple users and its own internal tasks, such as checkpoint processing and operator commands. The number of agents available, combined with how the agents are scheduled and dispatched can affect the overall performance of your system. For more information, refer to Concurrency.
Your operating system must also divide processor time among multiple applications (your application server being one). If the operating system favors your server and gives it more than its even share of time, your server may perform well, but at the expense of other applications. For VM, refer to Fair Share Scheduling. For VSE, refer to Dispatching Priority.
In multiple user mode (MUM), several agents may need to access the same data at the same time. This poses a problem if one agent tries to change data while another agent is still looking at it.
Consider two application programs, each trying to add ten dollars to the same account at the same time. Both programs read the account balance at the same time. They both see 100 dollars in the account. The first program updates the value in the account with 110 dollars, the second program does likewise. The problem is that when both programs are finished there is only 110 dollars in the account instead of 120.
To avoid this problem, the database manager can lock the account as soon as the first program looks at it and hold the lock until the program is finished updating the balance. The second program waits until the first is complete.
Of course while locking protects your data, there is a performance cost. Not only can waiting for locks increase response time (locks can last to the end of a logical unit of work), but each lock requires additional storage and processing time. Refer to Locking Contention.
Also, because there are a set number of potential locks defined at initialization time, you may run out. You may need more than were originally defined. If this happens, locks will be escalated, (refer to Lock Escalation) a process that requires additional storage and processor time.
Deadlocks (refer to Deadlock) can also be a problem. While the database manager detects deadlocks before they occur, the more potential deadlock situations that you create the more resources are required to avoid them.
Maintaining the integrity of your data means preventing its accidental or intentional destruction, alteration, or loss. If your data is ever affected, there are three systems to ensure that you can recover it.
For information on both logging and archiving, refer to Logging and Archiving.