Why Oracle sometimes uses indexes for data analysis

Why Does Oracle sometimes use indexes to search for data? A: When you use the SQL language to publish a query statement to the database, Oracle will generate an "Execution Plan", that is, the data search scheme through which the statement will be executed, whether to scan the entire table or search by index. The selection of search solutions is closely related to the Oracle optimizer. SQL statement execution steps the process of processing an SQL statement follows these steps. 1. analyze whether the syntax of a statement complies with the specifications to measure the meaning of each expression in the statement. 2. semantic analysis checks whether all database objects involved in the statement exist and the user has the relevant permissions. 3. View conversion converts query statements related to views into corresponding query statements for base tables. 4. Expression conversion converts complex SQL expressions into simple equivalent join expressions. 5. Select the optimizer and different optimizer. Generally, different execution plans are generated. 6. Select the connection mode. Oracle has three connection modes. You can select an appropriate connection mode for multi-Table connection to Oracle. 7. Select which table is first connected to the Oracle database connected to multiple tables in the connection sequence, and which table is selected as the source data table in the two tables. 8. Select the data search path and select the appropriate data search path based on the preceding conditions. If you select full table search, you can use indexes or other methods. 9 Oracle Optimizer for running the "Execution Plan" Oracle has two types of Optimizer: Rule-Based Optimizer (RBO, Rule Based Optimizer) and cost-Based Optimizer (CBO, cost Based Optimizer ). RBO has been adopted since Oracle version 6 and has a set of strict rules for use. As long as you write SQL statements according to it, no matter what content in the data table, it will not affect your "Execution Plan ", that is to say, Oracle is no longer developing this technology because it is not "sensitive" to Data. Since Oracle 7, many new technologies adopted by Oracle 7 are based on CBO, such as star join arrangement query, hash join query, and parallel query. CBO calculates the "cost" of various possible "execution plans", namely, cost. It selects the lowest cost solution as the actual operation plan. The cost calculation of each "Execution Plan" depends on the statistical distribution of data in the data table. The Oracle database itself is not clear about the statistical distribution and requires analysis tables and related indexes, to collect the data required by CBO. Generally, the "Execution Plan" selected by CBO is not inferior to the "Execution Plan" of RBO, and CBO has less demanding requirements on programmers than RBO, it saves programmers the debugging time to select an optimal solution from multiple possible "execution plans", but in some cases there will also be problems. Typical problems are: Sometimes, it indicates that an index is created, but the query process obviously does not use the relevant index. As a result, the query process takes a long time and consumes a large amount of resources. What is the problem? Find the cause in the following order. First, determine the optimization mode in which the database runs. The corresponding parameter is optimizer_mode. Run "show parameter optimizer_mode" in svrmgrl to view the information. Since Oracle V7, the default setting should be "choose". That is, if you want to query the analyzed tables, select CBO. Otherwise, select RBO. If this parameter is set to "rule", RBO is used no matter whether the table has been analyzed or not, unless it is forced by hint in the statement. Secondly, check whether the indexed column or the first column of the composite index appears in the WHERE clause of the PL/SQL statement. This is a necessary condition for the "Execution Plan" to use the relevant index. Third, check which type of connection is used. Oracle supports Sort Merge Join (SMJ), Hash Join (HJ), and Nested Loop Join (NL ). When two tables are connected and the target column of the internal table has an index, only the Nested Loop can effectively use the index. Even if an index is built on the relevant column, SMJ can only avoid data sorting because of the existence of the index. Due to HASH calculation, the existence of Indexes has almost no impact on the data query speed. Fourth, check whether related indexes are allowed in the connection sequence. Assume that the deptno column of the table emp has an index, and the deptno column of the table dept has no index. The Where statement has the condition emp. deptno = dept. deptno. During the NL connection, emp is first accessed as the External table. Due to the connection mechanism, the External table data is accessed in full table scan and emp. the index on deptno is obviously not used. A full index scan or quick full index scan can be performed on deptno. Fifth, whether to use the system data dictionary table or view. Because the system data dictionary tables have not been analyzed, the execution plan may be very poor ". However, do not analyze the data dictionary tables without authorization. Otherwise, a deadlock may occur or the system performance may degrade. Sixth, whether the index column is a function parameter. If so, indexes cannot be used during queries. 7. Whether there is a potential data type conversion. For example, if you compare the numeric data with the numeric data, Oracle will automatically convert the numeric data using the to_number () function, resulting in the occurrence of the sixth phenomenon. Eighth, whether to collect sufficient statistics for tables and related indexes. It is recommended that you analyze tables and indexes on a regular basis for tables with frequent data additions, deletions, and changes. Available SQL statement: analyze table xxxx compute statistics for all indexes; oracle can make the right choice only when it fully reflects the actual statistical data. Ninth, the selection of index columns is not high. We assume that the emp table contains 1 million rows of data, but the emp. deptno column contains only four different values, such as 10, 20, 30, and 40. Although emp has many data rows, Oracle determines that the values of the columns in the table are evenly distributed across all data rows by default. That is to say, each deptno value corresponds to 0.25 million data rows. Assuming that the SQL Search Condition DEPTNO = 10, using the index on the deptno column for data search efficiency is often no higher than the full table scan, ORACLE naturally turns a blind eye to the index ", the index is not highly selective. However, in another case, if 1 million data rows are not evenly distributed among the four deptno values, 0.99 million rows correspond to values of 10, rows correspond to values of 20, rows correspond to values of 30, and rows correspond to values of 40. In this data distribution pattern, when searching for other deptno values except 10, there is no doubt that if the index can be applied, the efficiency will be much higher. We can analyze the index column separately, or use the analyze statement to create a histogram for the column to collect sufficient statistics for the column, enables Oracle to index highly selective search values. 10. Whether the index column value can be NULL ). If the index column value can be NULL, indexes, such as COUNT (*), are not used in SQL statements for operations that require NULL values to be returned. Instead, full table scan is used. This is because the stored values in the index cannot be empty. 11th. Check whether parallel query (PQO) is useful ). Indexes are not used for parallel queries. 12th. Check whether bind variables are useful in PL/SQL statements. Because the database does not know the specific value of the bind Variable, such as "<", ">", and "like" during non-equal connections. Oracle will reference the default value, which may affect the execution plan in some cases. If no reason can be found from the above aspects, we have to use the hint method in the statement to force Oracle to use the optimal "Execution Plan ". Hint adopts the annotation method, which can be line comment or segment comment. If you want to use the IND_COL1 INDEX of Table A, you can use the following method: "SELECT/* + INDEX (A IND_COL1) */* from a where COL1 = XXX;" Note, the annotator must follow the SELECT clause, and the "+" in the comment must follow the comment start character "/*" or "--". Otherwise, the hint is considered as a general comment, the execution of PL/SQL statements does not have any impact. Two effective tracing and debugging methods: Oracle provides two effective tools to track and debug the execution plan of PL/SQL statements. One is the explain table method. You must first create a PLAN_TABLE table in your SCHEMA. each step of the execution plan is recorded in this table, the SQL script for table creation is utlxplan under $ {ORACLE_HOME}/rdbms/admin. SQL. Open SQL * PLUS, enter "set autotrace on", and then run the SQL statement to be debugged. After the query result is displayed, Oracle displays the corresponding "Execution Plan ", it includes the optimizer type, execution cost, connection mode, connection sequence, data search path, and corresponding resource costs such as continuous read and physical read. If we cannot determine the specific SQL statement to be tracked, for example, after an application is used for a period of time, the response speed suddenly slows down. We can use TKPROF, another powerful tool provided by Oracle, to track the entire process of application execution. In the system view V $ SESSION, locate the corresponding SID and SERIAL # Based on the USERID or MACHINE #. Run EXECUTE DBMS_SYSTEM.SET_ SQL _TRACE_IN_SESSION (SID, SERIAL #, TRUE) to connect to the database using SYS or other users that EXECUTE the DBMS_SYSTEM package, and then run the application on the server, the ora _ xxxx is generated in the directory indicated by the database parameter "USER_DUMP_DEST. trc file, where xxxx is the operating system process Number of the application to be tracked. After the application is executed, use the tkprof command to analyze the file. Command example: "tkprof tracefile outputfile explain = userid/password ". If you are an ORACLE user in the operating system, type "tkprof" to provide detailed Command help. The output file outputfile after analysis contains the "Execution Plan", CPU usage, physical reads, logical reads, and execution duration of each PL/SQL statement. Based on the output file information, you can find out which PL/SQL statements in the application cause problems.