Blocking It Out: Breaking (PCT)Free from Chains

DBA group: July, 2009DBA group: July, 200911

Blocking It Out:Blocking It Out:Breaking (PCT)Free from ChainsBreaking (PCT)Free from Chains

Philip RicePhilip Rice

Univ. of California Santa CruzUniv. of California Santa Cruz

Case Study: Overview of IssuesCase Study: Overview of Issues

Prompted by performance problem inPrompted by performance problem in Identity Management batch process: Identity Management batch process: Query is normally 1000+ statements per hourQuery is normally 1000+ statements per hour Slowed to 3 minutes each execution instead of Slowed to 3 minutes each execution instead of

normal 0.5 secondsnormal 0.5 seconds Culprit: Culprit: CHAIN_CNTCHAIN_CNT = 25% of table, other stats OK = 25% of table, other stats OK CBO in 9.2 never complained, 10.2 gave very CBO in 9.2 never complained, 10.2 gave very

bad plan, soon after upgradebad plan, soon after upgrade Focus became re-learning Block Mgmt details Focus became re-learning Block Mgmt details

(esp. PCTFREE), for valid performance fix(esp. PCTFREE), for valid performance fix

UCSC: July, 2009UCSC: July, 2009 Block It Out: PCTFREEBlock It Out: PCTFREE 22

Problem SQLProblem SQL

SELECT userobj.id, name, '', '', summary, '’SELECT userobj.id, name, '', '', summary, '’

FROM waveset.userobjFROM waveset.userobj

WHERE WHERE namename!=!='LASTMODIFIED’'LASTMODIFIED’

and and name name NOT LIKENOT LIKE '#DEL#%’ '#DEL#%’

and userobj.id INand userobj.id IN ( select id( select id

from waveset.userattrfrom waveset.userattr

where attrname='ADMINROLES’where attrname='ADMINROLES’

and attrval='#ID#4A4CA66222610BC0:14D921A:113E5993591:-7F74' )and attrval='#ID#4A4CA66222610BC0:14D921A:113E5993591:-7F74' )

ORDER BY name;ORDER BY name;

[Summary of Plan on next slides…][Summary of Plan on next slides…]


Execution Plan: fastExecution Plan: fast Sub-select gets ~12 rows from 1M+ row table Sub-select gets ~12 rows from 1M+ row table

using an Index Range Scanusing an Index Range Scan Outer select uses Index Unique Scan on the table Outer select uses Index Unique Scan on the table

that became (more recently) faulty with high that became (more recently) faulty with high CHAIN_CNT value: 162K rowsCHAIN_CNT value: 162K rows

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time || Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 9 | 5148 | 4 (25)| 00:00:01 || 0 | SELECT STATEMENT | | 9 | 5148 | 4 (25)| 00:00:01 |

| 1 | SORT ORDER BY | | 9 | 5148 | 4 (25)| 00:00:01 || 1 | SORT ORDER BY | | 9 | 5148 | 4 (25)| 00:00:01 |

| 2 | NESTED LOOPS | | 9 | 5148 | 3 (0)| 00:00:01 || 2 | NESTED LOOPS | | 9 | 5148 | 3 (0)| 00:00:01 |

| 3 | TABLE ACCESS BY INDEX ROWID| USERATTR | 1 | 92 | 2 (0)| 00:00:01 || 3 | TABLE ACCESS BY INDEX ROWID| USERATTR | 1 | 92 | 2 (0)| 00:00:01 |

|* 4 | INDEX RANGE SCAN | |* 4 | INDEX RANGE SCAN | USERATTR_ATTRNAMEUSERATTR_ATTRNAME | 3 | | 1 (0)| 00:00:01 | | 3 | | 1 (0)| 00:00:01 |

|* 5 | TABLE ACCESS BY INDEX ROWID| USEROBJ | 65 | 31200 | 1 (0)| 00:00:01 ||* 5 | TABLE ACCESS BY INDEX ROWID| USEROBJ | 65 | 31200 | 1 (0)| 00:00:01 |

|* 6 | INDEX UNIQUE SCAN | |* 6 | INDEX UNIQUE SCAN | USEROBJ_IDUSEROBJ_ID | 1 | | 1 (0)| 00:00:01 | | 1 | | 1 (0)| 00:00:01 |

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


Execution Plan: 10.2 CBO gets sickExecution Plan: 10.2 CBO gets sick

Faulty plan flips the inner/outer access:Faulty plan flips the inner/outer access: CHAIN_CNTCHAIN_CNT table does Index Full Scan (on table does Index Full Scan (on

“name” index: “name” index: not equalnot equal and and not likenot like) and ) and Access by RowID on 162K rows (*very* slow)Access by RowID on 162K rows (*very* slow)

