1. A user requests a connection to the Oracle database through his login credenital.
2. This login credential is accepted by the listener on server side and then listener hand over the login credential to PMON background process.
3. PMON checks the autheticity of the user in the data dictionary cache of the Shared pool area. If the detail of user is found in the data dictionary then PMON creates a server process and allocate a memory area PGA to that user. And sends acknowlegement for successfull connection to user.
4. If PMON does not find the detail in the data dictionary cache, it checks in the datafiles and if details found a copy of that is placed in the data dictionary cache and user is acknowleged for successfull connection.
5. If details are not found in the datafile also then PMON sends acknowledgement of unsuccessfull connection to user.
6. Then the user executes a statement to insert a new row into a table.
7. PMON checks the user’s privileges to make sure the user has the necessary rights to perform the insertion. If the user’s privilege information isn’t already in the library cache, it will have to be read from disk into that cache.
8. If the user has the requisite privileges, server process checks whether a previously executed SQL statement that’s similar to the one the user just issued is already in the shared pool. If there is, Oracle executes this version of the SQL; otherwise Oracle parses and executes the user’s SQL statement. Oracle then creates a private SQL area in the user session’s PGA.
9. Oracle first checks whether the necessary data is already in the data buffer cache. If not, the server process reads the necessary table data from the datafiles on disk.
10. Oracle immediately applies row-level locks, where needed, to prevent other processes from trying to change the same data simultaneously.
11. The server process writes the change vectors(redo) to the redo log buffer.
12. The server process modifies the table data (inserts the new row) in the data buffer cache.
13. The user commits the transaction, making the insertion permanent. Oracle releases the row locks after the commit is issued.
14. The log writer process immediately writes out the changed data in the redo log buffers to the online redo log file.
15. The server process sends a message to the client process to indicate the successful completion of the INSERT operation. The message would be “COMMIT COMPLETE” in this case. (If it couldn’t complete the request successfully, it sends a message indicating the failure of the operation.)
16. Changes made to the table by the insertion may not be written to disk right away. The database writer process writes the changes in batches, so it may be some time before the inserted information is actually written permanently to the database files on disk.
2. This login credential is accepted by the listener on server side and then listener hand over the login credential to PMON background process.
3. PMON checks the autheticity of the user in the data dictionary cache of the Shared pool area. If the detail of user is found in the data dictionary then PMON creates a server process and allocate a memory area PGA to that user. And sends acknowlegement for successfull connection to user.
4. If PMON does not find the detail in the data dictionary cache, it checks in the datafiles and if details found a copy of that is placed in the data dictionary cache and user is acknowleged for successfull connection.
5. If details are not found in the datafile also then PMON sends acknowledgement of unsuccessfull connection to user.
6. Then the user executes a statement to insert a new row into a table.
7. PMON checks the user’s privileges to make sure the user has the necessary rights to perform the insertion. If the user’s privilege information isn’t already in the library cache, it will have to be read from disk into that cache.
8. If the user has the requisite privileges, server process checks whether a previously executed SQL statement that’s similar to the one the user just issued is already in the shared pool. If there is, Oracle executes this version of the SQL; otherwise Oracle parses and executes the user’s SQL statement. Oracle then creates a private SQL area in the user session’s PGA.
9. Oracle first checks whether the necessary data is already in the data buffer cache. If not, the server process reads the necessary table data from the datafiles on disk.
10. Oracle immediately applies row-level locks, where needed, to prevent other processes from trying to change the same data simultaneously.
11. The server process writes the change vectors(redo) to the redo log buffer.
12. The server process modifies the table data (inserts the new row) in the data buffer cache.
13. The user commits the transaction, making the insertion permanent. Oracle releases the row locks after the commit is issued.
14. The log writer process immediately writes out the changed data in the redo log buffers to the online redo log file.
15. The server process sends a message to the client process to indicate the successful completion of the INSERT operation. The message would be “COMMIT COMPLETE” in this case. (If it couldn’t complete the request successfully, it sends a message indicating the failure of the operation.)
16. Changes made to the table by the insertion may not be written to disk right away. The database writer process writes the changes in batches, so it may be some time before the inserted information is actually written permanently to the database files on disk.
No comments:
Post a Comment