ORA-14452: attempt to create, alter or drop an index on temporary table already in use

บางทีเราเห็นว่าไม่มีอะไรรันกับ object นั้นแล้วพอจะ drop มันก็ดันแจ้งว่ามีคนใช้อยู่

เราสามารถใช้ query ประมาณนี้เพื่อหา user ที่เป็นคน lock object นั้นอยู่แล้วค่อย kill ออกได้ครับ

select * from v$lock where id1 = (select object_id from dba_objects 
where owner = 'KITTI' and object_name = 'DEPARTMENTS');

ORA-06553: PLS-213: package STANDARD not accessible

Error นี้อาจเกิดขึ้นเพราะเรา Create Database ผ่าน command เองโดยไม่ได้ใช้ DBCA Tool
ซึ่งเราอาจ login ด้วย RMAN ไม่ได้และไม่สามารถ Query Data Dictionary Views ได้ด้วย
ซึ่งปัญหานี้ส่วนใหญ่มาจากที่เราไม่มี catalog database กับ procedures

ลองแก้ด้วยการรันสคริปต์ catalog.sql กับ catproc.sql ที่อยู่ใน $ORACLE_HOME/rdbms/admin/

SQL> @?/rdbms/admin/catalog.sql
...
...
...
...

 SQL> @?/rdbms/admin/catproc.sql
 ...
...
...
...

เมื่อรันเสร็จลอง Query Data Dictionary Views และลอง Connect เข้า RMAN ดูครับ

Resumable Space Allocation

Resumable space allocation จะช่วยให้ลดปัญหางานที่ต้องทำแล้วเกิดพื้นที่เก็บข้อมูลเต็ม แล้วลดเวลาที่ต้องรันใหม่ด้วยการระงับ (suspending) งานนั้นไว้ก่อนแทนที่จะยกเลิก (Terminate) งานนั้นเลย
ในขณะที่ Operation ถูก suspend DBA สามารถเพิ่ม disk space ไปที่ tablespace นั้นหรือเพิ่ม quota ให้กับ user นั้นๆได้ เมื่อเราเพิ่มเสร็จแล้ว Operation ที่ถูกระงับจะเริ่่มทำงานต่อไปโดยอัตโนมัติ


ทำความเข้าใจกับ Resumable Space Allocation
ถ้า statement ถูกระงับ transaction ที่เป็นเจ้าของ statement นั้นจะถูกระงับไปด้วย
เงื่อนไขตามนี้สามารถทำให้เกิดการ suspend แล้วใช้ resumable space allocation ได้
- Operation รันจน Permanent หรือ Temporary tablespace เต็ม
- Extents ถึงค่า Maximum ของ Tablespace นั้น
- User ใช้งานจนเกิน quota

เราสามารถควบคุมระยะเวลาที่ statement จะถูก suspend ค่า default คือ 2 ชั่วโมง หากไม่มีการเพิ่ม disk space หรือ quota เข้าไปมันจะเด้ง error message ขึ้นมาที่ user หรือ application นั้น

Command 4 ประเภทที่สามารถ resumable :
- SELECT : SELECT statements จะเข้าสู่การ resumable ได้ในกรณีเดียวคือรันจน temporary tablespace เต็มเมื่อเรามีการทำ sort operation เช่น ORDER BY , DISTINCT , หรือ UNION
- DML Commands : การ INSERT , UPDATE , DELETE สามารถทำให้ tablespace เต็มได้ ในกรณีของ DELETE อาจทำให้ undo tablespace เต็ม
- SQL*Loader : จาก command sqlldr เราสามารถเซต RESUMABLE parameter เป็น TRUE เราสามารถกำหนดชื่อของ resumable operation ด้วย RESUMABLE_NAME parameter ได้ด้วยตลอดจน resumable timeout ด้วย RESUMABLE_TIMEOUT parameter
- DDL Commands : ทุก DDL commands ที่ต้องใช้ disk space สำหรับ segments ใหม่หรือที่มีอยู่แล้วอาจ resumable ได้เช่น
   -- CREATE TABLE . . . AS SELECT (CTAS)
   -- CREATE INDEX
   -- ALTER TABLE . . . [MOVE | SPLIT] PARTITION
   -- ALTER INDEX . . . REBUILD
   -- ALTER INDEX . . . [REBUILD | SPLIT] PARTITION
   -- CREATE MATERIALIZED VIEW