Nested Loops with Index Unique Scan (on PK Nested Loops with Index Unique Scan (on PK index) -- access on 1M+ row table is still fastindex) -- access on 1M+ row table is still fast

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time || Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

| 0 | SELECT STATEMENT | | 541K| 294M| 40880 (1)| 00:05:11 || 0 | SELECT STATEMENT | | 541K| 294M| 40880 (1)| 00:05:11 |

| 1 | NESTED LOOPS | | 541K| 294M| 40880 (1)| 00:05:11 || 1 | NESTED LOOPS | | 541K| 294M| 40880 (1)| 00:05:11 |

| 2 | TABLE ACCESS BY INDEX ROWID| USEROBJ | 163K| 74M| 40863 (1)| 00:05:11 || 2 | TABLE ACCESS BY INDEX ROWID| USEROBJ | 163K| 74M| 40863 (1)| 00:05:11 |

|* 3 | INDEX FULL SCAN | |* 3 | INDEX FULL SCAN | USEROBJ_NAMEUSEROBJ_NAME | 163K| | 136 (4)| 00:00:02 | | 163K| | 136 (4)| 00:00:02 |

|* 4 | INDEX UNIQUE SCAN | |* 4 | INDEX UNIQUE SCAN | USERATTR_PKUSERATTR_PK | 3 | 267 | 1 (0)| 00:00:01 | | 3 | 267 | 1 (0)| 00:00:01 |

------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------


CBO ConsiderationsCBO Considerations

App from vendor generates SQL,App from vendor generates SQL, no bind variables no bind variables

Want to fix without long term CBO tweaks:Want to fix without long term CBO tweaks: Avoid stats locking, stats settingAvoid stats locking, stats setting Can not use SQL Profile or query rewrite, Can not use SQL Profile or query rewrite,

each statement uniqueeach statement unique Temp fix put in place with analyze command Temp fix put in place with analyze command

(9i behavior) instead of dbms_stats(9i behavior) instead of dbms_stats Focus on fix for Chained/Migrated rowsFocus on fix for Chained/Migrated rows


Basics: ChainingBasics: Chaining Chained Row: won’t fit in data block, needs pointer Chained Row: won’t fit in data block, needs pointer

to another blockto another block Chained Example: 5 columns, varchar2(4000), Chained Example: 5 columns, varchar2(4000),

each mostly full – 20K won’t fit in 8K blockeach mostly full – 20K won’t fit in 8K block LOB in-line storage: up to 4000 bytes, can LOB in-line storage: up to 4000 bytes, can

contribute to problem of not fittingcontribute to problem of not fitting Options to handle Chaining:Options to handle Chaining:

Use different tablespace with larger block size,Use different tablespace with larger block size,multiple of OS blockmultiple of OS block

For LOB: out of line storageFor LOB: out of line storage


Basics: Migration Basics: Migration (credit to Tanel Poder(credit to Tanel Poder))

Row Migration: row that originally fit into one Row Migration: row that originally fit into one block is updated, overall row length increases, block is updated, overall row length increases, block free space is already completely filledblock free space is already completely filled

Entire row migrates to new block, pointer stays Entire row migrates to new block, pointer stays in original blockin original block

Corresponding index entries are not updated Corresponding index entries are not updated with new location of row, uses pointer in original with new location of row, uses pointer in original data block instead – index maintenance trade-offdata block instead – index maintenance trade-off

Index Range Scan is significant problem, FTS is Index Range Scan is significant problem, FTS is much less so because all blocks are readmuch less so because all blocks are read


Chains: Set Me Free!Chains: Set Me Free!

DBA_TABLES.CHAIN_CNT: chained and/or DBA_TABLES.CHAIN_CNT: chained and/or migrated countmigrated count

Which do we have?Which do we have?Need to look at current row conditionsNeed to look at current row conditions

Faulty table had LOB column:Faulty table had LOB column:look at LOB and non-LOB lengthslook at LOB and non-LOB lengths

Get max/min/avg size of LOB and non-LOB,Get max/min/avg size of LOB and non-LOB,and max/min/avg size of total row,and max/min/avg size of total row,determine Chained or Migrated…determine Chained or Migrated…


Row Length Info Row Length Info (credit to Robert James Hanrahan)(credit to Robert James Hanrahan)

Use vsize and dbms_lob functions to capture Use vsize and dbms_lob functions to capture column lengths for each row:column lengths for each row:

