Read an Excerpt
Chapter 6: Monitoring Multiple Databases
At the risk of tipping off future interview candidates, here are two questions that I always ask when interviewing to fill DBA positions:- 1. "What are the critical success factors for your database?"
- 2. "How do you monitor them?"
These seem like fairly straightforward questions, but many candidates suddenly realize that they don't know their database's critical success factors—Something with space, right?" And without knowing those factors, their monitoring systems are either insufficient or overkill. The database must be monitored in a fashion that takes its specific structure and usage into account. Monitoring should focus on revealing problems with the system implementation, rather than tracking the problems' symptoms.
Putting out a fire in a hotel results in an extinguished fire, but it does not make the hotel any less likely to catch fire in the future. Reacting to problems requires understanding the underlying system faults that led to them; otherwise, only the symptom is being treated while the cause remains.
To avoid failing into permanent DBA fire-fighting mode, four things are necessary:
- 1. A well-defined understanding of how the database will be used by its applications
- 2. A well-structured database
- 3. A set of metrics that gauge the database's health
- 4. A systematic method for making those measurements and determining trends
- 2. A well-structured database
The first two points, on database design, have been covered in Chapters 3-5. This chapter addresses the third and fourth points, providing measurement guides and a method for monitoring them. The first part of this chapterwill concentrate on measuring physical elements of the database via a "Command Center" database; the second section will focus on monitoring memory objects via the ORACLE statistics scripts.
Common Problem Areas
There are several potential problem areas in all ORACLE databases. These include- Running out of free space in a tablespace
- Insufficient space for temporary segments
- Rollback segments that have reached their maximum extension
- Fragmentation of data segments and free space
- Improperly sized SGA areas
In the following sections you will see a brief synopsis of the problem areas to be tracked, followed by details for creating a system tailored for their monitoring.
Running Out of Free Space in a Tablespace
Each tablespace in the database has datafiles assigned to it. The total space in all of the datafiles in a tablespace serves as the upper limit of the space that can be allocated in the tablespace.
When a segment is created in a tablespace, space is allocated for the initial extent of the segment from the available free space in the tablespace. When the initial extent fills with data, the segment acquires another extent. This process of extension continues either until the segment reaches a maximum number of extents or until the free space in the tablespace is less than the space needed by the next extent.
The free space in a tablespace therefore provides a cushion of unallocated space that can be used either by new segments or by the extensions of existing segments. If the available free space falls to a value that does not allow new segments or extents to be created, then additional space will have to be added to the tablespace (by adding new datafiles or resizing existing datafiles).
Therefore, you should monitor not only the current available free space in tablespaces, but also the trend in the available free space-is there more or less available today than there was a week ago? You must, be able to determine the effectiveness of the" current space allocation and predict what it will look like in the near future.
Insufficient Space for Temporary Segments
Temporary segments are used to store temporary data during sorting operations (such as large queries, index creations, and unions). Each user has a temporary tablespace specified when the account is created via the create user or alter user command. The temporary tablespace should be pointed to some place other than the SYSTEM tablespace (the default).
When a temporary segment is created, it uses the default storage parameters for that tablespace. While it is in existence, its storage parameters cannot be altered by changing the default storage parameters for the tablespace. it extends itself as necessary, and drops itself when the operation completes or encounters an error. Since the temporary segment itself can lead to errors (by exceeding the maximum number of extents or running out of space in the tablespace), the size of large sorting queries and operations should be taken into consideration when sizing the temporary tablespace.
If the temporary tablespace runs out of free space during the execution of a sorting operation, then the operation will fail. Since it is difficult to accurately size such segments, it is important to monitor whether the temporary tablespace created to hold them is large enough. As with data tablespaces, both the current value and the trend will be monitored via the scripts provided in this chapter. . . .