Friday, April 30, 2010

Materialized views: read-only, updatable, writeable

一直對oracle replication的機制不是相當了解,今天看了幾個章節,稍微有些心得,雖然還是不知道replication group存在的真正目的,不過到是對materialized view多了些認識。

Materialized view可以是read-only, updatable, writeable這三種模式。read-only相當好理解,不過updatable跟writeable兩個就... ?

Read-only
要做一個read-only的materialized view,就是不要使用"FOR UPDATE"這個子句(clause)即可。如其名,不可以對這類views執行任何DML語法。而且!!! 它也不需要屬於任何一個materialized view group。

Updatable
跟read-only相反,可以在這類views上執行DML語法,而這些變更也可以透過排程或其他方法更新回target master(可能是一個master table或master materialized view);不過有一個前提: 就是updatable materialized view必須放在一個materialized view group裡。

Writeable
writeable的materialized view跟updatable一樣,會用到"FOR UPDATE"子句。唯一差別是,他不會放在materialized view group內,換句話說,即使可以對writeable的materialized view執行DML,但是變更並不會更新回target master。(那幹嘛不用read-only就好=   = 所以這類materialized view也比較少用)

整理如下:

  Read-only Updatable Writeable
created with “FOR UPDATE” clause? N Y Y
perform DML operation? N Y Y
placed in a materialized view group? N Y N
changes be pushed back to master? N Y N
Tuesday, April 27, 2010

"could not create directory for unzipping" when installing chrome extension

※ 本篇只能"暫時"讓你安裝擴充功能而已,重新開啟chrome後該功能即會消失。另一解法請參考這理,works for me!! --2010/5/7

前陣子就發現在安裝google chrome extensions時會遇到這樣的錯誤(可是剛開始用的時候不會orz||),今天終於有一個extension讓我有動力想解決這個問題。

step1: 直接把extension下載下來,檔案的副檔名會是".crx"

2010-04-27_001

step2:  用解壓縮軟體直接把該檔案解壓縮
2010-04-27_002

step3: 回到chrome瀏覽器,在網址列輸入"chrome://extensions/"

step4: 點選右上角"開發人員模式" > "載入為封裝擴充功能"
2010-04-27_005 done~!

(補)不過後來發現,這個方法只能"暫時"使用extension而已,每次關掉瀏覽器再開啟,那個擴充功能就消失了,還是要再做一次上面的步驟才可以繼續使用 orz||

Ref: Fixing the Chrome Error: “Could not create directory for unzipping”

Q: Difference between oracle procedure, function and anonymous pl/sql block?

耶!! 前陣子的"回答oracle interview questions計畫"終於要開始惹!!
先簡單說明一下,基本上這些問題會用中文來回答,但是專有名詞的部分... 還是維持它原本的面貌... 因為我根本不知道他中文是要翻成什麼鬼=  =… 而且這些東西翻成中文感覺反而會失去原本的意思或被誤解。

[類別] PL/SQL
[問題] procedure, function還有anonymous pl/sql block間有什麼不同?

Answer
procedure跟function最大的差別在於function會有一個回傳值(a single value)。而anonymous pl/sql block如他字面上定義,是一段沒有名字的pl/sql,通常直接用在像SQL*PLUS這樣的工具裡,來叫用procedure, function或package。

喋喋不休版
procedure跟function兩者可以合稱為"subprogram",特色是具名、可以給予參數、可以有回傳值(only function);存在schema層級的subprogram又叫做standalone stored subprogram,而定義在package內的就叫package subprograms。

Anonymous blocks由三個部分組成: 宣告(declarative part)、執行(executable part)、例外處理(exception handlers),其中宣告與例外處理可有可無。特色是不具名(也就無法永久存於資料庫內),只做暫時之用(不像procedure跟function可以重複被叫用)。

比較表:

  Anonymous Blocks Subprograms
具名? N Y
每次使用時都進行編譯? N N
存於資料庫內? N Y
可被其他應用程式呼叫? N Y
可回傳bind variable值? Y Y
可回傳函數值? N Y
可接受參數? N Y