WITH length_of_each_row AS (WITH length_of_each_row AS (

select select 3 + (3 + ( nvl( nvl(vsizevsize(id),0)+1 + nvl((id),0)+1 + nvl(vsizevsize(name),0)+1 +(name),0)+1 +

nvl(nvl(vsizevsize(lockinfo),0)+1 + nvl((lockinfo),0)+1 + nvl(vsizevsize(modified),0)+1 +(modified),0)+1 +

nvl(nvl(vsizevsize(summary),0)+1 + nvl((summary),0)+1 + nvl(vsizevsize(attr1),0)+1 +(attr1),0)+1 +

nvl(nvl(vsizevsize(attr2),0)+1 + nvl((attr2),0)+1 + nvl(vsizevsize(attr3),0)+1 +(attr3),0)+1 +

nvl(nvl(vsizevsize(attr4),0)+1 + nvl((attr4),0)+1 + nvl(vsizevsize(attr5),0)+1 +(attr5),0)+1 +

nvl(nvl(vsizevsize(counter),0)+1 (counter),0)+1 ) ) "NonLOB_lngth""NonLOB_lngth",,

nvl(nvl(dbms_lob.getlengthdbms_lob.getlength(xml),0)+1 (xml),0)+1 "LOB_lngth""LOB_lngth"

from waveset.userobj )from waveset.userobj )

[...][...]


Row Length Info Row Length Info (credit to Robert James Hanrahan)(credit to Robert James Hanrahan)

SELECTSELECT

round(avg("NonLOB_lngth")) "avg_NonLOB_lngth",round(avg("NonLOB_lngth")) "avg_NonLOB_lngth",

round(avg("LOB_lngth")) round(avg("LOB_lngth")) "avg_LOB_lngth","avg_LOB_lngth",

round(avg("NonLOB_lngth"+"LOB_lngth")) round(avg("NonLOB_lngth"+"LOB_lngth")) "avg_Total_lngth","avg_Total_lngth",

max("NonLOB_lngth") "max_NonLOB_lngth",max("NonLOB_lngth") "max_NonLOB_lngth",

max("LOB_lngth") max("LOB_lngth") "max_LOB_lngth","max_LOB_lngth",

max("NonLOB_lngth"+"LOB_lngth") max("NonLOB_lngth"+"LOB_lngth") "max_Total_lngth","max_Total_lngth",

min("NonLOB_lngth") "min_NonLOB_lngth",min("NonLOB_lngth") "min_NonLOB_lngth",

min("LOB_lngth") "min_LOB_lngth",min("LOB_lngth") "min_LOB_lngth",

min("NonLOB_lngth"+"LOB_lngth") "min_Total_lngth"min("NonLOB_lngth"+"LOB_lngth") "min_Total_lngth"

FROM (FROM (length_of_each_rowlength_of_each_row););


Row Length ResultsRow Length Resultsavg_NonLOB_lngth 562avg_NonLOB_lngth 562

avg_LOB_lngth avg_LOB_lngth 10301030

avg_Total_lngth avg_Total_lngth 15921592

max_NonLOB_lngth 726max_NonLOB_lngth 726

max_LOB_lngth max_LOB_lngth 21692169

max_Total_lngth max_Total_lngth 28262826

min_NonLOB_lngth 152min_NonLOB_lngth 152

min_LOB_lngth 244min_LOB_lngth 244

min_Total_lngth 396min_Total_lngth 396

Nothing beyond 8K block size, Nothing beyond 8K block size, all are migratedall are migrated..

LOB is consistently 2/3 of totalLOB is consistently 2/3 of total, not worth , not worth doing out of line.doing out of line.


Basics: PCTFREE in Data BlockBasics: PCTFREE in Data Block

PCTFREE reserves space in data block for PCTFREE reserves space in data block for future growth – updatesfuture growth – updates


Fix: PCTFREEFix: PCTFREE

PCTFREE of 50 allows average length to doublePCTFREE of 50 allows average length to double CHAIN_CNT showed a quarter of table with CHAIN_CNT showed a quarter of table with

migration, 42K out of 162K rowsmigration, 42K out of 162K rows Allow for max growth on multiple rows within one Allow for max growth on multiple rows within one

blockblock What is growth pattern? Start very small?What is growth pattern? Start very small?

How much from LOB vs. non-LOB?How much from LOB vs. non-LOB? Our situation: assume close to double over time Our situation: assume close to double over time

(LOB proportional), need PCTFREE of ~40-50(LOB proportional), need PCTFREE of ~40-50


Fix Method: PCTFREEFix Method: PCTFREE

Steps for fix:Steps for fix: Drop indexesDrop indexes Rename table (no dependencies found)Rename table (no dependencies found) CTAS to original table name with PCTFREE CTAS to original table name with PCTFREE

