Oracle 10g Block Change Tracking

Inside Out
AIex Gorbachev
The Pythian Group
2006 November
http://www.pythian.com/documents/UKOUG06-10gBCT.ppt
Who am I?
Senior Oracle DBA at The Pythian Group
Working with Oracle since 97
Pythian is a leading DBA outsourcing
provider remote DBA 24x7
OIIices worldwide Canada, US, UK, India,
Australia
I`m blogging at www.pythian.com/blogs
This presentation exists in parts because
Pythian sponsors and encourages R&D
Disclaimer
Most oI inIormation in this presentation is
acquired by means oI experiments and can
be incomplete or even incorrect
OIIicial Oracle documentation does not
give any inIormation on implementation
Metalink public notes do not provide any
additional reIerence
Tools and Techniques to Use
X$KRC tables
Snap and compare
10046 trace
DBWR doesn`t post 'db Iile parallel write
when AIO enabled (!)
Linux 'strace and 'lsoI
Hex dump oI BCT Iile ('bvi)
Events 19774 and 19775 (what`s that?)
Agenda
Block Change Tracking overview
BCT Iile structure
BCT Iile content evolution
Inter-process communication
Impact analysis
What`s next?
Traditional Incremental Backup
RMAN reads every block
Compares block SCN with checkpoint
SCN oI parent incremental backup
II block SCN ~ backup SCN than copy
this block
Block Change Tracking
RMAN retrieves checkpoint SCN oI a
parent incremental backup
RMAN identiIies blocks to read based on
a bitmap in a BCT Iile
BCT development Ior 5 years ?
Comments in oraus.msg dated back to 2001
Only available in the Enterprise Edition
BCT File Block Structure
Blocks are 512 bytes (Linux)
Generally same Iormat as dataIile blocks
1
st
byte block type
0x29 BCT Iile header (X$KRCFH)
0x2F dataIile descriptors extent header
0x30 dataIile descriptor block (X$KRCFDE)
0x33 bitmap extent header (X$KRCFBH)
0x34 bitmap block (X$KRCBIT)
2
nd
byte block Iormat (0x22 Ior BCT Iile)
Some Iields are not used (like SCN)
BCT File Structure
H 15 bIk. type x36
header
1056 bIk. type x2B
X$KRCCDE
1 row = 1 bIock
PK - CSNO
1056 bIk. type x2C
X$KRCCDS - references to
descriptor extent headers
1 row = 1 bIock; PK - CSNO
fiIIer
47 bIk. type x36x3563 bIk. type x36
1 header + 63 bIk.
datafiIe descriptors
bitmap extent bitmap extent bitmap extent
.
X$KRCCDR
BCT File Header
Table X$KRCFH
FHSWV and FHCVN version inIormation
FHDBI and FHDBN DBID and DB name
FHFSZ Iile size
FHBSZ block size (512 bytes on Linux)
EXTBLKS extent size in blocks (64 on Linux)
RSZNEWEXTCNT next chunk size in extents
320 * 64 * 512 bytes 10 MB
First block oI the Iile is skipped so Iile header is
the second block
DataIile Descriptors
Table X$KRCFDE
FNO dataIile #
CHUNK chunk size in database blocks
32 kilobytes on Linux
CRESCN & CRETIME dataIile creation SCN and time
CURRLOWSCN starting SCN Ior the current version
CURRHIGHSCN highest SCN (max possible)
CURRFIRST/LAST header block# oI Iirst/last bitmap extents
CURREXTCNT number oI bitmap extents
CURRVERCNT & VERTIME current version number & TIME
HISTFIRST/LAST/EXTCNT/VERCNT/VERTIME
OLDESTLOW starting SCN oI the oldest version available
Pre-created according to dbIiles init.ora parameter
One descriptor per dataIile, 4 descriptors per block
One extent holds 252 dataIiles
Extent Map
Table X$KRCEXT
BNO extent header block#
USED Ilag
0 unused
1 used
Extent map only indicates whether extent
is used
No extent type inIo
Bitmap Extents
1 header 63 bitmap blocks (32 KB)
Every bitmap block provides 488 bytes or 3904
bits; i.e. 3904 chunks covered
1 bitmap block serves 122 MB oI space in
dataIile
1 bitmap extent can track 7686 MB oI data
Extents allocated when Iile resized
7 versions kept
Every version occupies separate extent(s)
Bitmap Extent Header
Table X$KRCFBH
CTFBNO bitmap extent header block#
FNO dataIile#
VERCNT version number
VERTIME version start time
HIST as in X$KRCFDE
LOW / HIGH start / end version SCNs
Bitmap Block
Table X$KRCBIT
CTFBNO extent header block#
VERCNT, VERTIME, FNO as beIore
BNO Iirst block# oI the chunk
BCT chunk size in db blocks
Chunk Change Tracking
BCT File Sizing
Initial size is 1 MB 10 MB Ior bitmaps
320 extents * 32 KB 10 MB
Considering 7 versions 45 extents leIt
~338 GB oI data tracked by 10 MB chunk
oI BCT Iile
In RAC every instance uses its own
extents so multiply by number oI nodes
Small Sizing Misconception
'For each datafile, a minimum of 320K of space is
allocated in the change tracking file, regardless of the si:e
of the file. Thus, if you have a large number of relatively
small datafiles, the change tracking file is larger than for
databases with a smaller number of larger datafiles
containing the same data.`
This is incorrect:
Created 70 dataIiles BCT Iile still 11 MB
BCT File Evolution
New dataIile, drop tablespace
Changing data
Incremental backup
Level 0, 1, 2
cumulative
Restore
New DataIile
CREATE TABLESPACE TBS1 DATAFILE SIZE 128M;
Allocate bitmap extent (X$KRCEXT)
II reserve is empty - X$KRCCDS. RESEXTCNT and RESFIRST
This mechanism is not clear yet
Format dataIile descriptor (X$KRCFDE)
CURRLOWSCN0
CURRHIGHSCN2
48
-1
CURRVERCNT1 or next version aIter deleted dataIile with
same Iile#
CURRVERTIMESYSDATE
Format bitmap extent header (X$KRCFBH)
Mark in the bitmap the Iirst Iew chunks Iormatted in the
dataIile
Drop Tablespace
Clear bitmap (X$KRCBIT)
Clear bitmap extent header (X$KRCFBH)
Clear dataIile descriptor(X$KRCFDE)
Extent becomes Iree in X$KRCEXT but
with some delay
Changing Blocks in a DataIile
Do nothing iI the chunk was already
changed in the current version
Block SCN ~ X$KRCFDE.CURRLOWSCN
Ior this dataIile
Otherwise, set the bit to 1 in the bitmap
Visible as a new row in X$KRCBIT
DataIile Incremental Backup
Mark current bitmap as historical (X$KRCFBH)
Set XFLAGS to 3; set LOW and HIGH
Purge bitmap older than 7 versions
Allocate bitmap extent and Iormat bitmap header (X$KRCFBH)
No data Iilled no VERCNT/TIME/LOW/HIGH/.
Update dataIile descriptor
CURR and HIST attributes
Update BCT Iile header (X$KRCFH)
Bitmap header`s Iilled with Iirst dataIile change
Set XFLAGS to 3
Set CURRVERCNT to last version 1
Set CURRVERTIME Irom dataIile descriptor
Nothing is done iI there were no changes since parent backup level
Purging Oldest Version
II more than 7 versions exist (including current)
Which version to purge on backup?
Version 1
Which version to purge on backup?
Version 2
No merge
How many blocks does RMAN read on backup
10?
All blocks
1 2
- LeveI 0 backup - LeveI 1 backup
3 4 5 6 7 8 9 10
Restore
BCT Iile is usable aIter restore
Remove a dataIile
Put that dataIile online
Restore Irom backup using
RMAN~ RESTORE DATAFILE #~;
Recover:
RMAN~ RECOVER DATAFILE #~;
Online dataIile
Blocks Read Prediction
SELECT count(distinct bno) 32
FRJM x$krcbit b
WHERE b.fno = 7 AND b.vercnt =
(SELECT MIN(ver) FRJM
(SELECT curr_vercnt ver, curr_highscn high, curr_lowscn low
FRJM x$krcfde WHERE fno = 7
UNIJN ALL
SELECT vercnt ver, high, low
FRJM x$krcfbh WHERE fno = 7)
WHERE (SELECT MAX(bd.checkpoint_change#)
FRJM v$backup_datafile bd
WHERE bd.file# = 7
AND bd.incremental_level <= 1) btween low and high);
Parent
IeveI
Blocks Read Prediction
32 K extent size hard-coded
First blocks overhead not counted
No case when required version is purged
All blocks are read
No case with optimization Ior level 0
v$dataIilebackup.usedoptimization
No case when Iile wasn`t changed
1 block read
Single dataIile
RAC
No accounting Ior non-available backups
Which Processes Use BCT File?
Any process can read BCT Iile
Access to X$KRC tables translates into
number oI "change tracking file synchronous
read" waits
CTWR writes to BCT Iile
RMAN writes to BCT Iile
CTWR
DBWR
Who Does What
Shadow process changes a block
Nothing Ior CTWR
Checkpoint
CKPT signals to DBWR and
waits
DBWR Ilushes dirty blocks and
posts to CKPT
CKPT posts to CTWR
CTWR updates BCT Iile header
and posts CKPT
CKPT updates controlIile and
dataIile headers checkpoint OK
CTWR updates bitmaps and
controlIile
DBWR ~ CTWR
change tracking state cha.
Shadow
process
bIocks
CKPT
Shared Pool Areas
CTWR buIIer?
change tracking state cha.
BCT 'crash recovery?
change tracking recovery
Direct / parallel load?
pq_krcpx
scntab_krcpx
krcpx
krccr_hp_krccx
CTWR Wait Events
Updates block 18 (X$KRCCDE) every 20-60
seconds
change tracking file synchronous read
change tracking file synchronous write
While updating CTWR
Reads and writes to controlIile
control file sequential read
control file parallel write
Reads and writes to BCT Iile (except bitmap extents)
change tracking file synchronous read
change tracking file synchronous write
CTWR Wait Events Unknown
Bitmap updates are not instrumented no wait
event posted
Issues pwrite64 system call
Supposed to be change tracking file parallel
write?
DBWR writing to the CT buIIer?
block change tracking buffer space
New enqueues
enq: CT %
New latches
change tracking state change latch
change tracking optimization SCN
change tracking consistent SCN
Direct Load and BCT
According to my experiments CTWR is
not involved directly
Change tracking change state is not lost
(stored in shared pool?)
CTWR updates BCT Iile during its next
'heartbeat
This write is not timed either (!)
or on the next checkpoint
Who Does What During Backup
For each dataIile
RMAN reads Irom BCT Iile and writes to the header
and X$KRCCDR
RMAN signals to CTWR to create a new version
CTWR creates new version and post back to RMAN
RMAN reads bitmaps and other BCT Iile areas to
Iind out the blocks to backup
RMAN starts reading blocks and writing to backup
Incremental Backup Levels
CTWR doesn`t distinguish levels
New version created on any incremental backup
CareIul with BCT Ior incremental backups with
cycle more than 8 days
Monthly cycle with 2 levels
Monthly level 0
Weekly level 1
Nightly level 2
Hourly level 3
Hourly backup makes BCT useless
Possible Negative Impact
Space overhead is practically zero
PerIormance impact is minimal
BCT Iile updates are triggered in the
background
Bulk oI updates are done in the background
oI another background action
Fallback (disable) is easy and online
In case oI problems recreate BTC Iile
ReIerences
None?
Backup and Recovery Basics, Section 4.4
Metalink Notes 262853.1 and 306112.1
Advanced Research Techniques in Oracle
by Tanel Pder, UKOUG 2006
tomorrow 15:05 - 15:50 and 16:25 - 17:25
Hall 1
" & A
Thank you!
gorbachevpythian.com
AIex Gorbachev
The Pythian Group
2006 November
http://www.pythian.com/blogs