*bind variable就是"連結變數"... 就是我們sql語法裡為了效能考量寫成”column_value=:v”的這個:v

Friday, April 23, 2010

[Study] Oracle 9i Space Management Demystified (2)

(續) [Study] Oracle9i Space Management Demystified (1)
[原文] Original file here

9i提供給DBA的利器之二: Automatic Undo Management

這是原文的第一個part,旨在介紹undo tablespace/undo segment。在讀這篇文章以前,心裡一直有訊息就是: 9i以前存放undo data的叫做rollback segment,9i稱為undo segment。以為只是名稱上的不同,作用機制應該一樣。現在終於清楚了解是不同的!於是相當三八的畫了圖,就來看圖說故事吧XD

雖然名字不同、作用機制不同,不過目的是一樣的:

purpose

 

Rollback Segment Reviewed

rollbackSegment(點圖見原始大小) Rollback segment由一個transaction table(存放在header)與兩個以上的extents(由undo blocks)組成。每個extent可以被多個transaction存取,但同一時間只能由單一transaction寫入。

Extent是循環使用的。每個transaction會嘗試使用下一個"有空"的extent,如果每個extent都已經被佔用,server會再配置新的extent。

Automatic Undo Management

autoUnodManagement(點圖見原始大小)9i的這個新功能是透過undo tablespace來實現,tablespace裡的segment就叫undo segment(header同樣有一個transaction table),segment再往下的邏輯架構同rollback segment。

Undo tablespace啟用時,部份undo segments也同時online。每個transaction建立時,server會嘗試配給一個undo segment(transaction table)。當online的undo segments不夠用時,剩餘offline的undo segments 也會online來使用。若還是不夠,server會嘗試再配置新的undo segments,直到undo tablespace的空間不足了,才可能讓transaction共享同一個undo segment(最閒的那個)。

以上,就是rollback segment跟undo segment的差異。所以這樣的差異如何可以讓DBA的生命更美好呢XD?

  1. 只要create一個夠大的undo tablespace,undo segment的數量與大小oracle server都會接手,自動依需求動態調整。若是9i以前,rollback segments的數量與大小都需要仔細考慮,才能降低因transaction佔用而導致效率下降的問題。
  2. 跟auto undo management搭配的還有一個參數: UNDO_RETENTION。透過設定這個參數(秒數),可以決定undo data需要被保留至少多久的時間。如果有long run query,可以降低ORA-1555(shapshot too old)的錯誤。不過要特別注意的是,這個參數要undo tablespace的大小配合。否則你希望保留較久的undo data,可是允許的空間不足的話... 只能說: 巧婦難為無米之炊XD
  3. 承第一點,比起固定大小的rollback segment,因為undo segment大小動態調整,對於整個tablespace的空間利用也就較有效率。

所以如果是oracle 9i用戶,只要透過設定以下兩個初始化參數,就可以使用automatic undo management囉~

UNDO_MANAGEMENT=AUTO
COMPATIBLE=9.0.0

Sizing Undo Tablespace

所以,undo tablespace該給多大顯然是個重要的議題... 最簡單的方法是,如果我知道三件事情,那麼就可以決定"至少"要給多大的空間:

  1. 資料庫平均每秒需要用到多少個undo blocks?
  2. 每個undo block(data block)多大?
  3. 政策上要保留多久時間(秒)以前的undo data?

以上,2跟3都很好解決,就是初始化參數的DB_BLOCK_SIZE跟上面提到的UNDO_RETENTION。1呢... 我們可以從V$UNDOSTAT這個view裡得到答案。

V$UNDOSTAT這個表每十分鐘就會多一筆資料,統計每十分鐘產生了多少個undo blocks以及最久的query時間。數學上是這樣: "每十分鐘吃掉X個糖果,每秒吃幾個?" XD,不過當然是全部數據拿來平均比較準。最久的query時間也有點用處,可以讓DBA們參考決定undo_retention要設多久。

所以得到以上三個數字後,相乘,可以得到一個byte數,那就是最小需要的undo tablespace的大小囉~