of 40: handle existing rowsof 40: handle existing rows Then PCTFREE of 50 for new rowsThen PCTFREE of 50 for new rows Can drop renamed table, purge laterCan drop renamed table, purge later Recreate indexes on CTAS table,Recreate indexes on CTAS table,

PCTFREE of 20 PCTFREE of 20 Monitor CHAIN_CNT in futureMonitor CHAIN_CNT in future


PCTUSED (legacy) vs. ASSMPCTUSED (legacy) vs. ASSM

PCTUSED (default of 40) says to not put more PCTUSED (default of 40) says to not put more rows in block until below this settingrows in block until below this setting


PCTUSED vs. ASSMPCTUSED vs. ASSM

PCTUSED uses Free List ManagementPCTUSED uses Free List Management PCTFREE + PCTUSED < 100PCTFREE + PCTUSED < 100 PCTUSED is moot point when Auto Segment PCTUSED is moot point when Auto Segment

Space Management (ASSM) is used at Space Management (ASSM) is used at Tablespace levelTablespace level Default in recent releasesDefault in recent releases PCTUSED is NULL then in dictionaryPCTUSED is NULL then in dictionary

ASSM is only in LMT – Locally Managed TblpscASSM is only in LMT – Locally Managed Tblpsc ASSM allows Segment Shrink feature, but ASSM allows Segment Shrink feature, but

Shrink does not pertain to our Migration problemShrink does not pertain to our Migration problem


ASSM in Data BlockASSM in Data Block

Status for freeness – 6 possibilitiesStatus for freeness – 6 possibilities 0 = unformatted0 = unformatted 1 = logically full1 = logically full 2 = 0-25% free2 = 0-25% free 3 = 25-50% free3 = 25-50% free 4 = 50%-75% free4 = 50%-75% free 5= 75-100% free5= 75-100% free


ASSM in Data BlockASSM in Data Block

When a block is 90% full, Freeness State will be When a block is 90% full, Freeness State will be set to 0-25% freeset to 0-25% free

If the block freeness drops below PCTFREE, If the block freeness drops below PCTFREE, freeness state will go to "FULL" regardless of freeness state will go to "FULL" regardless of percentage of free space in your block -- percentage of free space in your block -- PCTFREE is what mattersPCTFREE is what matters


Index ConsiderationsIndex Considerations

PCTUSED was never an option for IndexesPCTUSED was never an option for Indexes PCTUSED and ASSM can be considered for PCTUSED and ASSM can be considered for

data blocks, but does not pertain to index blocksdata blocks, but does not pertain to index blocks Index block is horse of a different stripe!Index block is horse of a different stripe! Data/Index block can use same tablespace Data/Index block can use same tablespace

building material, but they have different DNAbuilding material, but they have different DNA


Index Characteristics Index Characteristics (adapted from AskTom)(adapted from AskTom)

PCTFREE is used *only* when index is createdPCTFREE is used *only* when index is created After creation, index block is allowed to be After creation, index block is allowed to be

completely filled as part of normal operation, so completely filled as part of normal operation, so PCTFREE becomes meaningless at that pointPCTFREE becomes meaningless at that point


Data block is a heap,Data block is a heap, rows can go anywhere rows can go anywhere


Index Block is in a structure Index Block is in a structure (b-tree example)(b-tree example)


Index entry must go in correct locationIndex entry must go in correct location

Values for an indexed Values for an indexed MOODMOOD column column-- alpha order:-- alpha order:


Angry Apathetic Greedy

Happy Hopeful Mellow Overjoyed

Data Block Update = delete/insert for Data Block Update = delete/insert for associated index, index entry movesassociated index, index entry moves

““Mellow” is updated to “Anxious”, entry shifts to Mellow” is updated to “Anxious”, entry shifts to correct alpha location:correct alpha location:


Angry Apathetic Greedy

Happy Hopeful Overjoyed

When index entry grows,When index entry grows,space within block is shiftedspace within block is shifted

““Mellow” is now gone.Mellow” is now gone.

““Happy” is updated to “Happiest”, stays in same Happy” is updated to “Happiest”, stays in same alpha location:alpha location:


Angry Anxious Apathetic Greedy

Index CharacteristicsIndex Characteristics

When growth no longer fits, two possibilities:When growth no longer fits, two possibilities: Entry is at end of blockEntry is at end of block Entry is anywhere else, not at endEntry is anywhere else, not at end


Entry on right end can not fit:Entry on right end can not fit:~90-10 split to new/empty block~90-10 split to new/empty block