การตั้งค่า Resumable Space Allocation
เราสามารถเปิดใช้งาน Resumable Space Allocation ได้ง่ายๆโดยเซตระดับ Instance ด้วย RESUMABLE_TIMEOUT initialization parameter หรือระดับ session ด้วย ALTER SESSION command
ถ้าเราเซต RESUMABLE_TIMEOUT ให้มีค่ามากกว่า 0 จะเป็นการเปิดใช้งาน Resumable Space Allocation โดยค่าที่เราเซตเข้าไปจะเป็นระยะเวลาที่ Operation จะถูก suspend ไว้และมันเป็ฯ dynamic parameter เราจึงสามารถเซตได้โดยไม่ต้องรีสตาร์ท
มีหน่วยเป็นวินาทีเ่ช่น
SQL> ALTER SYSTEM SET RESUMABLE_TIMEOUT = 7200; --เซตไว้ 2 ชั่วโมง

ถ้าเราเปิดใช้ระดับ system ทุก sessions จะสามารถใช้ Resumable Space Allocation ได้ ถ้าเราต้องการให้ users ไหนสามารถควบคุมการใช้งานได้มากขึ้นเราสามารถให้สิทธิ์ในการควบคุมเวลา suspend ของ user นั้นเองได้ด้วยการ
SQL> GRANT RESUMABLE TO users;

เมื่อ user ได้ RESUMABLE privilege แล้วจะสามารถเปิดใช้งาน resumable และตั้งเวลาเองได้ผ่าน ALTER SESSION command เช่น
SQL> ALTER SESSION ENABLE RESUMABLE;
SQL> ALTER SESSION ENABLE RESUMABLE TIMEOUT 10000;

เราสามารถดูข้อมูล resumable ได้ผ่าน data dictionary  DBA_RESUMABLE , USER_RESUMABLE เราสามารถเปิดใช้ได้ด้วยการเซต NAME มันลงไป
SQL> ALTER SESSION ENABLE RESUMABLE NAME 'Create Big Table';

SQL> select user_id,session_id,status,name,sql_text from dba_resumable;

USER_ID  SESSION_ID  STATUS    NAME                      SQL_TEXT
------------  -----------------  ------------    -------------------------  --------------------------------------------------
85                             124  NORMAL  Create Big Table      create table sale_history as select
                                                                                            * from sale_orders;

Session สามารถปิดการใช้งาน resumable ได้โดย
SQL> ALTER SESSION DISABLE RESUMABLE;


ประยุกต์ใช้กับ Trigger
เราสามารถสร้าง Trigger  AFTER SUSPEND system event เพื่อแจ้งเตือนทาง email ให้กับ User ที่เรา focus และ DBA รับทราบเช่น

CREATE OR REPLACE TRIGGER resumable_notify
    AFTER SUSPEND ON DATABASE
DECLARE
   -- ประกาศตัวแปรถ้าต้องการ
BEGIN
   DBMS_RESUMABLE.SPACE_ERROR_INFO( . . . ); --เช็คข้อมูล user id , ใน DBA_RESUMABLEจะ return ค่าเป็น boolean ถ้าไม่สามารถหาข้อมูล space error ได้จะ return FALSE
   IF object_type = 'TABLE' and object_owner = 'HR' THEN
      DBMS_RESUMABLE.SET_TIMEOUT(7200);
      UTL_MAIL.SEND('orakitti@example.com', . . .);
   ELSE -- ยกเลิก statement อื่นที่ถูก suspend ไว้
      DBMS_RESUMABLE.ABORT( . . . );
   END IF;
END;


ตัวอย่างการใช้งาน
1. Grant resumable ให้ HR ก่อน

2. สร้าง Tablespace มี 1 datafile ขนาด 10M ขึ้นมาเพื่อทดสอบ

3. Connect เข้า HR แล้วลองวนลูปสร้าง table เพื่อให้ tablespace เต็ม

