Tài liệu ORACLE8i- P22 docx

CHAPTER 17 • MONITORING AND TUNING LATCHES, LOCKS, AND WAITS 836 If your system administrator manages these systems, you may not be privy to the mapping of physical disks. Perhaps, in part, the administrator doesn’t understand the importance of such mapping or doesn’t know how to create such a map. Either way, it’s imperative that you make clear to your system administrator that you need to know where this data resides, and with what other systems it interacts. Correcting I/O problems can make a huge difference in performance. This action alone can transform you into a hero. Trust me. I’ve been there. How’s the Shared Pool Doing? After tuning I/O, you may still be seeing a good deal of latch contention. Now’s the time to look at the shared pool and take advantage of the scripts provided in Chap- ter 15. A poorly tuned shared pool can cause all sorts of latch issues. Run the various scripts that monitor the hit ratios of the shared pool. Are your hit ratios low? If so, you must add memory. WARNING Any time you add memory to any Oracle memory structure such as the shared pool, make sure you don’t add so much that you cause the system to start thrash- ing memory pages between the swap disks and memory. This will inevitably result in per- formance problems. You’ll only wind up worse off than before. If the hit ratios are not low, and you see thrashing, make sure you have not over- allocated memory to the point that you are paging or excessively swapping memory to and from the disk. If you are, you must correct this problem immediately. You’ll need to enlist the help of your system administrator to determine if you’re having system memory contention issues. In keeping with the theme of reducing I/O is the idea that the fewer numbers of blocks you have to deal with, the less work the database will have to do, and latch con- tention will be minimized. Do everything you can to reduce I/Os during queries. Make sure your tables are allocating block storage correctly (look at PCTUSED/PCTFREE). Making sure tables load in order of the primary key (or most often used) index columns, and tuning your SQL to return the result set in the fewest number of block I/Os (logical or physical) will result in a reduction in latch contention—-we guarantee it. Finally, don’t just throw CPUs, disks, and memory at the problem: that’s the wrong kind of lazy solution and often doing so prolongs the problem. As your database sys- tem grows, even the faster hardware will not be able to handle the load. The only exception to this rule is if you simply do not have enough disk space to properly dis- tribute the I/O of the database. If this is the case then you simply have to buy more disk pronto. C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 837 NOTE In some cases, lack of memory in the shared pool or the database buffer cache actually is the problem. This can be true if you see low hit ratios in any of the memory areas. Fragmentation of the shared pool can also be a problem. Consider changing the shared_pool_reserved_size parameter, which is associated with the parameter _shared_pool_reserved_min_alloc These parameters affect the location in the shared pool for storing PL/SQL code. If the code is of a size greater than _SHARED_POOL_RESERVED_MIN_ALLOC, it will be stored in an area of the shared pool set aside by the parameter SHARED_POOL_ RESERVED_SIZE. If there isn’t enough memory available for that chunk to be stored in reserved memory, it will be stored in the normal memory area of the shared pool. You can positively affect shared pool fragmentation by increasing the SHARED_POOL_RESERVED_MIN_ALLOC parameter so that your largest PL/SQL pro- grams are loaded there. This approach will eliminate fragmentation issues. Another method that can be used to limit fragmentation of the shared pool is the use of the DBMS_SHARED_POOL.KEEP procedure to pin often used PL/SQL objects in the shared pool. (See Chapter 20 for more on DBMS_SHARED_POOL.) You might con- sider pinning commonly used objects in the SGA every time the database starts up. Doing so will help improve performance, and will go a long way toward reducing per- formance problems. Tune Up Your SQL If everything looks hunky-dory with the shared pool then make sure you are using re- usable SQL statements with bind variables as much as possible. If you aren’t, you can cause all sorts of problems, including latching contention. See Chapter 16 for more information on how to write reusable SQL and how to determine if SQL needs to be rewritten. You may also want to take advantage of cursor sharing in Oracle8i, which is also discussed in Chapter 16. General Tuning for Latch Contention Because there are various levels of latches, contention for one latch can cause contention against other, lower-level latches. A perfect example is the attempt to acquire a redo copy latch to quickly allocate memory in the redo log buffer. Depending on the size of the redo to be written, Oracle will often opt to use one of the several redo allocation TUNING LOCKS, LATCHES, AND WAITS Beyond Simple Database Management PART III C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 17 • MONITORING AND TUNING LATCHES, LOCKS, AND WAITS 838 latches rather than use the one redo copy latch. Having acquired the redo allocation latch, Oracle will then quickly try to acquire the level-six redo copy latch. Oracle needs this latch only long enough to allocate space in the redo log buffer for the entries it needs to write; then it releases the latch for other processes to use. Unfortu- nately, a delay in getting the redo copy latch can keep other processes from acquiring the available redo allocation latches. The bottom line is that you must always deal with latch contention level by level, tuning from the highest level (15) to the lowest (0). Consider increasing the _SPIN_COUNT parameter if you are seeing excessive sleeps on a latch. On many systems it defaults to 2000, but yours might be different. If you’re seeing problems with redo copy latches or other latch sleeps, see what you can do by playing with this parameter. You can use the ALTER SYSTEM command to reset the spin count as well, which means you don’t have to shut down the database. Here’s the syntax for this: ALTER SYSTEM SET “_SPIN_COUNT” = 4000; After you have reset the spin count, let the system run normally for a few minutes and then check to see if the number of spins has dropped. Also, has there been any change in the number of sleeps? (Note that sleeps for the redo copy latch are not unusual.) WARNING Remember that hidden or undocumented parameters are not sup- ported by Oracle in most cases. That includes _SPIN_COUNT (though it was a docu- mented parameter until Oracle8). With this in mind, test all hidden parameters before you decide to use them in production, and find out about any bugs by checking Oracle’s registered information. TIP In conjunction with your latch contention tuning, keep in mind that tuning bad SQL statements can have a huge impact on latching overall. So by all means tune the instance as best you can—but often your best results will come from SQL tuning. Tuning Redo Copy Latch Problems Oracle’s multiple redo copy latches are designed to relieve the hard-pressed single redo allocation latch. When using the redo copy latch, Oracle acquires the redo allo- cation latch only long enough to get memory in the redo log buffer allocated. Once that operation is complete, it releases the redo allocation latch and writes the redo log C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 839 entry through the redo copy latch. Note that sleeps for the redo copy latches are nor- mal and unique to this latch. The process will sleep if it fails to acquire one of the redo copy latches. When it wakes up, it tries to acquire the next redo copy latch in order, trying one at a time until it is successful. Oracle executes a sleep operation between each acquisition attempt, so you see the increases in the SLEEP columns of the V$LOCK data dictio- nary view. That being the case, if you get multiple processes fighting for this latch, you are going to get contention. You can do a couple of things to try to correct this problem. Increase the number of redo copy latches by increasing the default value of the parameters LOG_SIMULTANEOUS_COPIES and LOG_ENTRY_PREBUILD_THRESHOLD. Check your operating system documentation for restrictions on increasing these values. Tuning Redo Allocation Latch Problems Oracle’s lone redo allocation latch serializes access to the redo log buffer, allocating space to it for the server processes. Sometimes this latch is held for the entire period of the redo write, and sometimes just long enough for the allocation of memory in the redo log buffer. The parameter LOG_SMALL_ENTRY_MAX_SIZE sets a threshold for whether the redo allocation latch will be acquired for the duration of the redo log buffer write. If the size of the redo is smaller (in bytes) than LOG_SMALL_ENTRY_ MAX_SIZE, the redo allocation latch will be used. If the redo is larger, a redo copy latch will be used. So if you see latch contention in the form of sleeps or spins on the redo allocation latch, consider reducing LOG_SMALL_ENTRY_MAX_SIZE. NOTE There is a school of opinion for setting LOG_SMALL_ENTRY_MAX_SIZE to 0 and always using the redo copy latches. We contend that things Oracle are rarely so black and white. Always test a setting like this, and always be willing to accept that something else will work better. Other Shared Pool Latching Problems Latching issues in the shared pool are usually caused by insufficient memory alloca- tion. As far as database parameters go, there isn’t a lot to tune with respect to the shared pool beyond memory. Of course, maintain your typical vigilance over I/O dis- tribution and bad SQL. TUNING LOCKS, LATCHES, AND WAITS Beyond Simple Database Management PART III C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 17 • MONITORING AND TUNING LATCHES, LOCKS, AND WAITS 840 Tuning Buffer Block Waits Data block waits listed in the V$WAITSTAT view can indicate an insufficient number of free lists available on the table or index where the wait is occurring. You may need to increase it. In Oracle8i you can dynamically increase or decrease the number of free lists in an object by using the ALTER TABLE statement with the FREELISTS keyword in the STORAGE clause. NOTE By the way, don’t expect to see waits in V$WAITSTAT for the FREELIST class. This statistic applies only to free list groups. Free list groups are used in Oracle Parallel Server (OPS) configurations, so it’s unlikely that you’ll use them if you are not using OPS. Another concern is the setting of the object’s INITRANS parameter. The INITRANS parameter defaults to 1, but if there is substantial DML activity on the table, you may need to increase the setting. This parameter, as well, can be adjusted dynamically. Note that by increasing either free lists or INITRANS for an object, you are reducing the total space available in a block for actually storing row data. Keep this in mind. It can be hard to identify exactly what object is causing the buffer block wait prob- lems. Perhaps the easiest way is to try to capture the waits as they occur, using the V$SESSION_WAIT view. Remember that this view is transitory, and you might need to create a monitoring script to try and catch some object usage trends. Another way to monitor object usage is to enable table monitoring and watch the activity recorded in the SYS.DBA_TAB_MODIFICATIONS view. You can create a job to copy those stats to a permanent table before you update the statistics. See Chapter 16 for more on table monitoring. WARNING Carefully measure the performance impact of monitoring. It generally is insignificant, but with a system that is already “performance challenged,” you may further affect overall performance by enabling monitoring. Nevertheless, the potential gains from knowing which tables are getting the most activity may well override performance con- cerns. Remember that short-term pain for long-term gain is not a bad thing. You can pay me now, or you can pay me later. It’s the same old saw: The easiest way to reduce buffer block waits is to tune your I/O and then tune your SQL. Statements and databases that run efficiently will reduce the likelihood of buffer block waits. C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 841 TUNING LOCKS, LATCHES, AND WAITS Beyond Simple Database Management PART III By the way—others suggest that reducing the block size of your database is another solution. This approach might or might not reduce waiting; in any case, it’s not a good idea. The overwhelming advantages of larger block sizes cannot be ignored. Last Word: Stay on Top of I/O Throughput! We discussed proper placement of database datafiles in Chapter 4. If you’re run- ning multiple databases, I/O distribution becomes critical. In addition, file placement, partitioning, tablespaces, and physical distribution all affect I/O throughput to an even greater degree. Thus the concepts discussed in Chapter 4 have direct application in tuning methodologies. We’ll close this chapter with seven tenets for maximizing I/O throughput: 1. Separate data tablespaces from index tablespaces. 2. Separate large, frequently used tables, into their own tablespaces. If you partition tables, separate each partition into its own tablespace. 3. Determine which tables will frequently be joined together and attempt to distribute them onto separate disks. If you can also manage to put them on separate controllers as well, so much the better. 4. Put temporary tablespaces on their own disks, particularly if intense disk sorting is occurring. 5. Beware of the system tablespace. Often times DBAs think it is not heavily used. You might be surprised how frequently it is read from and written to. Look at V$FILESTAT and see for yourself. 6. Separate redo logs onto different disks and controllers. This is for both per- formance reasons and recoverability reasons. 7. Separate your archived redo logs onto different disks. The archiving process can have a significant impact on the performance of your system if you do not distribute the load out correctly. TIP One last bit of advice. On occasion, it’s the actual setups of the disk and file systems that are hindering performance. Make sure you ask your system administra- tor for help if you are having serious performance problems. He or she might have additional monitoring tools on hand that can help you solve your problem. A lazy DBA takes advantage of all resources at his or her disposal, always. C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 18 Oracle8i Parallel Processing FEATURING: Parallelizing Oracle operations 844 Using parallel DML and DDL 845 Executing parallel queries 849 Performing parallel recovery operations 854 Tuning and monitoring parallel processing operations 855 C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. P arallel processing is the process of using a multiprocessor computer to divide a large task into smaller operations to be executed in parallel. In Oracle, a single database operation can be divided into subtasks, which are performed by several different processors working in parallel. The result is faster, more efficient database operations. In this chapter, we discuss several options for effectively implementing parallel processing. The chapter begins with some basics of parallelizing operations, and then discusses how to use parallel DML and DDL, execute parallel queries, and perform parallel recovery operations. Finally, you will learn about the parallel processing param- eters and how to monitor and tune parallel processing operations. Parallelizing Oracle Operations In Oracle8i, parallel processing is easy to configure, and it provides speed and opti- mization benefits for many operations, including the following: • Batch bulk changes • Temporary rollup tables for data warehousing • Data transfer between partitioned and nonpartitioned tables • Queries • Recovery operations Prior to Oracle8i, you needed to configure your database instance for DML opera- tions. Oracle8i automatically assigns these values. Setting the init.ora parameter PARALLEL_AUTOMATIC_TUNING to TRUE will establish all of the necessary parame- ters to default values that will work fine in most cases. (Oracle recommends that PARALLEL_AUTOMATIC_TUNING be set to TRUE whenever parallel execution is implemented.) NOTE Setting the PARALLEL_AUTOMATIC_TUNING parameter to TRUE automatically sets other parallel processing parameters. If necessary, you can adjust individual parallel processing parameters in the init.ora file to tune your parallelized operations. See the “Tuning and Monitoring Parallel Operations” section later in this chapter for details. When you use parallel processing, the database evaluates the number of CPUs on the server and the number of disks on which the table’s data is stored in order to C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 845 determine the default degree of parallelism (DOP). The default degree of parallelism is determined by two initialization parameters. First, Oracle estimates the number of blocks in the table being accessed (based on statistics in the data dictionary) and divides that number by the value of the initialization parameter PARALLEL_ DEFAULT_SCANSIZE. Next, you can limit the number of query servers to use by default by setting the initialization parameter PARALLEL_DEFAULT_MAX_SCANS. The smaller of these two values is the default degree of parallelism. For example, if you have a table with 70,000 blocks and the parameter PARALLEL_DEFAULT_ SCANSIZE is set to 1000, the default degree of parallelism is 70. Rather than accepting the default degree of parallelism, you can tell Oracle what the degree of parallelism should be. You can assign a degree of parallelism when you create a table with the CREATE TABLE command or modify a table with the ALTER TABLE command. Also, you can override the default degree of parallelism by using the PAR- ALLEL hint (as explained in the “Using Query Hints to Force Parallelism” section later in this chapter). To determine the degree of parallelism, Oracle will first look at the sys- tem parameters, then the table settings, and then the hints in the SQL statements. NOTE When you are joining two or more tables and the tables have different degrees of parallelism associated with them, the highest value represents the maximum degree of parallelism. Using Parallel DML and DDL You can use parallel DML to speed up the execution of INSERT, DELETE, and UPDATE operations. Also, any DDL operations that both create and select can be placed in par- allel. The PARALLEL option can be used for creating indexes, sorts, tables—any DDL operation, including SQL*Loader. Enabling and Disabling Parallel DML When you consider what is involved in performing standard DML statements for INSERT, UPDATE, and DELETE operations on large tables, you will be able to see the advantage of parallel processing. To use parallel DML, you first need to enable it. Use the following statement to enable parallel DML: ALTER SESSION ENABLE PARALLEL DML; USING PARALLEL DML AND DDL Beyond Simple Database Management PART III C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 18 • ORACLE8i PARALLEL PROCESSING 846 When you’re finished with the task you want to perform in parallel, you can dis- able parallel DML, as follows: ALTER SESSION DISABLE PARALLEL DML; Alternatively, simply exiting the session disables parallel DML. You can also use the ALTER SYSTEM command to enable and disable the PARAL- LEL option. Creating a Table with Parallel DML Let’s work through an example to demonstrate parallel DML in action. In this example, you will use parallel DML to create a table that combines information from two other existing tables. The example involves data from a product-buying club of some sort (such as a music CD club or a book club). The two tables that already exist are PROD- UCT and CUSTOMER. The PRODUCT table contains information about the products that a customer has ordered. It has the following columns: CUST_NO PROD_NO PROD_NAME PROD_STAT PROD_LEFT PROD_EXPIRE_DATE PROD_OFFERS The CUSTOMER table contains information about each customer, including the customer’s name, address, and other information. It has the following columns: CUST_NO CUST_NAME CUST_ADD CUST_CITY CUST_STATE CUST_ZIP CUST_INFO C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.