呼~ 大致上就這樣,最基本的概念介紹完畢。原文裡還有其他資訊,請自閱。

Tuesday, April 13, 2010

[ORA-00845]: MEMORY_TARGET not supported on this system

environment:

Oracle Database 11g Release 11.2.0.1.0 – 64bit
Red Hat Linux Server

人哪.. 如果閒著沒事幹就會替自己找麻煩=   =,今天把準備拿來當production的oracle shutdown下來,再重開。馬上就被賞了個大禮。說是大禮,因為要是今天沒發現... 等到真的上線了才手忙腳亂,也沒時間整理文件囉~ =P

先來說說11g的新變革:
Automatic Memory Management(AMM)是11g的新功能,需要額外的shared memory(/dev/shm)還有一些file descriptors來實現,透過MMAN這支process來管理動態管理SGA與PGA的大小。

比較一下11g跟10g以前的記憶體管理設定參數:

  11g before 10g
memory size MEMORY_TARGET
SGA_TARGET
PGA_AGGREGATE_TARGET
limit MEMORY_MAX_TARGET SGA_MAX_TARGET

(當MEMORY_TARGET或MEMORY_MAX_TARGET其中一個有指定值時,SGA_MAX_TARGET會自動設成大的那個)

嗯... 簡單介紹到這,接著該來講正事: ORA-00845
在startup oracle時,若

  1. /dev/shm not mounted
  2. mounted with available size less then MEMORY_TARGET(系統內shared memory(/dev/shm)比設定的MEMORY_TARGET還要小)

就會丟出ORA-00845這個錯誤。同時去檢查alert log,也可以看見相關訊息,而且他也會建議適合的大小給你設定。

Starting ORACLE instance (normal)
WARNING: You are trying to use the MEMORY_TARGET feature. This feature requires the /dev/shm file system to be mounted for at least 2097152000 bytes. /dev/shm is either not mounted or is mounted with available space less than this size. Please fix this so that MEMORY_TARGET can work as expected. Current available is 2071711744 and used is 0 bytes. Ensure that the mount point is /dev/shm for this directory.
memory_target needs larger /dev/shm

要判斷自己是哪種情況可以先下"df -k"這個指令來查看/dev/shm是否有mount,若正常,應該可以看到如下:

[...]$ df –k
檔案系統          1K-區段      已用        可用       已用%    掛載點
tmpfs             3145728   1062256   2083472    34%      /dev/shm

 

若確定有掛載,那就是大小問題,可以調大mountpoint size:

# mount -t tmpfs shmfs -o size=7g /dev/shm

 

為了讓每次server重開機時,可以自動分配同樣的大小,需要修改/etc/fstab這個檔案,請讓他看起來長的像這樣:
tmpfs     /dev/shm       tmpfs   size=3g    0 0

這樣就一切大功告成!! 祝startup愉快~ =D

Ref:

  1. [Oracle Doc] Oracle Release Notes > Known issues
  2. [Oracle Doc] Preinstallation Requirements > Hardware Requirements > Memory Requirements > Automatic Memory Management(AMM)
  3. (need login) [Metalink] ORA-00845: MEMORY_TARGET not supported on this system - Linux Servers [ID 465048.1]
  4. [Ask Tom] ORA-00845: …
  5. [鳥哥] /etc/fstab
Monday, April 12, 2010

Oracle Role and Privileges

介紹一些跟角色(role)還有oracle系統權限(privileges)相關的view:

VIEW Description
DBA_ROLES All Roles which exist in the database
DBA_ROLE_PRIVS Roles granted to users and roles
ROLE_ROLE_PRIVS Roles which are granted to roles
ROLE_SYS_PRIVS System privileges granted to roles
ROLE_TAB_PRIVS Table privileges granted to roles


個人覺得最實用的是ROLE_SYS_PRIVS,在授予使用者角色時,用這個表可以看出ROLE包了哪些system privileges。

另外加贈兩個不錯的view: DBA_TAB_COMMENTS, DBA_COL_COMMENTS分別可以看表格或表格欄位的說明~

