Method1 : but no reliability
select ora_rowscn from table
select scn_to_timestamp(ora_rowscn) from table
Method2 : Audit to Monitor
One option is as follows:
(1) Turn the auditing on: AUDIT_TRAIL = true in init.ora
(2) Restart the instance if its running.
(3) Audit the table:
AUDIT INSERT,SELECT,DELETE,UPDATE on TableName
by ACCESS WHENEVER SUCCESSFUL
(4) Get the desired information using :
SELECT OBJ_NAME,ACTION_NAME ,to_char(timestamp,'dd/mm/yyyy , HH:MM:SS')
from sys.dba_audit_object.
2008年3月28日 星期五
2008年3月26日 星期三
SQL*PLUS Command Regular Expression
SQL> select name,issys_modifiable from v$system_parameter where issys_modifiable
<>false;
c /false/'FALSE'/
run
<>false;
c /false/'FALSE'/
run
2008年3月25日 星期二
Insert Into Statement
INSERT INTO "table_name" ("column1", "column2", ...)
VALUES ("value1", "value2", ...)
INSERT INTO "table1" ("column1", "column2", ...)
SELECT "column3", "column4", ...
FROM "table2"
Note that this is the simplest form. The entire statement can easily contain WHERE, GROUP BY, and HAVING clauses, as well as table joins and aliases.
VALUES ("value1", "value2", ...)
INSERT INTO "table1" ("column1", "column2", ...)
SELECT "column3", "column4", ...
FROM "table2"
Note that this is the simplest form. The entire statement can easily contain WHERE, GROUP BY, and HAVING clauses, as well as table joins and aliases.
ALTER TABLE
1.ALTER TABLE NAME
ALTER TABLE [PROJECT.]OLD_TABLE_NAME RENAME TO NEW_TABLE_NAME;
2.ALTER TABLE COLUMN NAME
ALTER TABLE [PROJECT.]TABLE_NAME RENAME COLUMN OLD_COLUMN_NAME TO NEW_COLUMN_NAME;
3.ALTER TABLE COLUMN DATA TYPE
ALTER TABLE [PROJECT.]TABLE_NAME MODIFY COLUMN_NAME NEW_DATATYPE;
4.ADD COLUMN
ALTER TABLE [PROJECT.]TABLE_NAME ADD COLUMN_NAME DATATYPE;
5.DROP COLUMN
ALTER TABLE [PROJECT.]TABLE_NAME DROP COLUMN COLUMN_NAME;
ALTER TABLE [PROJECT.]OLD_TABLE_NAME RENAME TO NEW_TABLE_NAME;
2.ALTER TABLE COLUMN NAME
ALTER TABLE [PROJECT.]TABLE_NAME RENAME COLUMN OLD_COLUMN_NAME TO NEW_COLUMN_NAME;
3.ALTER TABLE COLUMN DATA TYPE
ALTER TABLE [PROJECT.]TABLE_NAME MODIFY COLUMN_NAME NEW_DATATYPE;
4.ADD COLUMN
ALTER TABLE [PROJECT.]TABLE_NAME ADD COLUMN_NAME DATATYPE;
5.DROP COLUMN
ALTER TABLE [PROJECT.]TABLE_NAME DROP COLUMN COLUMN_NAME;
2008年3月23日 星期日
Oracle Install Attention
Built DB時,
密碼可不能設 XXX@XXX , 夾了 "@" 是建不起來的.
可能是 把 @後的 XXX 當成 SID ~ 有點鳥 試了一晚才發現.
密碼可不能設 XXX@XXX , 夾了 "@" 是建不起來的.
可能是 把 @後的 XXX 當成 SID ~ 有點鳥 試了一晚才發現.
2008年3月18日 星期二
Mysql Character Set 問題解決
轉載自
http://bluecat.csie.net/2007/12/17/2498/
老問題,不過一直懶得弄,都用懶人法先撐著。
懶人設定法,在 connect 後呼叫
SET NAMES ‘latin1′
如果要根本上治好,或是說連資料庫內的資料都正確的轉成 utf8 ,那就得作點苦工了。首先 MySQL 的 Character Set 變數有三
character_set_client client 傳給 server 使用的 charset ,即輸入
character_set_results server 傳給 client 使用的 charset ,即輸出
character_set_connection db 實際上存放時的 charset ,通常用 utf8
正常自動設定的話,character_set_connection 會是建立 db 時選擇的 charset,如果 table 或 field 有特別指定不同的 charset ,那麼就以指定的為準,不過這部份是 MySQL 自動轉換,所以不需要管,重點在於輸入與輸出的 charset 必須正確,才能正確的轉換。可以當成語言翻譯,首先必須指出自己使用的語言,伺服器就能正確的翻譯並紀錄成指定的語言,然後指出需要的語言,如此伺服器就能從紀錄翻譯出需要的語言。
懶人設定法就是不管是啥,一概都不轉碼,因為 SET NAMES ‘x’ 等同於
SET character_set_client = ‘x’
SET character_set_results =’x’
SET character_set_connection = ‘x’
也就是告訴資料庫設定傳進去的是 latin1 編碼,並且存成 latin1 編碼,跟存 raw byte data 很像,因此雖然 Database Charset 設成 UTF-8 ,但實際卻還是用 latin1 在處理資料;用 phpMyAdmin 的時,因為網頁編碼是 UTF-8,character_set_client & character_set_results 就會被設成 UTF-8,這時候,懶人設定法的資料就全部都會變亂碼, 因為 UTF-8 的編碼被當作 latin1 ,而這時又要求輸出 UTF-8,於是把原本就是 UTF-8 的資料又做了一次 latin1 -> UTF-8 轉換,會變亂碼也不奇怪了。如果是用 phpMyAdmin 插入資料,雖然 character_set_client 是 UTF-8 做了一次 UTF-8 -> latin1 轉換,但輸出時,因 character_set_results 也是 UTF-8,所以做了 latin1 -> UTF-8 的反轉換,因此得到原本的正常字串。
根本的 UTF-8 修正方式就是先用 latin1 編碼倒出資料,然後依據原始編碼轉碼成 UTF-8 後再倒回去,比較省事的方法是用 mysqldump 抓下來,然後用 vim 轉碼後在倒回去。
之前有個網頁是 Big5 ,就用 php 一筆筆拉出來,然後 mb_convert_encoding 成 UTF-8 ,再存回去,當然 Database 本身的 charset 已經設成 UTF-8 ,需要注意的是 field 的校對也要先設成 utf8_general_ci ,因為要順便作點處理,所以才用 php 做,不然用 mysqldump 應該比較快。
實例
資料庫是 UTF-8 編碼,可是資料都是 Big5 ,並用懶人設定寫入資料庫,現在要把資料庫內的資料從偽 UTF-8 轉成正確的資料以在 phpMyAdmin 中也正常顯示
connet 後,呼叫
mysql_query("SET NAMES utf8"); // 設定輸出為 utf8
mysql_query( "SET character_set_results = ‘latin1′"); // 但吐資料請給我 latin1 (即 Big5 的資料)
接著一筆筆拉出來,用 mb_convert_encoding 從 Big5 轉成 UTF-8 再存回去。
或是
connet 後,呼叫
mysql_query( "SET character_set_client = ‘big5′"); // 設定輸出為 big5
mysql_query( "SET character_set_results = ‘latin1′"); // 但吐資料請給我 latin1 (即 Big5 的資料)
mysql_query( "SET character_set_connection = ‘utf8′"); // 資料庫是 utf8
接著一筆筆拉出來,再直接存回去就好
http://bluecat.csie.net/2007/12/17/2498/
老問題,不過一直懶得弄,都用懶人法先撐著。
懶人設定法,在 connect 後呼叫
SET NAMES ‘latin1′
如果要根本上治好,或是說連資料庫內的資料都正確的轉成 utf8 ,那就得作點苦工了。首先 MySQL 的 Character Set 變數有三
character_set_client client 傳給 server 使用的 charset ,即輸入
character_set_results server 傳給 client 使用的 charset ,即輸出
character_set_connection db 實際上存放時的 charset ,通常用 utf8
正常自動設定的話,character_set_connection 會是建立 db 時選擇的 charset,如果 table 或 field 有特別指定不同的 charset ,那麼就以指定的為準,不過這部份是 MySQL 自動轉換,所以不需要管,重點在於輸入與輸出的 charset 必須正確,才能正確的轉換。可以當成語言翻譯,首先必須指出自己使用的語言,伺服器就能正確的翻譯並紀錄成指定的語言,然後指出需要的語言,如此伺服器就能從紀錄翻譯出需要的語言。
懶人設定法就是不管是啥,一概都不轉碼,因為 SET NAMES ‘x’ 等同於
SET character_set_client = ‘x’
SET character_set_results =’x’
SET character_set_connection = ‘x’
也就是告訴資料庫設定傳進去的是 latin1 編碼,並且存成 latin1 編碼,跟存 raw byte data 很像,因此雖然 Database Charset 設成 UTF-8 ,但實際卻還是用 latin1 在處理資料;用 phpMyAdmin 的時,因為網頁編碼是 UTF-8,character_set_client & character_set_results 就會被設成 UTF-8,這時候,懶人設定法的資料就全部都會變亂碼, 因為 UTF-8 的編碼被當作 latin1 ,而這時又要求輸出 UTF-8,於是把原本就是 UTF-8 的資料又做了一次 latin1 -> UTF-8 轉換,會變亂碼也不奇怪了。如果是用 phpMyAdmin 插入資料,雖然 character_set_client 是 UTF-8 做了一次 UTF-8 -> latin1 轉換,但輸出時,因 character_set_results 也是 UTF-8,所以做了 latin1 -> UTF-8 的反轉換,因此得到原本的正常字串。
根本的 UTF-8 修正方式就是先用 latin1 編碼倒出資料,然後依據原始編碼轉碼成 UTF-8 後再倒回去,比較省事的方法是用 mysqldump 抓下來,然後用 vim 轉碼後在倒回去。
之前有個網頁是 Big5 ,就用 php 一筆筆拉出來,然後 mb_convert_encoding 成 UTF-8 ,再存回去,當然 Database 本身的 charset 已經設成 UTF-8 ,需要注意的是 field 的校對也要先設成 utf8_general_ci ,因為要順便作點處理,所以才用 php 做,不然用 mysqldump 應該比較快。
實例
資料庫是 UTF-8 編碼,可是資料都是 Big5 ,並用懶人設定寫入資料庫,現在要把資料庫內的資料從偽 UTF-8 轉成正確的資料以在 phpMyAdmin 中也正常顯示
connet 後,呼叫
mysql_query("SET NAMES utf8"); // 設定輸出為 utf8
mysql_query( "SET character_set_results = ‘latin1′"); // 但吐資料請給我 latin1 (即 Big5 的資料)
接著一筆筆拉出來,用 mb_convert_encoding 從 Big5 轉成 UTF-8 再存回去。
或是
connet 後,呼叫
mysql_query( "SET character_set_client = ‘big5′"); // 設定輸出為 big5
mysql_query( "SET character_set_results = ‘latin1′"); // 但吐資料請給我 latin1 (即 Big5 的資料)
mysql_query( "SET character_set_connection = ‘utf8′"); // 資料庫是 utf8
接著一筆筆拉出來,再直接存回去就好
2008年3月9日 星期日
Creating a Function-Based Index
You must set the initialization parameter QUERY_REWRITE_ENABLED to true in order to take advantage of function-based indexes.
show parameter QUERY_REWRITE_ENABLED;
if false then
SQL> ALTER SYSTEM SET QUERY_REWRITE_ENABLED=TRUE;
statement :
Drop Index
DROP INDEX INDEX_NAME;
You must set the initialization parameter QUERY_REWRITE_ENABLED to true in order to take advantage of function-based indexes.
show parameter QUERY_REWRITE_ENABLED;
if false then
SQL> ALTER SYSTEM SET QUERY_REWRITE_ENABLED=TRUE;
statement :
CREATE INDEX INDEX_Name
ON table(func(table.column));
ex.
CREATE INDEX QUEUE_TABLE_ID01
ON QUEUE_TABLE(MOD(NO,2));
Drop Index
DROP INDEX INDEX_NAME;
2008年3月4日 星期二
Perl DBI Calling Oracle Procedure
How does one invoke stored procedures with DBI?
There is currently no standard way to call stored procedures with DBI. However, if you have created a stored procedure within an Oracle database, you can use $dbh->do() to immediately execute the procedure:
$dbh->do("BEGIN myPackage.myProcedure; END;");
Or
Sample:
my $sth=$dbh_o->prepare("begin PRO_BID_QUEUE_TABLE(:in1,:int2,:T); end;");
$sth->bind_param("in1",20);
$sth->bind_param("in2",30);
my $result;
$sth->bind_param_inout("T",\$result,20);
$sth->execute();
$sth->commit();
CREATE OR REPLACE PROCEDURE
PRO_BID_QUEUE_TABLE( N1 IN NUMBER , N2 IN NUMBER , TOTAL OUT NUMBER)
IS
BEGIN
TOTAL := N1 + N2 ;
END;
There is currently no standard way to call stored procedures with DBI. However, if you have created a stored procedure within an Oracle database, you can use $dbh->do() to immediately execute the procedure:
$dbh->do("BEGIN myPackage.myProcedure; END;");
Or
Sample:
my $sth=$dbh_o->prepare("begin PRO_BID_QUEUE_TABLE(:in1,:int2,:T); end;");
$sth->bind_param("in1",20);
$sth->bind_param("in2",30);
my $result;
$sth->bind_param_inout("T",\$result,20);
$sth->execute();
$sth->commit();
CREATE OR REPLACE PROCEDURE
PRO_BID_QUEUE_TABLE( N1 IN NUMBER , N2 IN NUMBER , TOTAL OUT NUMBER)
IS
BEGIN
TOTAL := N1 + N2 ;
END;
2008年3月2日 星期日
Oracle -TableSpace( Create Table, Manage )
(轉載至網路)
TableSpace介紹
簡介
TableSpace 是Oracle空間管理上的邏輯單位,實體上存放資料的是Tablespace裡面的檔案(Data File);而我們所熟悉的Table就放在這 一個一個的檔案裡面。所以TableSpace可以看成是Data File的群組。通常在管理上會把使用者的資料與Oracle系統的物件以不同的Tablespace做切分 。如果一個Oracle上有多個不同的AP系統,以不同的TableSpace做切割,則可以達到管理與備份的目的。但是TableSpace的功用也不僅僅只是簡單的群組分類而已,Oracle 提供了許多功能上的參數來設定TableSpace來達到空間管理與效能增進的目的。
有必要提的是,TableSpace沒辦法跨資料庫,TableSpace中的Data File沒辦法跨TableSpace,Data File中的Table (Segement)可以跨 Data File,但不能跨TableSpace。簡單的來說,一個Table裡面的資料是有可能因為Oracle的空間分配而分布在同一個TableSpace的 不同的Data File中的;因此一個Data File創出來後,是不能隨便刪除的,這將會造成嚴重的資料損毀的問題。
SYSTEM與Non-SYSTEM TableSpace
當資料庫剛建立起來,系統會建立一個叫做SYSTEM的系統TableSpace,存放SYS、SYSTEM等User重要的系統資料(ex:資料字典與預儲程序等) 如果我們建立Oracle User時,不指定預設的TableSpace,則此User則會以SYSTEM TableSpace作為預設的TableSpace。 這將造成管理上的混亂與嚴重的效能問題,這是必須特別注意的。
TableSpace的類型:Permanent、Undo、Temporary
Permanent Tablespace
一般我們創建給AP使用的都是Permanent Tablespace。裡面物件的生命週期不會隨著交易或者 使用者的session結束而消失。
Undo Tablespace
Undo Tablespace是系統用的特殊的Tablespace,用來取代過去的rollback segement的機制, 主要的功用是提供使用者修改資料未commit之前的read consistency的功能以及rollback交易的功能。 也因為undo tablespace主要是取代過去的rollback segement的機制,所以不能存放其他種類的segement。 undo tablespace只能是local managed。
Temporary Tablespace
Temporary Tablespace也是系統用的特殊的Tablespace。當使用者需要做排序時, 有時就會使用Temporary Tablespace,因此裡面的Segement的生命週期都很短,可能交易結束或者 User的Session結束就會消失。每個系統都必須要有一個預設的Temporary Tablespace(Default Temporary Tablespace), 如果沒有的話,忘了指定使用哪個Temporary Tablespace的使用者會以SYSTEM tablespace來當作Temporary Tablespace,這樣就很糟糕。 以下列出幾個Temporary Tablespace的特性。
Temporary Tablespace是NOLOGGING模式,因此若資料庫損毀,做Recovery不需要恢復Temporary Tablespace。
Temporary最好是使用Local managed Tablespace
若使用local managed模式,UNIFORM SIZE參數最好是Sort_Area_Size的參數,這樣效能比較好。
Uniform size預設1024K,而Sort_area_size預設是512K
Temporary Tablespace不能使用local managed的AUTOALLOCATE參數。
TableSpace的Extent空間管理:Local Managed 與Dictionary Managed
Local Managed 與Dictionary Managed最主要的分別,在於空間管理方式的不同。Local managed 的管理方式是讓 每個TableSpace自己利用bitmaps去管理他自己的空間,而Dictionary Managed則是利用SYSTEM TableSpace的資料字典來做空間管理。 這兩者最大的不同在於Local managed大大的改善了Oracle做空間管理(例如:產生新的Exten或釋放Extent...等)時,搶奪 SYSTEM TableSpace資源的問題。所以Oracle從8i以後已經朝Local managed的方向去走了,所以我們應該盡量使用Local managed的方式才對,所以Dictionary managed的方式不多做介紹了。
Local managed tablespace
Local managed使用bitmaps做空間管理。
bitmaps中每個bit代表一個data block或者一堆相鄰的data block(extent)
從10g開始,SYSTEM Tablespace預設使用local managed -->Oracle建議使用local managed的證據。
假如SYSTEM TableSpace是local managed,那麼其他TableSpace必須是local managed。
若沒指定使用local managed或者dictionary managed,則預設使用local managed。
使用local managed可以增進效能,因為減少了SYSTEM TableSpace的效能競爭。
使用local managed則不需要做空間縫合(loalescing),因為相鄰的不同大小的extent,辨識extent使用狀態的bits也在一起 ,Oracle可以直接使用這些相鄰的extent。不需要先進行縫合才可以使用。這也可以增進部份效能。
local managed的extent空間管理(Extent Management):AUTOALLOCATE與UNIFORM
AUTOALLOCATE與UNIFORM這兩個參數,是用來設定Local managed的extent大小的參數。 AUTOALLOCATE是讓Oracle自己來決定extent的大小;而UNIFORM則是強制規定TableSpace中extent的為固定的大小。 通常若你明確的知道extent必須多大,才會使用UNIFORM,使用UNIFORM的好處是每個extent的大小都相同,不會產生空間破碎的問題。 但是如果無法預知extent必須多大,使用AUTOALLOCATE會比較好,讓Oracle自己決定使用extent的大小,可以比較符合實際的需求 ,因此會比較節省空間,但是這可能會產生部分空間破碎的問題。使用AUTOEXTENT,Oracle會使用的extent大小為64k、1M、8M、64M。 根據我系統上使用的結果,99.95%的extent都是使用64k、只有少部分使用1M 的extent,所以其實破碎的情況不嚴重,使用AUTOALLOCATE 在我的系統上其實就夠用了。想知道你的TableSpace所使用的Extent有幾種,請用下列的語法:
Select bytes,count(*) from dba_extents where tablespace_name='your_tablespace_name' group by bytes
Local managed中的Segment的空間管理(Segment Space Management ):AUTO與MANUAL
Tablespace中的Segment的空間管理上,可以設置的參數為AUTO與MANUAL。MANUAL是使用 我們熟悉的PCTUSED、FREELISTS、FREELIST GROUPS的方式來管理Segment中的data block;而AUTO則是 使用bitmaps來管理data block。使用AUTO來管理的話,以往create tablespace或create table時設定的 storage的參數設定都不需要再設定了,因為data block的管理已經是bitmaps了,不再是free list了。如果沒有特別的需求話 ,使用AUTO會比使用MANUAL有更好的空間利用率,與效能上的提升。
Local managed中的Create TableSpace範例
Create Tablespace MYDATA
Datafile '/u1/oradata/mydb/mydata1.dbf' size 100M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED ,
'/u1/oradata/mydb/mydata2.dbf' size 100M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED
Extent Management Local
Segment Space Management Auto;
dictionary managed中的Create TableSpace範例
Create Tablespace MYDATA
Datafile '/u1/oradata/mydb/mydata1.dbf' size 100M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED
Extent Management Dictionary
Default Storage (
Initial 64k
next 64k
minextents 2
maxextents unlimited
pctincrease 0 );
TableSpace介紹
簡介
TableSpace 是Oracle空間管理上的邏輯單位,實體上存放資料的是Tablespace裡面的檔案(Data File);而我們所熟悉的Table就放在這 一個一個的檔案裡面。所以TableSpace可以看成是Data File的群組。通常在管理上會把使用者的資料與Oracle系統的物件以不同的Tablespace做切分 。如果一個Oracle上有多個不同的AP系統,以不同的TableSpace做切割,則可以達到管理與備份的目的。但是TableSpace的功用也不僅僅只是簡單的群組分類而已,Oracle 提供了許多功能上的參數來設定TableSpace來達到空間管理與效能增進的目的。
有必要提的是,TableSpace沒辦法跨資料庫,TableSpace中的Data File沒辦法跨TableSpace,Data File中的Table (Segement)可以跨 Data File,但不能跨TableSpace。簡單的來說,一個Table裡面的資料是有可能因為Oracle的空間分配而分布在同一個TableSpace的 不同的Data File中的;因此一個Data File創出來後,是不能隨便刪除的,這將會造成嚴重的資料損毀的問題。
SYSTEM與Non-SYSTEM TableSpace
當資料庫剛建立起來,系統會建立一個叫做SYSTEM的系統TableSpace,存放SYS、SYSTEM等User重要的系統資料(ex:資料字典與預儲程序等) 如果我們建立Oracle User時,不指定預設的TableSpace,則此User則會以SYSTEM TableSpace作為預設的TableSpace。 這將造成管理上的混亂與嚴重的效能問題,這是必須特別注意的。
TableSpace的類型:Permanent、Undo、Temporary
Permanent Tablespace
一般我們創建給AP使用的都是Permanent Tablespace。裡面物件的生命週期不會隨著交易或者 使用者的session結束而消失。
Undo Tablespace
Undo Tablespace是系統用的特殊的Tablespace,用來取代過去的rollback segement的機制, 主要的功用是提供使用者修改資料未commit之前的read consistency的功能以及rollback交易的功能。 也因為undo tablespace主要是取代過去的rollback segement的機制,所以不能存放其他種類的segement。 undo tablespace只能是local managed。
Temporary Tablespace
Temporary Tablespace也是系統用的特殊的Tablespace。當使用者需要做排序時, 有時就會使用Temporary Tablespace,因此裡面的Segement的生命週期都很短,可能交易結束或者 User的Session結束就會消失。每個系統都必須要有一個預設的Temporary Tablespace(Default Temporary Tablespace), 如果沒有的話,忘了指定使用哪個Temporary Tablespace的使用者會以SYSTEM tablespace來當作Temporary Tablespace,這樣就很糟糕。 以下列出幾個Temporary Tablespace的特性。
Temporary Tablespace是NOLOGGING模式,因此若資料庫損毀,做Recovery不需要恢復Temporary Tablespace。
Temporary最好是使用Local managed Tablespace
若使用local managed模式,UNIFORM SIZE參數最好是Sort_Area_Size的參數,這樣效能比較好。
Uniform size預設1024K,而Sort_area_size預設是512K
Temporary Tablespace不能使用local managed的AUTOALLOCATE參數。
TableSpace的Extent空間管理:Local Managed 與Dictionary Managed
Local Managed 與Dictionary Managed最主要的分別,在於空間管理方式的不同。Local managed 的管理方式是讓 每個TableSpace自己利用bitmaps去管理他自己的空間,而Dictionary Managed則是利用SYSTEM TableSpace的資料字典來做空間管理。 這兩者最大的不同在於Local managed大大的改善了Oracle做空間管理(例如:產生新的Exten或釋放Extent...等)時,搶奪 SYSTEM TableSpace資源的問題。所以Oracle從8i以後已經朝Local managed的方向去走了,所以我們應該盡量使用Local managed的方式才對,所以Dictionary managed的方式不多做介紹了。
Local managed tablespace
Local managed使用bitmaps做空間管理。
bitmaps中每個bit代表一個data block或者一堆相鄰的data block(extent)
從10g開始,SYSTEM Tablespace預設使用local managed -->Oracle建議使用local managed的證據。
假如SYSTEM TableSpace是local managed,那麼其他TableSpace必須是local managed。
若沒指定使用local managed或者dictionary managed,則預設使用local managed。
使用local managed可以增進效能,因為減少了SYSTEM TableSpace的效能競爭。
使用local managed則不需要做空間縫合(loalescing),因為相鄰的不同大小的extent,辨識extent使用狀態的bits也在一起 ,Oracle可以直接使用這些相鄰的extent。不需要先進行縫合才可以使用。這也可以增進部份效能。
local managed的extent空間管理(Extent Management):AUTOALLOCATE與UNIFORM
AUTOALLOCATE與UNIFORM這兩個參數,是用來設定Local managed的extent大小的參數。 AUTOALLOCATE是讓Oracle自己來決定extent的大小;而UNIFORM則是強制規定TableSpace中extent的為固定的大小。 通常若你明確的知道extent必須多大,才會使用UNIFORM,使用UNIFORM的好處是每個extent的大小都相同,不會產生空間破碎的問題。 但是如果無法預知extent必須多大,使用AUTOALLOCATE會比較好,讓Oracle自己決定使用extent的大小,可以比較符合實際的需求 ,因此會比較節省空間,但是這可能會產生部分空間破碎的問題。使用AUTOEXTENT,Oracle會使用的extent大小為64k、1M、8M、64M。 根據我系統上使用的結果,99.95%的extent都是使用64k、只有少部分使用1M 的extent,所以其實破碎的情況不嚴重,使用AUTOALLOCATE 在我的系統上其實就夠用了。想知道你的TableSpace所使用的Extent有幾種,請用下列的語法:
Select bytes,count(*) from dba_extents where tablespace_name='your_tablespace_name' group by bytes
Local managed中的Segment的空間管理(Segment Space Management ):AUTO與MANUAL
Tablespace中的Segment的空間管理上,可以設置的參數為AUTO與MANUAL。MANUAL是使用 我們熟悉的PCTUSED、FREELISTS、FREELIST GROUPS的方式來管理Segment中的data block;而AUTO則是 使用bitmaps來管理data block。使用AUTO來管理的話,以往create tablespace或create table時設定的 storage的參數設定都不需要再設定了,因為data block的管理已經是bitmaps了,不再是free list了。如果沒有特別的需求話 ,使用AUTO會比使用MANUAL有更好的空間利用率,與效能上的提升。
Local managed中的Create TableSpace範例
Create Tablespace MYDATA
Datafile '/u1/oradata/mydb/mydata1.dbf' size 100M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED ,
'/u1/oradata/mydb/mydata2.dbf' size 100M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED
Extent Management Local
Segment Space Management Auto;
dictionary managed中的Create TableSpace範例
Create Tablespace MYDATA
Datafile '/u1/oradata/mydb/mydata1.dbf' size 100M AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED
Extent Management Dictionary
Default Storage (
Initial 64k
next 64k
minextents 2
maxextents unlimited
pctincrease 0 );
訂閱:
文章 (Atom)