4. Enable RESUMABLE และตั้งเวลาไว้ 3600 วินาที (1 ชั่ืวโมง)













5. ลองสร้างเพิ่มอีก Table นึงจะดูเหมือนว่ามันแฮ้งค์และมีข้อมูลขึ้นมาใน Alert Log ด้วย

Sat Nov 22 23:35:02 2014
statement in resumable session 'User HR(85), Session 520, Instance 1' was suspended due to
    ORA-01658: unable to create INITIAL extent for segment in tablespace KITTI_TBS
มันจะขึ้นใน EM ตรง Alert section ด้วย


6. จาก Admin user เราจะ Query  DBA_RESUMABLE เพื่อดูข้อมูลเกี่ยวกับ session ที่ถูก suspend

7. DBA ได้เพิ่ม datafile เข้าไปที่ tablespace KITTI_TBS อีก 1 ไฟล์

เมื่อเพิ่มเข้าไปเสร็จแล้ว user HR สามารถทำ Operation ต่อได้โดยอัตโนมัติ ในที่นี้คือ Create Table

และ Alert Log ก็แจ้งข้อความว่า Statement ได้ถูก resume แล้ว
Sat Nov 22 23:49:49 2014
statement in resumable session 'User HR(85), Session 520, Instance 1' was resumed


8. Query DBA_RESUMABLE อีกครั้งเพื่อยืนยันว่า Operation resumable แล้ว

** ถ้ามี session ถูก suspend จะมีข้อมูลขึ้นมาใน V$SESSION_WAIT ที่คอลัมน์ EVENT ว่า "statement suspended, wait error to be cleared"

เราควรแจ้งเตือน User ด้วยวิธีการใดๆก็ได้ (เช่น Trigger ส่งอีเมล) เพื่อให้ User เข้าใจว่าเกิดเหตุการ Suspend ขึ้น


Ref : OCP Oracle 11g Administration II Exam Guide

วิธี Implement HugePages บน Linux

สวัสดีครับ
เรามาทำความรู้จักกับ HugePages ก่อนว่าเป็นอย่างไรครับ

มันคือฟีเจอร์ตัวนึงที่มีอยู่ใน Linux kernel 2.6 โดยฟีเจอร์นี้จะทำให้เราสามารถใช้ Memory page size ได้ใหญ่กว่าปกติ (4K) นั่นเอง และมันยังสามารถใช้ได้ทั้ง 32bit กับ 64bit ได้อีกด้วยครับ

คำศัพท์ :
- Page Table : คือ Data structure ของ Virtual memory system ในระบบปฏิบัติการเพื่อเก็บการทำ mapping ระหว่าง virtual address กับ physical address นี้หมายถึงบน Virtual memory system
Memory จะถูก accessed โดยการ access ที่ Page table แล้วถึงจะ access พื้นที่บน memory จริงๆ
- TLB : ย่อมาจาก Translation Lookaside Buffer คือ buffer (หรือ cache) ใน CPU ที่ประกอบไปด้วยส่วนต่างๆของ Page Table จะมีขนาดคงที่ในขณะที่ถูกใช้เพื่อทำ virtual address translation ได้เร็วขึ้น

สิ่งที่ควรรู้ :
- เราสามารถปรับจำนวนของ HugePages ได้โดยไม่ต้องรีสตาร์ทเครื่องใหม่ แต่ในครั้งแรกที่เรา Config มันเราจำเป็นต้องรีสตาร์ทเครื่องเพื่อให้ระบบทำการจองไว้ตั้งแต่เริ่มสตาร์ทอัพ

- HugePages sizes สามารถมีได้หลายขนาดตั้งแต่ 2MB จนถึง 256MB ขึ้นอยู่กับ Kernel version กับ Hardware Architecture


ประโยชน์ของ HugePages :
- มันไม่ใช้ Swap จึงไม่ต้องกังวลเกี่ยวกับกลไก page-in/page-out  , HugePages จะเป็นการปักหมุดเอาไว้บน Physical Memory
- ใช้ TLB น้อยลง
   -- HugePages ใช้จำนวน pages น้อยกว่าในการครอบคลุมพื้นที่ Physical address
   -- TLB entries จะครอบคลุมพื้นที่ส่วนใหญ่เมื่อใช้ HugePages นั่นคือจะมี TLB เพียงเล็กน้อยที่ขาดหายไปก่อนที่ทั้งหมดหรือส่วนใหญ่ของ SGA จะถูกแมปใน SGA
   -- TLB entries น้อยกว่าสำหรับ SGA นั้นหมายถึงจะมีพื้นที่สำหรับส่วนอื่นๆมากขึ้นด้วย
