Hi, Here is one from email…the original questions and my reply, my suggestions and why. I have a quick question about the rows on the IO tab of the Session Browser. I have a single SQL running that is doing a DELETE of about 1.8 million rows out of a table with 6.6 million rows and doing an index read to find them. On the IO tab I see the 'Block gets' number and the 'Block changes' numbers increasing pretty rapidly but the 'Consistent gets' is increasing very slowly and the 'Physical reads' not at all. What do the 'Block gets' and 'Block changes' represent and what blocks are they changing? I'm also seeing a lot of 'direct path write temp' wait event. What is it doing with temp? Thanks very much for your insight. It is much appreciated!! First, this is a lot of rows to delete. Almost a third of the table. I don’t believe the CBO is using an index to find the rows, but does have to maintain the indexes during the delete operations though. I didn’t get the SQL statement or the explain plan. The Block Gets and the Block Changes is where the work is happening. Seems this table has been previously accessed as most, if not all of it is already in the buffer cache…just lack of physical reads really. IF the block changes are matching up with the block gets…then this delete is affecting almost every block in the table. IF the consistent gets were increasing…this means someone else is updating the table while this delete is going on…consistent gets is the read consistency mechanism of Oracle…it works extremely well…it can really slow down DML operations… I recently posted an article about Block Internals and how ASSM works. I suggested this person review some of those posts. I feel the TEMP work is the result of the explain plan processing…the number of rows/size of the rows exceeds the result set workspace while processing the explain plan. This is visible in TOAD by right clicking on the explain plan and selecting Temp Space to be displayed in the explain plan display. IF a temporary tablespace name appears in this column, then the rows for that part of the result set are being written to the temp tablespace…accounting for even more work. My recommendation here is to: Drop the indexes as they would need to be rebuilt anyway, they would slow the DML process Do the delete on the table Rebuild the table as it would be fragmented as well Re-create the indexes The script tab on this table object in the Describe panel will give the syntax for the table and the indexes. I’d use this script to review the permissions, indexes, synonyms, and about anything. I’d rebuild the table using a create table as…select * from…type of syntax then drop the old and rename the new back to the old. Perhaps there is a better way to do this anymore but this is what I’d recommend. The stats shows that the delete is going across almost all the blocks in the table so there will be wasted space all over the place. ASSM is good at extent management, not necessarily row management. I hope this helps you in your day to day use of the Oracle RDBMS. Dan Hotka Oracle ACE Director Author/Instructor/CEO
↧