How does the query execution occur? 1. SQL*plus checks the syntax on client side. 2.

If syntax is correct the query is stamped as a valid SQL statement and encrypted into OCI (Oracle Call Interface) packets and sent via LAN using TCP to the server. 3. Once the packets reach the server the server process will rebuild the query and again perform a syntax check on server side. 4. Then if syntax is correct SP will continue execution of the query. 5. The SP will go to the library cache. The L.C. will keep the recently executed SQL statements along with their execution plan. 6. In the library cache the server process will search from the MRU (Most Recently Used) end to the LRU (Least Recently Used) end for a match for the SQL statement. It does this by using a hash algorithm that returns a hash value. If the hash value of the query we have written matches with that of the query in L.C. Then SP need not generate an execution plan (soft parsing) but if no match is found then SP has to proceed with the generation of execution plan (hard parsing). 7. Parsing is the process undertaken by Oracle to generate an execution plan. 8. The first step in parsing involves performing a semantic check. This is nothing but check for the existence of the obj and its structure in the database. 9. This check is done by SP in the data dictionary cache. Here SP will ask for the definition of the object, if already available within the DDC , SP will process the check. If not available then SP will retrieve the required information from the system tablespace. 10. After this SP will approach the optimizer, who will read the SQL statement and generate the execution plan of the query. 11. After generation of the e-plan's the SP will pick the best e-plan and go to the L.C. 12. SP will keep the e-plan in the L.C. Along with the original SQL text. 13. At this point in time the parsing ends and the execution of the SQL statement will begin.

14. SP will then go to the database cache and checks whether the data required by the query is already available or not in the cache. 15. If available that data can be returned to the client else it brings the data from the database files. 16. If sorting and filtering is required by the query then the PGA is utilized along with the temporary tablespace for performing sort run. 17. After sort run the data is returned to the client and SQL*plus client will show the data to the users. There may two Cause for SNAPSHOT-TOO-OLD error:(1) Since space managemnt in undo segment follo LRU algorihm.So in space allocated for to undo segment will so small to data may frequently swaped out from undo segement and may cause SNAPSHOT-TOO-OLD error. (2) It also depend on the undo retention policy set by the DBA.If the undo retention time is set to very low the the data will sweped out too early and may cause SNAPSHOT-TOO-OLD error. Explanation :First you have to understand that Oracle is a MVCC (multiversion concurrency control) or "repeatable read" database system. Queries are returned with all rown consistent with respect to the point in time (SCN) you bagan the query (or earlier with "flashback query"). Oracle accomplishes this by examining each block as you query it. If a block has had a transaction started on it by another session since your query SCN, your query refers to the UNDO to determine if a prior version of the block needs to be reconstructed in cache to fulfill your consistent read. ORA-01555 (Snapshot too old) is simply the error returned when your read-consistent query (not necessarily a transaction), cannot find the necessary UNDO to reconstruct the way a block looked when you began the query. This occurs because other users have been using the UNDO and the necessary entries have been overwritten by other users performing DML. Often tis happens when your query has been running for a very long time (poorly-tuned query). Therefore the first question to someone complaining about OR-01555 should be "How long did your query run before you get the error?" There are two cases: WITH the UNDO_TABLESPACE specified (Automatic Undo Management) and WITHOUT the UNDO_TABLESPACE (old-fashioned rollback segments). With UNDO_TABLESPACE: You may get ORA-01555 when your query runs for longer than the UNDO_RETENTION parameter. You can either tune the query or increase

UNDO_RETENTION. It is also possible that the size of the UNDO_TABLESPACE may need to be increased to fulfull the needs of the UNDO_RETENTION parameter. With old-fashioned rolback segments: When other users performing transactions use the rollback segments enough that the entries needed to reconstruct a read-consistent view for you have been overwritten, you receive ORA-01555. In all cases, the first solution is to make the query run faster, so that the chance of needed a very old block version is reduced. Only if that is impossible should you consider increasing UNDO_RETENTION or increasing the size of the UNDO.