- ขจัด Page Table lookup overhead
- ประสิทธิภาพโดยรวมของ Memory จะดีขึ้น  บน Virtual Memory System การทำงานของ Memory แต่ละครั้งจะถูกแบ่งการทำงานจริงๆเป็น 2 การทำงาน เมื่อ HugePages ใช้จำนวน pages เพียงเล็กน้อย โอกาสที่จะเกิด bottleneck ของการ access page table จะหายไป
- Page size ขนาดใหญ่และใช้จำนวน Page น้อยกว่า นั้นคือ Default page size คือ 4K แต่ว่า HugePages คือ 2048K นี้หมายถึงระบบจะลดจำนวนการ handle pages ลงไปถึง 512 เท่า
- Reduced Page Table Walking ตั้งแต่ HugePages ครอบคลุม virtual address range ได้ต่อเนื่องกันมากกว่า โอกาสของ TLB hit per TLB entry ก็จะสูงกว่าด้วย สิ่งนี้จะทำให้ access physical address ได้เร็วขึ้นโดยลดจำนวน page tables ที่ต้องเดินข้ามผ่านเพื่อหา physical address จาก virtual address
- ใช้ Memory น้อยกว่า จากมุมมองของ Oracle Database กับ HugePages คือ Linux kernel จะใช้ memory น้อยกว่าในการสร้าง page tables เพื่อเก็บเส้นทาง mapping ระหว่าง virtual สู่ physical สำหรับ พื้นที่ SGA เมื่อเปรียบเทียบกับ page size แบบปกติที่ใช้ memory มากกว่าเพื่อ available สำหรับ process-private หรือการใช้ PGA


Size ของ HugePages
ขึ้นอยู่กับ
- Kernel version / Linux distribution
- Hardware Platform
เราสามารถดู size ของ HugePages ที่เครื่องเราได้ด้วยคำสั่ง :
grep Hugepagesize /proc/meminfo


HugePages Reservation
ฟีเจอร์นี้ถูก implement อย่างสมบูรณ์ที่ kernel 2.6.17 ดังนั้น EL5 (based on 2.6.18) จะมีฟีเจอร์นี้ด้วย
ฟีเจอร์นี้จะทำให้ Oracle Database สามารถ allocate hugepages สำหรับ sublevels ของ SGA ได้ตามต้องการ


HugePages and Oracle 11g Automatic Memory Management (AMM)
AMM และ HugePages ไม่ compatible กัน เราต้อง Disable AMM เพื่อจะสามารถใช้ HugePages ได้


สิ่งที่เกิดขึ้นเมื่อจำนวน HugePages ไม่เพียงพอ?
- HugePages จะไม่ถูกใช้ (HugePages_Total = HugePages_Free)
- ประสิทธิภาพในการทำงานของ Database ลดลง
- System จะรัน out of memory หรือเกิด swap มาก
- Database Instance บางตัวอาจไม่สามารถ startup ขึ้นได้

USE_LARGE_PAGES initialization parameter จะช่วย manage SGAs ให้ใช้ HugePages เท่านั้นและจะแจ้ง warning หรือ ทำให้ไม่สามารถ startup ขึ้นได้ถ้ามันไม่สามารถใช้ hugepages เหล่านั้นได้


วิธีการ Configure
Step 1 : เซต memlock user limit ใน /etc/security/limits.conf เซตค่าเป็น KB ให้น้อยกว่าจำนวน Memory เล็กน้อยเช่นมี RAM 64GB เราอาจเซตเป็น
*    soft    memlock    60397977
*    hard   memlock    60397977

*ไม่มีผลเสียใดๆถ้าหากเราจะเซตค่านี้เกินกว่า SGA ที่เราต้องการ

