First, the client listens to the database by listening, the database opens a server process process to receive the SQL sent by the client.
1. This SQL statement has never been executed. (Hard Parse)
2. This SQL statement has been executed. (Soft parsing)
Second, let's look at a SQL statement internal parsing what went through it?
Steps for SQL hard parse resolution
1. Syntax detection: Detecting SQL statements for syntax errors, compliance with SQL specification
2. Semantic detection: Detects whether the object involved in the SQL statement exists.
3. Check that the shared pool has the same SQL statement that has been executed.
4. Calculate the optimal execution plan by using the statistical information of the data dictionary.
Steps for SQL soft parse resolution
1. Syntax detection: Detecting SQL statements for syntax errors, compliance with SQL specification
2. Semantic detection: Detects whether the object involved in the SQL statement exists.
3. Check that the shared pool has the same SQL statement that has been executed. If so, use the execution plan directly
Third, check whether the shared pool has the same method of executing SQL statements:
1. Convert the SQL text to an ASCII value, then convert the ASCII value through the hash function into a hash value, and find the bucket according to the calculated hash to the chain chain in the library cache. Compare buckets for this SQL statement. As for the library cache inside is the use of the data structure of the chain to manage memory, the library cache has a lot of chain chain, each chain and hang a lot of buckets. The bucket contains SQL statement text, execution plan, and so on.
Oracle's internal parsing process for SQL statements "Weber"