Uh-oh, it looks like your Internet Explorer is out of date.

For a better shopping experience, please upgrade now.

Oracle8 DBA Handbook

Oracle8 DBA Handbook

4.0 1
by Kevin Loney
What every system administrator needs to know for effective and efficient database management.

The Essential Guide to Database Management in the Real World.

No DBA should be without this book! Oracle8 DBA Handbook is a thorough revision of the most popular book ever published on the subject of Oracle database administration. This comprehensive


What every system administrator needs to know for effective and efficient database management.

The Essential Guide to Database Management in the Real World.

No DBA should be without this book! Oracle8 DBA Handbook is a thorough revision of the most popular book ever published on the subject of Oracle database administration. This comprehensive authoritative guide is considered the "bible" for all Oracle DBA's.

World renowned Oracle expert Kevin Loney show you how to set up a database for maximum efficiency,monitor it,tune it,and maintain its security. You'll find tips on using Oracle's distributed database and its client/server capabilities for both UNIX and NT platforms. Completely revised to cover Oracle8 and all of its revolutionary new features and technologies,this book holds the most up-to-date information available on Oracle's latest release of Oracle Server,including:

  • Managing very large databases (VLDBs)
  • Implementing Net8 (the updated version of SQL*Net)
  • Supporting Oracle tools and packages,including Oracle Financials,Oracle Designer/2000,ConText,and Oracle utilities
  • And of course,supporting Oracle8's object-relational database technology and the Oracle7 to Oracle8 migration process

Whether you are a new or experienced DBA,you can master the many nuances and intricacies of this complete and powerful database system. The Oracle8 DBA Handbook will be your crucial guide to developing today's real-world information needs.

Product Details

McGraw-Hill Companies, The
Publication date:
Edition description:
Product dimensions:
7.32(w) x 9.04(h) x 1.88(d)

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

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
An effective database monitoring system, such as the one whose details are provided in this chapter, should be able to detect unacceptable values for each of these 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. . . .

Customer Reviews

Average Review:

Post to your social network


Most Helpful Customer Reviews

See all customer reviews

Oracle8 DBA Handbook 4 out of 5 based on 0 ratings. 1 reviews.
Guest More than 1 year ago
This book has all the elements one needs to know to perform ORACLE DBA maintenance. It's only lacking is that it does not have a quick reference card, but it delivers a reference section and CDROM of sample scripts. There could also be more examples of DBA commands and situations. This would help the practitioner by providing hands-on examples that are easy to replicate. This text is weak on the DBA tools.