Friday, April 02, 2010

[Study] Oracle 9i Space Management Demystified (1)

[原文在此] Original file here

今天早上找到的好文章。版本老是老了點,不過有很多概念是一直延續的,個人認為這篇還有讀的價值。

開場白就說了database administrator花了他們大部分的時間在做space utilization, 而oracle 9i相當好心的提供了3個改革來改善DBA們的生命XD。
  • Automatic Undo Management
  • Locally Managed Tablespace
  • Auto Segment Space Management
因為我是在找tablespace fragmentation相關議題的時候看到這篇文章的,所以會先從Locally managed tablespace這塊讀起。

Locally Managed Tablespace
首先介紹名字的由來,Locally Managed Tablespace是針對extents管理的一個改革。傳統的tablespace management方法是利用data dictionary (tables) 來追蹤extents的使用狀況(所以稱為dictionary-managed tablespace),因為data dictionary屬於SYS, 是在不同的tablespace裡,所以整個資料庫內extents被分配或釋放時,都要集中在SYS tablespace裡記錄,還會有資源搶用(contention)的問題。
Dictionary Managed
Locally Managed
space managed bydata dictionary (SYS)bitmap (datafile header)
generate undo info.yesno
auto coalesce free spacenoyes

使用Locally managed tablespace還有分兩種決定extent size的方法: AUTO ALLOCATE跟UNIFORM EXTENT。
AUTO ALLOCATEUNIFORM EXTENT
size decisionby Oracle automaticallyDBA
decision factorcorresponding segment?: base on db utilization
initial extentsmaller (64K)? (default 1M)
when enough free space not availableauto allocates smaller extentsfail
which mode to use1. objects in tablespace vary drastivally in size
2. growth pattern is expected to be highly dynamic
only if all objects in the db are going to be of the same size and grow in a uniform manner

整體上看來,還是建議使用AUTO ALLOCATE模式即可。許多人可能認為使用UNIFORM EXTENT可以保證被釋放的extnets一定可以再被重新利用,因此也比較能減少fragment的現象。但其實不然,就像上面表格裡建議的,若是tablespace裡的物件經常性的建立還有刪除(像是暫時建了Table當作資料處理的中繼站),那麼使用uniform就相當浪費空間,因為不管表格大或小,他就是會佔去一個固定大小的extent。反過來看auto allocate模式下的extents,雖然大小各不相同,但是他們基本上還是follow一個基本的模式在增長,通常是initial extent的倍數,所以再被重新利用並不難。

造成fragmentation的現象的主因並非extents size不同,而是因為tablespace裡的objects follow不同的extent sizing policy,而導致被釋放的extent很難再被重新利用。所以要用auto還是uniform mode? 基本上還是視資料庫的使用情形決定。

整體上看來,locally managed tablespace有兩大優點:
  1. 效能較好: 因為少了data dictionary的搶用;還有他對space的管理方式,也是提升效能的關鍵之一(long running queries, add and drop objects)。
  2. 較少fragmentation: 如上述。
OK!!! 這就是locally managed tablespace的部分,是這三個主題裡篇幅最少的一個惹~ XD
Thursday, April 01, 2010

Interview Questions with Answers for Oracle, DBA, and developer candidates

Interview Questions with Answers for Oracle, DBA, and developer candidates
今天看資料的時候忽然找到這個網站,感覺起來滿有趣的,他把問題分為8大類:
  1. PL/SQL
  2. DBA
  3. SQL/SQL PLUS
  4. Tuning
  5. Installation/Configuration
  6. Data Modeler
  7. UNIX
  8. Oracle Troubleshooting
花了一些時間把他們整理起來。然後我決定... 要回答全部的問題!!! (好大的願望XD),目前預計能將進度控制在每個禮拜回答一題XDD(沒辦法,我還有半本Oracle DBA Fundamentals還沒讀完Q_Q)。至於開始時間呢... 就看什麼時候開始回答第一題吧~ =P (最近好懶散..)
敬請期待!!!

Tags