SecureFiles در پایگاه داده اوراکل نسخه ۱۱gr1
SecureFiles در پایگاه داده اوراکل نسخه ۱۱gr1
در پایگاه داده اوراکل نسخه ۱۱g عملکرد SecureFiles در پیاده سازی Object های بزرگ دچار تغییر شده است. ذخیره ساز اصلی LOB که اکنون به نام BASICFILE شناخته می شود همچنان به عنوان روش ذخیره ساز پیش فرض وجود دارد ولی کلمه کلیدی SECUREFILE شیوه جدید ذخیره سازی را فعال می نماید که امکان Encryption برای امنیت بیشتر و حفظ بیشتر فضا به وسیله فشرده سازی و Deduplication را دارا می باشد.
تنظیم پارامترهای اولیه
کارایی SecureFile هنگامی که پارامتر COMPATIBLE به ۱۱٫۰٫۰٫۰٫۰ یا بالاتر تنظیم شود فعال خواهد شد. پارامتر DB_SECUREFILE رفتار پیش فرض پایگاه داده با ذخیره سازی LOB را کنترل می نماید و مقادیر قابل پذیرش آن به شرح ذیل است:
ALWAYS – تمامی LOB ها در ASSM Tablespace ها به شیوه SecureFiles ایجاد می شوند و LOB های non-ASSM Tablespace مادامی که صریحاْ به طور SecureFiles مشخص نشده باشند به شیوه BasicFile ایجاد خواهند شد. گزینه های BasicFile نادیده گرفته می شود و گزینه های پیش فرض ذخیره ساز SecureFiles در نظر گرفته خواهد شد.
FORCE – تمامی LOB ها به شیوه SecureFile LOB ایجاد می شوند، در صورتی که LOB در یک non-ASSM Tablespace باشد دچار خطا خواهد شد. گزینه های ذخیره ساز BasicFile نادیده گرفته می شود و گزینه های پیش فرض ذخیره ساز SecureFiles در نظر گرفته می شود.
PERMITTED – تنظیم پیش فرض می باشد. در صورت فعال بودن کلمه کلیدی SECUREFILE ذخیره ساز SecureFile LOB فعال خواهد بود. روش ذخیره پیش فرض BASICFILE است.
NEVER – ایجاد SecureFile LOB مجاز نمی باشد.
IGNORE – جلوگیری از ایجاد SecureFile LOB و نادیده گرفتن تمام خطاهای مرتبط با گزینه های ذخیره ساز SecureFile
پارامتر پویا است و توسط دستور ALTER SYSTEM تنظیم می شود.
SQL> ALTER SYSTEM SET db_securefile = ‘FORCE’;
System altered.
SQL> ALTER SYSTEM SET db_securefile = ‘PERMITTED’;
System altered.
SQL>
در مثال فوق پارامتر ابتدایی DB_SECUREFILE برابر مقدار پیش فرض PERMITTED تنظیم شده است.
ایجاد SecureFile LOB ها
مبانی اولیه
در ساده ترین حالت SecureFile LOB ها به وسیله اضافه نمودن کلمه کلیدی SECUREFILE در عبارت ذخیره ساز LOB ایجاد می شود. کد زیر ایجاد دو جدول را نشان می دهد، در اولی از روش اصلی ایجاد ذخیره ساز استفاده شده و در دومی از شیوه SecureFile استفاده شده است.
CREATE TABLE bf_tab (
id NUMBER,
clob_data CLOB
)
LOB(clob_data) STORE AS BASICFILE;
INSERT INTO bf_tab VALUES (1, ‘My CLOB data’);
COMMIT;
CREATE TABLE sf_tab (
id NUMBER,
clob_data CLOB
)
LOB(clob_data) STORE AS SECUREFILE;
INSERT INTO sf_tab VALUES (1, ‘My CLOB data’);
COMMIT;
حذف رکوردهای تکراری LOB
گزینه DEDUPLICATE در SecureFiles امکان حذف رکوردهای تکراری در سطح جدول یا پارتیشن را ایجاد می نماید. همانطور که انتظار دارید فرآیند پردازش حذف این رکوردها باعث سربار خواهد شد. گزینه KEEP_DUPLICATES صریحاْ از ایجاد رکوردهای تکراری جلوگیری می کند. در مثال زیر مقایسه ای بین فضای استفاده شده از یک SecureFile معمولی و SecureFile با حذف رکوردهای تکراری است.
CREATE TABLE keep_duplicates_tab (
id NUMBER,
clob_data CLOB
)
LOB(clob_data) STORE AS SECUREFILE keepdup_lob(
KEEP_DUPLICATES
);
CREATE TABLE deduplicate_tab (
id NUMBER,
clob_data CLOB
)
LOB(clob_data) STORE AS SECUREFILE dedup_lob (
DEDUPLICATE
);
DECLARE
l_clob CLOB := RPAD(‘X’, 10000, ‘X’);
BEGIN
FOR i IN 1 .. 1000 LOOP
INSERT INTO keep_duplicates_tab VALUES (i, l_clob);
END LOOP;
COMMIT;
FOR i IN 1 .. 1000 LOOP
INSERT INTO deduplicate_tab VALUES (i, l_clob);
END LOOP;
COMMIT;
END;
/
EXEC DBMS_STATS.gather_table_stats(USER, ‘keep_duplicates_tab’);
EXEC DBMS_STATS.gather_table_stats(USER, ‘deduplicate_tab’);
COLUMN segment_name FORMAT A30
SELECT segment_name, bytes
FROM user_segments
WHERE segment_name IN (‘KEEPDUP_LOB’, ‘DEDUP_LOB’);
SEGMENT_NAME BYTES
—————————— ———-
DEDUP_LOB 262144
KEEPDUP_LOB 19267584
۲ rows selected.
SQL>
به میزان کوچکی سگمنت ها با حذف رکوردهای تکراری توجه نمایید. فضای به دست آمده وابسته به extent های درون LOB سگمنت است.
شیوه duplication با دستور ALTER TABLE قابل استفاده است.
ALTER TABLE deduplicate_tab MODIFY LOB(clob_data) (
KEEP_DUPLICATES
);
EXEC DBMS_STATS.gather_table_stats(USER, ‘deduplicate_tab’);
COLUMN segment_name FORMAT A30
SELECT segment_name, bytes
FROM user_segments
WHERE segment_name IN (‘KEEPDUP_LOB’, ‘DEDUP_LOB’);
SEGMENT_NAME BYTES
—————————— ———-
DEDUP_LOB 76808192
KEEPDUP_LOB 68091904
۲ rows selected.
SQL>
فشرده سازی LOB
گزینه COMPRESS از SecureFile امکان فشرده سازی محتوای LOB در سطح جدول و پارتیشن را فراهم می کند. درجه فشرده سازی با کلمات کلیدی MEDIUM و HIGH مشخص می شود. اگر درجه فشرده سازی مشخص نشود به طور پیش فرض MEDIUM در نظر گرفته می شود. به همراه فرآیند فشرده سازی محتوای LOB سربار نیز به وجود می آید و استفاده از میزان HIGH می تواند در کارایی سیستم نتیجه معکوس داشته باشد. فشرده سازی در SecureFile تاثیری روی فشرده سازی جداول و بالعکس ندارد. مثال زیر مقایسه فضای استفاده شده SecureFile LOB های معمولی و فشرده شده است.
CREATE TABLE nocompress_tab (
id NUMBER,
clob_data CLOB
)
LOB(clob_data) STORE AS SECUREFILE nocompress_lob(
NOCOMPRESS
);
CREATE TABLE compress_tab (
id NUMBER,
clob_data CLOB
)
LOB(clob_data) STORE AS SECUREFILE compress_lob (
COMPRESS HIGH
);
DECLARE
l_clob CLOB := RPAD(‘X’, 10000, ‘X’);
BEGIN
FOR i IN 1 .. 1000 LOOP
INSERT INTO nocompress_tab VALUES (i, l_clob);
END LOOP;
COMMIT;
FOR i IN 1 .. 1000 LOOP
INSERT INTO compress_tab VALUES (i, l_clob);
END LOOP;
COMMIT;
END;
/
EXEC DBMS_STATS.gather_table_stats(USER, ‘nocompress_tab’);
EXEC DBMS_STATS.gather_table_stats(USER, ‘compress_tab’);
COLUMN segment_name FORMAT A30
SELECT segment_name, bytes
FROM user_segments
WHERE segment_name IN (‘COMPRESS_LOB’, ‘NOCOMPRESS_LOB’);
SEGMENT_NAME BYTES
—————————— ———-
COMPRESS_LOB 131072
NOCOMPRESS_LOB 71565312
۲ rows selected.
SQL>
قابل مشاهده است که LOB سگمنت های فشرده شده به طور محسوسی کوچکتر از سگمنت های غیر فشرده شده است. درجه صرفه جویی از فضا وابسته به نوع داده های موجود در سگمنت LOB است.
شیوه فشرده سازی با دستور ALTER TABLE قابل استفاده است.
ALTER TABLE compress_tab MODIFY LOB(clob_data) (
NOCOMPRESS
);
EXEC DBMS_STATS.gather_table_stats(USER, ‘compress_tab’);
COLUMN segment_name FORMAT A30
SELECT segment_name, bytes
FROM user_segments
WHERE segment_name IN (‘COMPRESS_LOB’, ‘NOCOMPRESS_LOB’);
SEGMENT_NAME BYTES
—————————— ———-
COMPRESS_LOB 76808192
NOCOMPRESS_LOB 71630848
۲ rows selected.
SQL>
LOB Encryption
Encrypt نمودن SecureFile LOB ها، وابسته به wallet یا مدل امنیتی سخت افزار (HSM) برای نگهداری کلید encryption است. پیش از انجام مثال های زیر آن ها را انجام دهید.
گزینه ENCRYPT به منظور اعمال encryption در سطح بلاک های محتوای LOB در SecureFile است. یک عبارت انتخابی USING برای تعریف آن دسته از الگوریتم هایی که استفاده می شود است. (۳DES168, AES128, AES192, AES256) پیش فرض AES192 است.
گزینه NO SALT برای SecureFile encryption وجود ندارد. Encryption بر پایه ستونی اعمال می شود بنابراین بر تمام پارتیشن های داخل LOB اعمال می شود. گزینه DECRYPT به منظور عدم اعمال Encryption مورد استفاده قرار می گیرد. در مثال زیر ایجاد یک جدول به همراه encrypted SecureFile LOB نشان داده شده است.
CREATE TABLE encrypt_tab (
id NUMBER,
clob_data CLOB
)
LOB(clob_data) STORE AS SECUREFILE encrypt_lob(
ENCRYPT USING ‘AES256’
);
دستور ALTER TABLE برای encrypt وdecrypt یک ستون موجود مورد استفاده قرار می گیرد. به منظور سوییچ بین الگوریتم های encryption از گزینه REKEY استفاده می شود.
ALTER TABLE encrypt_tab MODIFY (
clob_data CLOB DECRYPT
);
ALTER TABLE encrypt_tab MODIFY (
clob_data CLOB ENCRYPT USING ‘3DES168’
);
ALTER TABLE encrypt_tab REKEY USING ‘AES192’;
Encryption توسط ابزارهای import و export و یا Tablespace های قابل انتقال پشتیبانی نمی شود، بنابراین داده ها باید توسط ابزارهای Data Pump import و Data Pump export منتقل شوند.
Cache و Logging در LOB ها
هر دو LOB های Basicfile و SecureFile گزینه های Cache و Logging مشترک دارند.
گزینه های Caching متداول عبارتند از:
CACHE – داده های LOB در Cache Buffer قرار می گیرند.
CACHE READS – داده های LOB در حین عملیات تنها برای خواندن در Cache Buffer قرار می گیرند نه در حین نوشتن.
NOCACHE – داده های LOB در Cache Buffer قرار نمی گیرند. این گزینه پیش فرض برای هر دو LOB های Basicfile و SecureFile است.
گزینه های اولیه Logging عبارتند از:
LOGGING – ایجاد LOB و تغییرات منجر به تولید redo می شود. این تنظیم پیش فرض است.
NOLOGGING – فرآیند در redolog ها Log نمی شود و قابل Recovery نیستند و می تواند در حین ساخت اولیه و در حین بارگذاری زیاد که احتمال Failure وجود دارد مفید باشد.
علاوه بر این SecureFile LOB ها می توانند گزینه Logging از FILESYSTEM_LIKE_LOGGING را دارا باشند که تنها Metadata ها Log می گردند و می تواند برای بازگردانی سگمنت ها در صورت Failure استفاده شود.
لازمه گزینه CACHE وضعیت LOGGING است و نمی توان آن را با NOLOGGING یا FILESYSTEM_LIKE_LOGGING استفاده نمود.
در کد زیر مثالی از Caching و Logging قبل و بعد از ساخت جدول نشان داده می شود.
CREATE TABLE caching_and_logging_tab (
id NUMBER,
clob_data CLOB
)
LOB(clob_data) STORE AS SECUREFILE(
NOCACHE
FILESYSTEM_LIKE_LOGGING
);
ALTER TABLE caching_and_logging_tab MODIFY LOB(clob_data) (
CACHE
);
PL/SQL APIs
بسته های DBMS_LOB برای هر دو LOB های Basicfile و SecureFile به کار می رود. اثرات معمول LOB با انتقال آن SecureFile تغییر نمی کند. روال SETOPTIONS و تابع GETOPTIONS امکان فشرده سازی و encryption و deduplication را فراهم می سازد.
CREATE TABLE securefile_tab (
id NUMBER,
clob_data CLOB
)
LOB(clob_data) STORE AS SECUREFILE securefile_lob(
encrypt
compress
);
INSERT INTO securefile_tab VALUES (1, ‘ONE’);
INSERT INTO securefile_tab VALUES (2, ‘TWO’);
COMMIT;
SET SERVEROUTPUT ON
DECLARE
l_clob CLOB;
BEGIN
SELECT clob_data
INTO l_clob
FROM securefile_tab
WHERE id = 1
FOR UPDATE;
DBMS_OUTPUT.put_line(‘Compression : ‘ || DBMS_LOB.getoptions(l_clob, DBMS_LOB.opt_compress));
DBMS_OUTPUT.put_line(‘Encryption : ‘ || DBMS_LOB.getoptions(l_clob, DBMS_LOB.opt_encrypt));
DBMS_OUTPUT.put_line(‘Deduplication: ‘ || DBMS_LOB.getoptions(l_clob, DBMS_LOB.opt_deduplicate));
ROLLBACK;
END;
/
بسته DBMS_SPACE دارای سربار روال SPACE_USAGE برای برگرداندن اطلاعات درباره مقدار بلاک های استفاده شده از فضای دیسک توسط تمام LOB ها در LOB سگمنت است. این روال تنها برای ASSM tablespaces استفاده می شود.
SET SERVEROUTPUT ON
DECLARE
l_segment_size_blocks NUMBER;
l_segment_size_bytes NUMBER;
l_used_blocks NUMBER;
l_used_bytes NUMBER;
l_expired_blocks NUMBER;
l_expired_bytes NUMBER;
l_unexpired_blocks NUMBER;
l_unexpired_bytes NUMBER;
BEGIN
DBMS_SPACE.SPACE_USAGE(
segment_owner => ‘TEST’,
segment_name => ‘SECUREFILE_LOB’,
segment_type => ‘LOB’,
segment_size_blocks => l_segment_size_blocks,
segment_size_bytes => l_segment_size_bytes,
used_blocks => l_used_blocks,
used_bytes => l_used_bytes,
expired_blocks => l_expired_blocks,
expired_bytes => l_expired_bytes,
unexpired_blocks => l_unexpired_blocks,
unexpired_bytes => l_unexpired_bytes);
DBMS_OUTPUT.put_line(‘segment_size_blocks:’ || l_segment_size_blocks);
DBMS_OUTPUT.put_line(‘segment_size_bytes :’ || l_segment_size_bytes);
DBMS_OUTPUT.put_line(‘used_blocks :’ || l_used_blocks);
DBMS_OUTPUT.put_line(‘used_bytes :’ || l_used_bytes);
DBMS_OUTPUT.put_line(‘expired_blocks :’ || l_expired_blocks);
DBMS_OUTPUT.put_line(‘expired_bytes :’ || l_expired_bytes);
DBMS_OUTPUT.put_line(‘unexpired_blocks :’ || l_unexpired_blocks);
DBMS_OUTPUT.put_line(‘unexpired_bytes :’ || l_unexpired_bytes);
END;
/
مهاجرت به SecureFiles
روش خودکاری برای مهاجرت یک ستون از BasicFile به SecureFile LOB وجود ندارد. میبایست به طور دستی و با استفاده یکی از متدهای زیر نسبت به تبدیل داده ها اقدام نمایید:
CREATE TABLE … AS SELECT …
INSERT INTO … SELECT …
Online table redefintion.
Export/Import
ایجاد یک ستون جدید، بروزرسانی مقادیر این ستون توسط مقادیر موجود در ستون اصلی و حذف ستون قدیمی.
ساخت یک ستون جدید، بروزرسانی مقادیر این ستون توسط مقادیر موجود در ستون اصلی و تغییر نام جدول و ساخت یک View به نام اصلی که تنها به ستون جدید اشاره دارد.
به غیر از متد export/import تمامی گزینه ها به میزان قابل توجهی از فضای دیسک به هنگام تبدیل LOB های دارای مقادیر داده ای زیاد نیاز دارند.
Oracle Streams از SecureFiles در نسخه ۱۱gr2 در صورتی که LOB ها deduplicated نباشند، پشتیبانی می نماید.
دیدگاه خود را ثبت کنید
تمایل دارید در گفتگوها شرکت کنید؟در گفتگو ها شرکت کنید.