Oracle Database Administration for Microsoft SQL Server DBAs part 26 ppsx

Depending on the type of database that is running, several of these parameters may be useful for tuning, including the following: ■ The STAR_TRANSFORMATION_ENABLED parameter would probably be set to TRUE if the database has more of a data warehousing purpose, rather than is just used as a transactional database. ■ The OPTIMIZER_INDEX_COST_ADJ parameter can be adjusted to make the optimizer more willing to use indexes. The setting is a percentage to adjust the cost of using indexes in the query plans. For example, reducing the value of this parameter from 100 to 50 would cut the cost of using an index in half. ■ The OPTIMIZER_MODE parameter chooses the approach for the database instance. FIRST_ROWS will find a best plan to return the first set of rows faster. ALL_ROWS will develop the plan to return all of the values of the query in the session. 232 Oracle Database Administration for Microsoft SQL Server DBAs FIGURE 8-5. Optimizer parameters Adjusting the parameters can help change how the optimizer behaves, and can also give the database instance more resources, especially when increasing the memory parameters to allocate more memory to the system. Some of the default settings might be valid for simple database environments. The type of database environment and how it is being used in general should be considered when adjusting these parameters. Additional information from the snapshot reports and advisors that run in the database can help determine the appropriate settings and configurations for some of the parameters. Automatic Workload Repository The Automatic Workload Repository (AWR) contains significant information that can be helpful when it comes to tuning the database environment. The database takes regular snapshots to get information about the database settings and the workload in the environment, and stores them in the AWR metadata tables (WRM$_) and historical statistics tables (WRH$_). In Oracle Database 11 g , these reports and information are part of the Oracle Diagnostic Pack, which provides automated gathering of the information and ways to pull the information out of the workload and history tables for review and evaluation of performance issues. You can also create baseline templates to be able to compare information. Baselines are especially useful when you find that the database is not performing as it did before, and you need to understand what might have changed. AWR Reports AWR reports have information about the different waits. The reports list the top waits, providing a quick way to determine the areas that might be of interest or where to start looking for bottlenecks. The AWR reports can be viewed in OEM, as shown in Figure 8-6. The reports are based on the snapshot times. If different intervals are needed, different reports can be generated. In OEM, you can view the details in the list or see the reports in HTML format. The time period, activity on the server, and some information about Chapter 8: Performance and Tuning 233 the load on the server are summarized first. Figure 8-7 shows this information at the top of the report, as well as the wait information, which appears a bit further down in the report. The first item listed in the wait information is DB CPU at the top. In the example in Figure 8-7, no waits are listed; it shows just the percent of the database time for CPU. I would suspect since there is no waiting for CPU, the time is just the regular activity against the database and what is needed for CPU. As noted earlier in the chapter, the db file scattered read wait event points to full-table scans being done. If you see these waits, check the top SQL statements to validate query plans and consider placing indexes on the appropriate tables. 234 Oracle Database Administration for Microsoft SQL Server DBAs FIGURE 8-6. AWR reports available for viewing in OEM Chapter 8: Performance and Tuning 235 FIGURE 8-7. An AWR report in OEM Active Session History View The Active Session History (ASH) view has information about waits and events based on the sessions that are occurring in the database. The following example generates a list of how many sessions had waits for an event. SQLPLUS> select session_id||','||session_serial# SID, n.name, wait_time, time_waited from v$active_session_history a, v$event_name n where n.event# = a.event# SID NAME WAIT_TIME TIME_WAITED 170,3 db file sequential read 0 28852 321,1 reliable message 0 977530 286,33215 db file parallel write 0 1108 240,25727 library cache lock 0 185 … ##plenty more events returned, so just a sampling The TIME_WAITED column shows the actual time waited for the event, and will be updated when the event is completed. The WAIT_TIME column information matches up with the v$session_wait view. When the wait time is shown as zero, then the session is currently waiting; nonzero values indicate the session’s last wait time. The information about events and waits can be overwhelming. In tuning the database, you should focus on the top wait events, especially if the information gathered is during a period when performance was an issue. Getting information about which SQL statements were running and what Oracle was waiting on will help with this troubleshooting. Also be aware that some waits are just routine in the system, such as the reliable message wait listed in the example of the ASH view. This is an idle wait event, meaning that it is just waiting for work—something to do—and not waiting on a resource. Library Cache for SQL Statements In the wait events listed in the sample AWR report and ASH view, you saw a couple events pointing to the library cache. The library cache is part of the shared pool and is the area in memory that handles SQL statements, PL/SQL packages, and procedures. This can be considered similar to the SQL Server procedure cache. 236 Oracle Database Administration for Microsoft SQL Server DBAs Oracle will first look in the library cache for code that is to be executed against the database, so there is no additional load into memory if the code is already there. The plans are also available there, so it is beneficial to be able to reuse SQL that is available in the library cache. The following wait events appeared in the previous examples: ■ The library cache lock event is when two users want to compile the same piece of code. ■ The library cache load lock event is a wait for the lock to be able to load an object into the library cache. The AWR reports show a library cache hit ratio to indicate how much of the code is found in the cache and available for reuse. One reason for not finding code in the library cache is that the cache is too small to hold all of the statements; if there are a lot of ad hoc statements, it might be hard to hold all of the statements. Another reason could be due to the use of literal values instead of bind variables in the code. SQLPLUS> select … … where employee_name='George'; SQLPLUS> select … … where employee_name=:empname; The code with the variable will be getting the information passed in from a variable in the package instead of just using the string value that is passed in. Using bind variables is good practice and will help with management of the library cache. There is also a parameter that can help make code seem similar enough that it can be reused: CURSOR_SHARING. This parameter can be set to one of the following: ■ EXACT This makes the code match exactly. Using this value will result in either a large library cache/shared pool or a very low hit ratio of the library cache if literal values are used in the code and can’t be matched up. ■ FORCE This will force a substitute of a literal into a bind variable to reuse the code. ■ SIMILAR This will allow Oracle to decide what to bind, so that code can be reused. Chapter 8: Performance and Tuning 237 Other memory areas should also be examined for tuning and performance, but the library cache is important because it is related to the code running on the database. If you are able to design this code to use bind variables, or know how to take advantage of some other parameters to force it to behave in a more efficient manner, the database will perform better. Summary Tuning the performance of the database is a multiple-step process. First, you’ll need to ask questions to figure out where the performance issue is and what the issue actually means. Several Oracle tools allow you to gather information and see history and current statistics, giving you more details regarding what is running and how the server is behaving. The areas to check first in an Oracle database are different from those in a SQL Server database. Since locks and blocking are handled differently in Oracle, this area is further down on the list that it is in SQL Server. Indexes, statistics, and waits are the top areas to look at in an Oracle system to validate that the database has what it needs as input to create good execution plans and that it is not waiting on resources while the code is running. Oracle provides several different index types. You may be able to make code that may be less than optimal more efficient and access data faster, such as through function-based indexes. Also, indexes that can skip the first column may allow for fewer indexes to be created and maintained, which might benefit data change performance. Since the Oracle CBO takes into account the different costs of the indexes available and statistical information, it is important to have good indexes and up-to-date statistics on the tables and indexes. The system views that provide session and wait information are valuable in the tuning process, and the summary reports from the AWR provide a quick glance at the information. Using these tools, you can drill down into an issue to see if there are bottlenecks or code that needs to be tuned. 238 Oracle Database Administration for Microsoft SQL Server DBAs CHAPTER 9 PL/SQL T he extended programming language for SQL Server is Transact- SQL (T-SQL). For Oracle, the programming language is PL/SQL. These programming languages provide additional capabilities beyond those available with standard SQL. They are used to develop applications and a way of accessing data. However, using the database programming languages is not just for developers. Besides doing code reviews, there are plenty of times for DBAs to use these languages to write procedures for monitoring databases, performing maintenance, and moving or loading data. The database programming languages have some similar characteristics, but each takes advantage of some features that are platform-specific. For both, you define the variables and code to be executed, as well as pass in values and return values. They both provide ways to handle errors and process standard SQL statements. You can create triggers, stored procedures, and functions. Oracle also has packages that group functions and procedures together. In previous chapters, you have seen several examples of SQL statements to look at the data in an Oracle database or change it in some way, as well as examples to execute PL/SQL system-supplied packages and procedures, such as DBMS_STATS and DBMS_SCHEDULER. This chapter provides more details about using PL/SQL. If you’re migrating from SQL Server to Oracle, you’ll probably need to spend some time converting the T-SQL procedures to PL/SQL procedures. Database Coding Practices PL/SQL is a programming language with close integration to the Oracle database. Some of the standard coding practices used with T-SQL don’t translate to PL/SQL, and might even seem backward. However, some of the concepts correspond, although the coding will not be exactly the same. For example, the concept of SQL Server INSTEAD OF triggers are found in Oracle’s BEFORE triggers. Table 9-1 shows some examples of commonly used programming tools in SQL Server and Oracle. As we look at PL/SQL examples throughout this chapter, you will see how these are used in blocks of code. 240 Oracle Database Administration for Microsoft SQL Server DBAs Chapter 9: PL/SQL 241 Usage SQL Server Tool Oracle Tool Data type association User-defined types %TYPE or %ROWTYPE allows for using a column or row to have the variable be the same type Select SELECT 'test' Can select without from clause SELECT 'test' FROM dual; Dummy table to use with FROM Row ID Can generate an ID column on select using functions Row ID is automatically created as a pseudo column Unique identifier Identity Sequences If this, then this … CASE DECODE or CASE Set operators EXISTS and NOT EXISTS INTERSECT and MINUS Cursors For looking at one row at a time; tend to be slower way to process Implicit cursors used for data processing; explicit use of cursors to manipulate the data of a SELECT statement Delimiters Statements continue when previous statement is completed without specific delimiter Use of ; to delimit statements Create If exists, drop, then create Create or replace Alter Alters stored procedure code if exists Create or replace TABLE 9-1. Common Code Usage in SQL Server and Oracle . code. 240 Oracle Database Administration for Microsoft SQL Server DBAs Chapter 9: PL /SQL 241 Usage SQL Server Tool Oracle Tool Data type association User-defined types %TYPE or %ROWTYPE allows for using. waits, check the top SQL statements to validate query plans and consider placing indexes on the appropriate tables. 234 Oracle Database Administration for Microsoft SQL Server DBAs FIGURE 8-6. AWR. Server procedure cache. 236 Oracle Database Administration for Microsoft SQL Server DBAs Oracle will first look in the library cache for code that is to be executed against the database, so there is no additional