““Greedy updated to “Greediest”:Greedy updated to “Greediest”:


Angry Anxious Apathetic

Happiest Hopeful Overjoyed

Greediest

Entry in middle can not fit:Entry in middle can not fit:~60-40 split to new/empty block~60-40 split to new/empty block

““Anxious” updated to “Argumentative”:Anxious” updated to “Argumentative”:


Angry Argumentative

Happiest Hopeful Overjoyed

Apathetic Greedy

Index CharacteristicsIndex Characteristics

Split is very high cost operation (Doc 30405.1)Split is very high cost operation (Doc 30405.1) High PCTFREE (High PCTFREE (used at index creation only!used at index creation only!) )

helps minimize future splitshelps minimize future splits How do table values arrive (i.e. inserts)?How do table values arrive (i.e. inserts)?

Two possibilities:Two possibilities: Random orderRandom order SequentialSequential


Index Characteristics: SequentialIndex Characteristics: Sequential

Value is always GREATER THAN all values that Value is always GREATER THAN all values that existed at index creation time,existed at index creation time,aka "a monotonically increasing value”aka "a monotonically increasing value” -- examples: -- examples: Primary Key using Oracle SequencePrimary Key using Oracle Sequence Activity date column using SYSDATEActivity date column using SYSDATE

Inserts on right side can cause buffer busy waitsInserts on right side can cause buffer busy waits Monotonically Monotonically decreasingdecreasing value is same effect value is same effect


Many Deletes after Sequential ArrivalMany Deletes after Sequential Arrival Index space is *not* reused unless block Index space is *not* reused unless block

becomes totally empty, because no values becomes totally empty, because no values would logically fit into that data structurewould logically fit into that data structure


09-AUG-1974

04-JUL-2009 05-JUL-2009 06-JUL-2009 07-JUL-2009

08-JUL-2009 09-JUL-2009 10-JUL-2009 11-JUL-2009

17-OCT-1989

…Blocks with entries far in the past are nearly empty. Blocks with recent entries are mostly full…

Index Characteristics with many deletesIndex Characteristics with many deletes

For many deletes on sequential (monotonic):For many deletes on sequential (monotonic): Rebuild *might* make senseRebuild *might* make sense Coalesce ("online friendly") betterCoalesce ("online friendly") better

For data arriving in random order:For data arriving in random order: Index rebuild could mean unnecessary splits, Index rebuild could mean unnecessary splits,

unless sufficient PCTFREE is includedunless sufficient PCTFREE is included Natural “puffiness” Natural “puffiness”


Table/Index ScenariosTable/Index Scenarios

If table is If table is emptyempty when index is created, and data when index is created, and data filled in laterfilled in later, PCTFREE on index has no bearing , PCTFREE on index has no bearing because index will fill blocks completely as part of because index will fill blocks completely as part of normal operationnormal operation

If adding an index to a populated table If adding an index to a populated table that is on that is on monotonic sequencemonotonic sequence, PCTFREE = 0 is acceptable, PCTFREE = 0 is acceptable

If adding an index to a populated table If adding an index to a populated table that is that is random insert/update/deleterandom insert/update/delete, no perfect number , no perfect number for PCTFREE, not related to value for data blockfor PCTFREE, not related to value for data block


Final PointsFinal Points Larger index block size can help reduce Height,Larger index block size can help reduce Height,

but will not help data block migration but will not help data block migration PCTFREE choice for our Problem:PCTFREE choice for our Problem:

Data block:Data block: 40 during migration fix, 40 during migration fix, 50 after that: more blocks to read in FTS, 50 after that: more blocks to read in FTS,

but minor compared to faulty CBO planbut minor compared to faulty CBO plan Index block:Index block:

20 (indexes recreated as part of fix) 20 (indexes recreated as part of fix)-- Will prevent block splits for a while-- Will prevent block splits for a while-- Index block splits won’t affect -- Index block splits won’t affect

CHAIN_CNTCHAIN_CNTUCSC: July, 2009UCSC: July, 2009 Block It Out: PCTFREEBlock It Out: PCTFREE 3535


Don’t get caught by surprise!Don’t get caught by surprise!


A & QA & Q

Acknowledgements for reference material: Tanel Poder, Acknowledgements for reference material: Tanel Poder, Tom Kyte (Tom Kyte (adapted from thread in AskTomadapted from thread in AskTom))

A & Q A & Q AAnswers: Wisdom to share?nswers: Wisdom to share?QQuestions?uestions?

Date post:	14-Jan-2016
Category:	Documents
Upload:	lalo
View:	43 times
Download:	0 times

Blocking It Out: Breaking (PCT)Free from Chains

Documents