Page 701
CAUTION |
Be careful when using the dynamic performance tables during a performance crisis. If you look at the values today, they may well be larger than they were yesterday, simply because many of them accumulate over the life of the instance. Any time the database does useful work, these statistics are likely to increase. Develop a monitoring strategy that will allow you to compare the rates of change, rather than simply relying on the values shown in the tables at a specific moment in time. Also, do not try to gather data from these tables too soon after instance startup. You should expect a lot of overhead when the instance is new and still acquiring resources for the first time. |
If you find true pinging from these tables, you have a number of options. First, if only two instances are involved, you might consider combining their workload and their users into just one instance. If this is not possible due to resource limitations, or if more than one instance is involved, you may need to consider the partitioning options discussed earlier. Your objective should be to find a means to restrict the majority of the access on a given block to one and only one instance. This may require examining the values of the rows on the pinged blocks to identify partitioning options.
If you find false pinging is occurring, your simplest solution is to add more hash locks or to convert to fine grain locks for the datafiles involved. The former may involve creating too many locks for your current memory to handle in which case you would have to use fine grain locks. If these additional fine grain locks, in conjunction with existing hash locks, still constitute too many locks for your system to manage, you need to try reassigning some of the datafiles covered by hash locks to fine grain locks.
If you cannot solve the pinging problems using these methods, it may mean that your database is not properly designed and you may need to return to the drawing board and use the design techniques discussed earlier to find a better design. Releases of Oracle prior to Version 7.3, which didn't offer fine grain locks and the related benefits, made some databases inappropriate for Parallel Server. Now, with fine grain locking, the use of TP monitors, and the additional features of Oracle8 such as the global views and reverse key indexes, you should be able to build and monitor a multi-instance database for either failover or scalable purposes, if not both.l
Page 702