Step 2 : Re-logon OS ใหม่โดยเข้า Account ที่เป็นเจ้าของ Oracle Software เช่น 'oracle' และเช็ค memlock limit
$ ulimit -l
60397977

Step 3 : ถ้าเราใช้ Oracle Database 11g หรือใหม่กว่า Default ของ Database จะใช้ AMM ดังนั้นเราต้องปิดการใช้งาน AMM ก่อนด้วยการเซต MEMORY_TARGET และ MEMORY_MAX_TARGET เป็น 0
ORA-00845: MEMORY_TARGET not supported on this system

Step 4 : เพื่อความชัวร์เมื่อเรา Disable AMM แล้ว (ใช้ ASMM หรือเซต memory components แต่ละตัว) เราสามารถรันสคริปต์ hugepages_setting.sh เพื่อดูจำนวน hugepages ที่จะเซต

#!/bin/bash
#
# hugepages_settings.sh
#
# Linux bash script to compute values for the
# recommended HugePages/HugeTLB configuration
#
# Note: This script does calculation for all shared memory
# segments available when the script is run, no matter it
# is an Oracle RDBMS shared memory segment or not.
# Check for the kernel version
KERN=`uname -r | awk -F. '{ printf("%d.%d\n",$1,$2); }'`
# Find out the HugePage size
HPG_SZ=`grep Hugepagesize /proc/meminfo | awk {'print $2'}`
# Start from 1 pages to be on the safe side and guarantee 1 free HugePage
NUM_PG=1
# Cumulative number of pages required to handle the running shared memory segments
for SEG_BYTES in `ipcs -m | awk {'print $5'} | grep "[0-9][0-9]*"`
do
   MIN_PG=`echo "$SEG_BYTES/($HPG_SZ*1024)" | bc -q`
   if [ $MIN_PG -gt 0 ]; then
      NUM_PG=`echo "$NUM_PG+$MIN_PG+1" | bc -q`
   fi
done
# Finish with results
case $KERN in
   '2.4') HUGETLB_POOL=`echo "$NUM_PG*$HPG_SZ/1024" | bc -q`;
          echo "Recommended setting: vm.hugetlb_pool = $HUGETLB_POOL" ;;
   '2.6') echo "Recommended setting: vm.nr_hugepages = $NUM_PG" ;;
    *) echo "Unrecognized kernel version $KERN. Exiting." ;;
esac
# End

$ ./hugepages_settings.sh
...
Recommended setting: vm.nr_hugepages = 1496
$ 

Step 5 : เพิ่ม parameter vm.nr_hugepages ลงไปในไฟล์ /etc/sysctl.conf

vm.nr_hugepages = 1496

(อาจบวกเพิ่มเข้าไปซัก 2-3 pages)

Step 6 : Stop all database instances and reboot the server

Step 7 : หลังจาก reboot เสร็จแล้วให้เปิด Database ขึ้นมา 

(เพื่อให้แน่ใจว่า Database Instances จะใช้ HugePages ตลอดแน่นอนให้เซตค่า use_large_pages = ONLY ไว้ที่ Database นั้น)

Step 8 : เราสามารถเช็คได้ว่า HugePages ถูกใช้หรือไม่

# grep HugePages /proc/meminfo
HugePages_Total: 1496
HugePages_Free: 485
HugePages_Rsvd: 446
HugePages_Surp: 0

เพื่อให้แน่ใจว่า HugePages ได้ถูกใช้  HugePages_Free ควรมีค่าน้อยกว่า HugePages_Total

Ref : Oracle Support (Doc ID 361323.1)

ORACLE CHECKPOINTS

ORACLE CHECKPOINTS

