Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005
Share Embed Flag
Download ePaper

Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

rekharaghuram
from rekharaghuram More from this publisher
05.11.2015 Views

CHAPTER 9 ■ REDO AND UNDO 335 OK, so now we know that we have lots of dirty blocks on disk. We definitely wrote some of them out, but we just did not have the room to hold them all. Next, we opened a cursor, but did not yet fetch a single row. Remember, when we open the cursor, the result set is preordained, so even though Oracle did not actually process a row of data, the act of opening that result set fixed the point in time the results must be “as of.” Now since we will be fetching the data we just updated and committed, and we know no one else is modifying the data, we should be able to retrieve the rows without needing any undo at all. But that is where the delayed block cleanout rears its head. The transaction that modified these blocks is so new that Oracle will be obliged to verify that it committed before we begin, and if we overwrite that information (also stored in the undo tablespace), the query will fail. So, here is the opening of the cursor: ops$tkyte@ORA10G> variable x refcursor ops$tkyte@ORA10G> exec open :x for select * from big; PL/SQL procedure successfully completed. ops$tkyte@ORA10G> !./run.sh run.sh is a shell script. It simply fired off nine SQL*Plus sessions using a command: $ORACLE_HOME/bin/sqlplus / @test2 1 & where each SQL*Plus session was passed a different number (that was number 1; there was a 2, 3, and so on). The script test2.sql they each ran is as follows: begin for i in 1 .. 1000 loop update small set y = i where x= &1; commit; end loop; end; / exit So, we had nine sessions inside of a tight loop initiate many transactions. The run.sh script waited for the nine SQL*Plus sessions to complete their work, and then we returned to our session, the one with the open cursor. Upon attempting to print it out, we observe the following: ops$tkyte@ORA10G> print x ERROR: ORA-01555: snapshot too old: rollback segment number 23 with name "_SYSSMU23$" too small no rows selected As I said, the preceding is a rare case. It took a lot of conditions, all of which must exist simultaneously to occur. We needed blocks that were in need of a cleanout to exist, and these blocks are rare in Oracle8i and above. A DBMS_STATS call to collect statistics gets rid of them so the most common causes—large mass updates and bulk loads—should not be a concern, since the tables need to be analyzed after such operations anyway. Most transactions tend to

336 CHAPTER 9 ■ REDO AND UNDO touch less then 10 percent of the block buffer cache; hence, they do not generate blocks that need to be cleaned out. In the event that you believe you’ve encountered this issue, in which a SELECT against a table that has no other DML applied to it is raising ORA-01555, try the following solutions: • Ensure you are using “right-sized” transactions in the first place. Make sure you are not committing more frequently than you should. • Use DBMS_STATS to scan the related objects, cleaning them out after the load. Since the block cleanout is the result of a very large mass UPDATE or INSERT, this needs to be done anyway. • Allow the undo tablespace to grow by giving it the room to extend and increasing the undo retention. This decreases the likelihood of an undo segment transaction table slot being overwritten during the course of your long-running query. This is the same as the solution for the other cause of an ORA-01555 error (the two are very much related; you are experiencing undo segment reuse during the processing of your query). In fact, I reran the preceding example with the undo tablespace set to autoextend 1MB at a time, with an undo retention of 900 seconds. The query against the table BIG completed successfully. • Reduce the runtime of your query (tune it). This is always a good thing if possible, so it might be the first thing you try. Summary In this chapter, we took a look at redo and undo, and what they mean to the developer. I’ve mostly presented here things for you to be on the lookout for, since it is actually the DBAs or SAs who must correct these issues. The most important things to take away from this chapter are the significance of redo and undo, and the fact that they are not overhead—they are integral components of the database, and are necessary and mandatory. Once you have a good understanding of how they work and what they do, you’ll be able to make better use of them. Understanding that you are not “saving” anything by committing more frequently than you should (you are actually wasting resources, as it takes more CPU, more disk, and more programming) is probably the most important point. Understand what the database needs to do, and then let the database do it.

336<br />

CHAPTER 9 ■ REDO AND UNDO<br />

touch less then 10 percent of the block buffer cache; hence, they do not generate blocks that<br />

need to be cleaned out. In the event that you believe you’ve encountered this issue, in which a<br />

SELECT against a table that has no other DML applied to it is raising ORA-01555, try the following<br />

solutions:<br />

• Ensure you are using “right-sized” transactions in the first place. Make sure you are not<br />

committing more frequently than you should.<br />

• Use DBMS_STATS to scan the related objects, cleaning them out after the load. Since the<br />

block cleanout is the result of a very large mass UPDATE or INSERT, this needs to be done<br />

anyway.<br />

• Allow the undo tablespace to grow by giving it the room to extend <strong>and</strong> increasing the<br />

undo retention. This decreases the likelihood of an undo segment transaction table slot<br />

being overwritten during the course of your long-running query. This is the same as the<br />

solution for the other cause of an ORA-01555 error (the two are very much related; you<br />

are experiencing undo segment reuse during the processing of your query). In fact, I<br />

reran the preceding example with the undo tablespace set to autoextend 1MB at a time,<br />

with an undo retention of 900 seconds. The query against the table BIG completed<br />

successfully.<br />

• Reduce the runtime of your query (tune it). This is always a good thing if possible, so it<br />

might be the first thing you try.<br />

Summary<br />

In this chapter, we took a look at redo <strong>and</strong> undo, <strong>and</strong> what they mean to the developer. I’ve<br />

mostly presented here things for you to be on the lookout for, since it is actually the DBAs or<br />

SAs who must correct these issues. The most important things to take away from this chapter<br />

are the significance of redo <strong>and</strong> undo, <strong>and</strong> the fact that they are not overhead—they are integral<br />

components of the database, <strong>and</strong> are necessary <strong>and</strong> m<strong>and</strong>atory. Once you have a good<br />

underst<strong>and</strong>ing of how they work <strong>and</strong> what they do, you’ll be able to make better use of them.<br />

Underst<strong>and</strong>ing that you are not “saving” anything by committing more frequently than you<br />

should (you are actually wasting resources, as it takes more CPU, more disk, <strong>and</strong> more programming)<br />

is probably the most important point. Underst<strong>and</strong> what the database needs to do,<br />

<strong>and</strong> then let the database do it.

logo

products

Resources

Company

Terms of service
Privacy policy
Cookie policy
Cookie settings
Imprint
Change language
Made with love in Switzerland
© 2024 Yumpu.com all rights reserved

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!