Hi! This series of articles have been focused on Oracle RDBMS data block internals. I’ve discussed how Oracle manages space in the blocks, how row level locking works (how more than one user can be making changes to rows in the same blocks), and how Oracle writes to the blocks. This article dives into read consistency, which utilizes previously discussed structures, mostly the Interested Transaction List (ITLs). I’ll illustrate here how row level locking affects users accessing data. The above illustration comes from my Advanced SQL Tuning class. I’ll discuss the relationship of the ITL list, V$Transaction, and the Undo Tablespace. As previously discussed, the ITL list keeps track of the different users and the rows they are updating. The entry in this table, the transaction id, becomes that user’s id throughout their tranasaction…and is maintained and is useful until a commit or rollback is issued. V$Transaction keeps track of active transactions, again, by this same transaction ID and other information stored here is the rollback segment, now called Undo Tablespace segment assigned to the transaction. This information is used if a read-consistent image of a data block is required or a rollback was issued. Data is being written to the database as you make the changes. Oracle goes with the thought that you will probably commit, not rollback. When any work starts in Oracle, a SCN is assigned. This becomes your transaction ID. SCN is system change number, a base 64 number physically stored in 2 parts (just an fyi…), and can cover an incredible length of time. So, in the above illustration, Sally starts a long running SQL statement. It’s feeding data into a report perhaps. Her query starts at 10am and she is given an SCN of 5 (let’s keep it simple for this example). This information is logged into the V$Transaction table. Stan realizes his batch job had an issue from the night before, he fixes the problem and starts a long running update command at 10:05. His transaction id is a 10. As the readers (Sally in this example) reads data blocks, they compare the SCN assigned to them to the SCN in the block. They are good to use the data as long as their SCN is > than that in the data block. Ok, Sally’s SQL starts to run slow. She is bumping into blocks that Stan has now updated and has recorded a SCN of 10…Stan’s SCN number. Stan has not committed yet so Sally’s transaction requests the before image of the block from Stan’s assigned undo tablespace. This scan is like a full-table scan…so…it is slow. Once loaded, Sally’s transaction again checks the SCN (if more than 1 person was updating these blocks, there might be more than one that is needed to produce the block as it existed when Sally’s transaction started). This is the key and best way to describe read-consistency. Sally is guaranteed that the data will be consistent with the time she started her request. If, for any reason (will discuss these reasons in the next article in this series) Sally’s transaction cannot get the before image of the data block, she is issued an Ora-01550 Snap Shot Too Old error. She has to start her query over and perhaps Stan would have commited so her report will run fast now. Read consistency is a lot of work. If there are many blocks that Sally will bump into, Oracle repeats this process over and over. When this is occurring, it is easy to notice as Oracle logs time on a wait event called ‘Consistent Changes’. IF the DBA staff notices that they are getting these wait events, it’s easy to see the object that is having the issue (P1 is the file number and P2 is the block number, use this information in DBA_EXTENTS, previously discussed, to retrieve the object name). Easy to discover, maybe not so easy to solve. A reporting database using a product like Shareplex to maintain duplicate data might be useful. This feature is nice for a number of reasons. The app can make changes real-time and not have any effect on people querying the data. Also, the reporting data store can be tuned for reporting where the active data store can be tuned for inserts. Using materialized views to subset and maintain the data might be useful as well particularly if real time data isn’t a hard requirement. Next month, I’ll discuss our old friend fragmentation…that seems to have taken a back seat in today’s database environment. Dan Hotka Oracle ACE Director Author/Instructor/CEO
↧