จุดประสงค์ของ check point

            DB blocks จะถูกเก็บไว้ชั่วคราวใน DB buffer cache สำหรับ Blocks ที่ถูกอ่านจาก Data files จะถูกนำไปเก็บไว้ที่ DB buffer cache เพื่อให้ User อื่นๆสามารถใช้งานได้เลยโดยไม่ต้องอ่านจาก Disk

            เมื่อเราแก้ไข Row ใดๆก็ตามจะเป็นการแก้ไขที่ DB buffer cache ที่ตรงกับ Block ที่เก็บไว้ในตัวมันซึ่งเป็นการแก้ไขบน Memory  การเปลี่ยนแปลงนี้จะบันทึกไว้ใน Redo log buffer

                เมื่อ User ทำการ Commit , transaction ของ User จะถูกบันทึกลง Disk เพื่อจะได้เก็บข้อมูลไว้เป็น Permanent  การบันทึกนี้จะเก็บไว้ที่ไหน? ลงไปที่ Data file หรือไม่? ไม่ใช่!!! Transaction จะถูกบันทึกจาก Redo log buffer ลง Redo log file โดย LGWR

                ทำไม Oracle ถึงไม่บันทึกลง Data file เมื่อ User ทำการ Commit ไปเลย?  เหตุผลง่ายๆ… ถ้า Oracle เลือกที่จะบันทึกตรงๆลง Data file เลย   DBWR จะต้องหา Block ใน Data file ก่อนแล้วถึงบันทึกลงไป

User จะต้องรอจนกว่า DBWR จะทำงานเสร็จถึงจะทำ Command ต่อไปได้ จึงทำให้มีผลกระทบกับ Performance มาก

                Redo log จึงมีบทบาทสำคัญในตรงนี้ การบันทึกข้อมูลลงใน Redo log จะเป็นแบบ Sequential write

LGWR แค่นำข้อมูลจาก Redo buffer ลง Redo log file แบบ sequential และ synchronous เพื่อที่ User จะได้ไม่ต้องรอนาน  และยิ่งไปกว่านั้น DBWR จะเขียนเป็นแบบ block แต่ LGWR จะเขียนแค่ transaction ดังนั้นจะเพิ่ม performance โดยลดจำนวนการเขียน data แบบ synchronous

            เมื่อไรที่ต้องเขียน Data block จาก Buffer ลง Data file?   Data block ใน Data file จะถูก update โดย DBWR เขียนแบบ asynchronous ด้วยบาง trigger…   Trigger เหล่านี้เรียกว่า Checkpoint

            Checkpoint เป็นการทำแบบ Synchronization ที่ถูกกำหนดในบางครั้ง จะทำให้บาง dirty block หรือทุกๆ dirty block จะถูกเขียนลง disk เพื่อจะมั่นใจได้ว่า data block จะถูกเขียนลง data file เรียบร้อย

เมื่อไรก็ตามที่ dirty block ถูกเขียนลง data file จะทำให้ Oracle สามารถ :

-         To reuse a redo log  : redo log file จะสามารถเขียนทับได้เมื่อ dirty block ที่เกี่ยวข้องทุกอันถูกเขียนลง disk แล้ว ถ้าเราพยายามจะ reuse มันก่อนที่ DBWR จะเขียนเสร็จ จะมีการแจ้งเตือนขึ้นมาใน  Alert log ว่า

Checkpoint not complete

-         To reduce instance recovery time  : เมื่อ Memory ของ DB Instance เพิ่มขึ้น อาจทำให้ DB Buffer cache ใหญ่มาก จึงต้องการ checkpoint บ่อยขึ้นเพื่อ limit recovery time

-         To free buffers for reads  : เราไม่สามารถอ่าน data ใหม่จาก disk ไปไว้ที่ dirty block จนกว่ามันจะถูกเขียนลง disk ดังนั้น DBWR จะเขียน dirty block ลง disk เพื่อเพิ่ม free block

เมื่อเกิด checkpoint สิ่งที่เกิดขึ้นคือ

-         DBWR เขียน dirty block บางอันหรือทั้งหมดลง data file

-         CKPT process updates control file and data file headers

Checkpoint ชนิดต่างๆใน Oracle

FULL CHECKPOINT

- Writes block images to the database for all dirty buffers from all instances.

- Statistics updated

  . DBWR checkpoints

  . DBWR checkpoint buffers written

  . DBWR thread checkpoint buffers written

- Caused by :

  . Alter system checkpoint [global]

  . ALter database begin backup

  . ALter database close

  . Shutdown [immediate]

- Controlfile and datafile headers are updated

  . Checkpoint_change#

THREAD CHECKPOINT

- Writes block images to the database for all dirty buffers from one instance

- Statistics updated

  . DBWR checkpoints

  . DBWR checkpoint buffers written

  . DBWR thread checkpoint buffers written

- Caused by :

  . Alter system checkpoint local

- Controlfile and datafile headers are updated

  . Checkpoint_change#

TABLESPACE AND DATA FILE CHECKPOINT

เมื่อ tablespace เข้าสู่ backup mode หรือ offline (normal), DBWR จะเขียนทุก dirty block ที่เกี่ยวข้องกับ tablespace นั้นลง data file ก่อนที่จะเปลี่ยนสถานะของ tablespace นั้น

- Writes block images to the database for all dirty buffers for all files of a tablespace from all instances

- Statistics updated

  . DBWR checkpoints

  . DBWR tablespace checkpoint buffers written

  . DBWR checkpoint buffers written

- Caused by :

  . Alter tablespace xxx offline normal

  . Alter tablespace xxx begin backup

  . Alter tablespace xxx read only

  . Alter tablespace xxx shrink space

- Controlfile and datafile headers are updated

  . Checkpoint_change#

PARALLEL QUERY CHECKPOINT

Parallel query จะใช้ direct path reads บ่อยๆ (Full table scan or Index fast full scan)

นั่นหมายถึง data block จะถูกอ่านขึ้น session’s PGA ตรงๆ ไม่ผ่าน DB buffer cache

แต่ถ้าขณะนั้นมี dirty buffer ที่เกี่ยวข้องอยู่ใน DB buffer cache , session นั้นจะไม่มีทางรู้ข้อมูลเวอร์ชั่นล่าสุดเว้นแต่ dirty block นั้นจะถูกเขียนลง disk ก่อนเริ่ม query

ดังนั้น Parallel query จะเริ่มด้วยการทำ checkpoint ที่เกี่ยวข้องกับ object นั้นๆก่อน

- Writes block images to the database for all dirty buffers belonging to objects accessed by the query from all instances.

- Statistics updated

  . DBWR checkpoints

  . DBWR checkpoint buffers written

- Caused by :

  . Parallel Query

  . Parallel Query component of Parallel DML (PDML) or Parallel DDL (PDDL)

- Mandatory for consistency

- Controlfile and datafile headers are updated

  . Checkpoint_change#

OBJECT CHECKPOINT

  เมื่อ object ถูก drop/truncate , session นั้นจะเริ่มทำ object checkpoint โดยบอก DBWR ให้เขียน dirty buffer ของ object นั้นลง disk

- Statistics updated

  . DBWR checkpoints

  . DBWR object drop buffers written

- Caused by dropping or truncating a segment:

  . Drop table XXX

  . Drop table XXX Purge

  . Truncate table xxx

  . Drop index xxx

- Mandatory for media recovery purposes

- Controlfile and datafile headers are updated

  . Checkpoint_change#

LOG SWITCH CHECKPOINT

- Writes the contents of the dirty buffers whose information is protected by a redo log to the database.

- Statistics updated

  . DBWR checkpoints

  . DBWR checkpoint buffers written

  . background checkpoints started

  . background checkpoints completed

- Caused by log switch

- Controlfile and datafile headers are updated

  . Checkpoint_change#

INCREMENTAL CHECKPOINT

  เป็นชนิดของการ checkpoint อย่างหนึ่งเพื่อหลีกเลี่ยงการเขียน dirty block จำนวนมากเมื่อเกิด log file switch และลดเวลาของการทำ Instance recovery (fast_start_mttr_target เกี่ยวข้องโดยตรงกับ incremental checkpoint)

DBWR จะเช็คทุกๆ 3 วินาทีเพื่อหา block ที่จะเขียนและจะ sleep ไปเมื่อไม่มี block ที่ต้องเขียนเมื่อเสร็จแล้วจะทำให้ CKPT เขียนตำแหน่ง checkpoint ไปที่ control file แต่จะยังไม่เขียนที่ data file header

Note : Incremental checkpoint ได้ถูก implement ด้วยสองอัลกอริทึ่มนี้ (ซับซ้อนมาก)

- Ageing algorithm

- LRU/TCH algorithm


Ref : http://oracleinaction.com/checkpoints/