مکانيزم فشرده سازي در اوراکل

صرفه جويي در منابع سيستم و بهبود کارايي با استفاده از مکانيزم فشرده سازي پيشرفته در اوراکل Oracle Advanced Compression
در نگارش 11g پايگاه داده اوراکل امکانات متعددي ارائه شده است. اين امکانات براي بهبود کارايي، دسترسي پذيري بيشتر، مديريت آسان تر پايگاه داده، کدنويسي کمتر و کاهش نياز به منابع سخت افزاري نظير رسانه ذخيره سازي و پهناي باند شبکه ارائه شده است. از جمله اين موارد که هم باعث کاهش ميزان نياز به فضاي ذخيره سازي و هم افزايش سرعت مي شود، مکانيزم Advanced Compression است که الگو و الگوريتم فشرده سازي آن در عين کاهش نياز به فضاي ذخيره سازي، به علت سرباره پردازشي کم و کاهش شديد بار I/O مي تواند تاثير بسيار مثبتي در کارايي پايگاه داده داشته باشد. در اين مقاله به بررسي اين مکانيزم جديد مي پردازيم.
جان، به عنوان مدير پايگاه در بانک Acme Bank فعاليت مي کند و در حال حاضر مشغول بررسي نمودارها و صفحات گسترده اي است که توسط گروه تعيين ظرفيت آتي بانک، ارائه شده است. در طول بررسي اين نمودارها مي توان يک پيام ساده را به روشني دريافت کرد، در آينده نه چندان دور حجم پايگاه داده بانک به طور فزاينده اي افزايش پيدا خواهد کرد. اين مسئله از دلايل مختلفي ناشي مي شود، به عنوان مثال، رشد طبيعي کسب و کار بانک، انتقال برنامه هاي کنوني از سيستم هاي مبتني بر دسکتاپ به سيستم هاي سازماني بزرگ و متمرکز، درخواست هاي قانوني به منظور نگهداري داده براي مدت طولاني تر و مجموعه اي از عوامل ديگر. تمام اين موارد به رشد تواني حجم پايگاه داده و در نتيجه آن نياز به ظرفيت پردازشي بالاتر (پردازنده، شبکه، I/O و پهناي باند) منجر مي شود. البته، افزايش نياز به همه اين موارد به يک نسبت نخواهد بود. اين فرآيند به معني در نظر گرفتن فاکتورهاي متعدد در سطح پايگاه داده مي شود که از آن جمله مي توان به اين موارد اشاره کرد:
1- رشد سرسام آور هزينه خريد تجهيزات ذخيره سازي: اين گروه پيشنهاد کرده است تا به منظور کاهش هزينه ها از ادوات ذخيره سازي ارزان تر استفاده شود که منطقاً بر سرعت و کارايي سيستم ها تاثير منفي خواهد داشت.
2- داده بيشتر به معني نياز به فضاي بيشتر براي نگهداري از نسخه هاي پشتيبان: يکي از گزينه ها، براي کاهش اين هزينه ها اين است که تعداد نسخه هاي پشتيباني که تهيه و روي ديسک نگهداري مي شوند، کاهش يابد، که اين کار بهترين روش ممکن نيست، زيرا باعث افزايش زمان مورد نياز براي بازيابي مي شود.
3- اگر ميزان داده اي که از آن پشتيبان تهيه مي شود زياد باشد، زمان مورد نياز براي تهيه آن نيز افزايش مي يابد و در نتيجه ممکن است با ساير jobهاي تهيه نسخه پشتيبان که برنامه ريزي شده است، دچار تداخل شود.
4- افزايش حجم داده، همچنين به معناي افزايش ميزان I/O بين مولفه هاي مختلف سيستم، نظير کارت هاي HBA (سرنام Host Bus Adapter) و رابط هاي متصل به ادوات ذخيره سازي سطح شبکه (NAS) مي شود و اين مسئله نيز بر کارايي سيستم تاثير منفي دارد.
5- داده بيشتر در پايگاه داده، به معني نياز به اختصاص حافظه بيشتر به ناحيه SGA (سرنام System Global Area) است و اختصاص حافظه بيشتر به SGA به معني نياز به تهيه حافظه بيشتر براي سرور است. اگر حافظه بيشتر در اختيار نباشد، ميزان کمتري از داده در SGA به صورت Cache شده نگهداري مي شود و باعث کاهش کارايي مي شود. براي مقابله با اين مسائل، گروه مديران پايگاه داده در Acme Bank ، پيشنهادهاي معمول را ارائه کرده است. اين پيشنهادها عبارتند از: افزودن به ميزان فضاي ديسک، حافظه، ظرفيت شبکه و پهناي باند براي I/O. اما با در نظر گرفتن تاکيد فراوان بر صرفه جويي، اين راهکارها توسط گروه مديران بانک، مورد تاييد قرار نگرفت. جيل که مدير گروه مديران پايگاه داده بانک را بر عهده دارد، اميدوار است که جان بتواند يک راه حل جايگزين براي اين مشکل پيدا کند، به نحوي که با افزايش ميزان داده، کارايي سيستم ها در سطح کنوني آن حفظ شود و در همان حال ميزان ديسک، حافظه، I/O نيز افزايش يابد يا حتي کاهش پيدا کند.

راه حل: فشرده سازي
 

هرچند که مشکلات زيادي وجود دارد، علت اصلي را مي توان به طور مختصر اين گونه بيان کرد: رشد داده با ضريب افزايش تواني. داده بيشتر به فضاي بيشتري در سطح ديسک نياز دارد و اين مسئله به نوبه خود، به معني هزينه بيشتر براي نگهداري پايگاه داده و نسخه هاي پشتيبان تهيه شده براي آن و همچنين افزايش ميزان I/O است. اگر روشي وجود داشت که بتوان حجم کنوني داده را به صورت موثرتري (در حجم کمتر) روي ديسک نگهداري کرد، همه مشکلات مرتبط با حجم زياد داده نيز حل مي شدند. سوالي که در اينجا مطرح مي شود اين است که چگونه مي توان بدون پاک کردن داده، ميزان مصرف فضاي ديسک را کاهش داد.
مکانيزم Oracle Advanced Compression، گزينه جديدي است که در پايگاه داده Oracle 11g Enterprise Edition مطرح شده است و پاسخي به شکل ناشي از رشد حجم داده در Acme Bank است. فشرده سازي در پايگاه داده اوراکل، راه حل جديدي نيست. در Oracle8i براي اولين بار امکان فشرده سازي انديس ها از طريق حذف انديس هاي تکراري در سطح برگ ها فراهم شد. در نگارش دوم از Oracle9i نيز امکانات جديدي براي فشرده سازي جدول ها ارائه شد که نياز به نگهداري مقادير تکراري در جدول ها را برطرف مي کرد. اين نوع جدول ها حتي از عمليات دريافت حجمي داده (Bulk load) پشتيباني مي کردند و در محيط انبار داده، گزينه قدرتمندي به شمار مي آيند.گزينه Oracle Advanced Compression که در Oracle 11g Enterprise Edition ارائه شده، امکانات غني تر و قدرتمندتري دارد که آن را حتي براي محيط هاي OLTP که حساسيت و نياز بالايي به انجام سريع تراکنش ها دارند، نيز به عنوان يک گزينه ايده آل مطرح کرده است.

مراحل فشرده سازي و نياز به ديسک
 

مراحل فعال کردن مکانيزم فشرده سازي، بسيار ساده است. جان براي بررسي اين موضوع، دو جدول ايجاد مي کند که اطلاعات حساب ها در آن نگهداري مي شود، يکي از اين دو جدول از نوع فشرده و ديگري معمولي است (جدول هاي n,g ihd ACCOUNTS_COMP و ACCOUNT_REG). جان جدول ACCOUNT_COMP را با استفاده از کد فهرست 1 ايجاد مي کند. در اين کد به عبارت « Compress For All Operations» توجه کنيد که جدول را به ازاي همه دستورات DML به صورت فشرده شده ايجاد مي کند تا امکان فشرده سازي را براي جدول هاي OLTP فراهم سازد.(گزينه فشرده سازي ديگر عبارت است از: «فشرده سازي براي عمليات بارگذاري مستقيم يا Direct_load» که امکان فشرده سازي را تنها به ازاي عمليات بارگذاري مستقيم داده «Direct Load Path» يعني عمل INSERT يا APPENT يا استفاده از SQL*Loader به همراه گزينه directpath فراهم مي کند.
جدول ACCOUNT_REG نيز با استفاده از همان کد فهرست 1 ايجاد مي شود، با اين تفاوت که نام جدول به ACCOUNT_REG تبديل مي شود و عبارت «Compress Forr All Operations» نيز حذف مي شود. سپس از کد ins_acc.sql استفاده مي کند (کد فهرست 2) تا محيط برنامه هاي بانک ACME را شبيه سازي کرده و رکوردهاي داده اي را در هر دو جدول ثبت کند. بعد از درج داده، جان با استفاده از کد زير تعداد بلاک هاي درج شده در هر جدول را بررسي مي کند:

کد:

select segment_name,blocks,from user_segments where segment_name like 'ACCOUNTS_%
 

خروجي:

SEGMENT_NAME BLOCKS
--------- -------------------
4096 ACCOUNTS_COMP
11264 ACCOUNTS_REG
 

خروجي پرس و جوي فوق، به خوبي ميزان صرفه جويي در فضا، به واسطه نوع جدول را نشان مي دهد. هر دو جدول تعداد يکساني از ستون هاي هم نوع را دارند، اما جدول ACCOUNTS_COMP فقط 4/096 بلاک فضا اشغال کرده است که در مقايسه با 11/264 بلاک اختصاص يافته به جدول ACCOUNTS_REG معادل با 64 درصد صرفه جويي در فضاي ديسک است.
البته، جان به اين نکته نيز اشاره کرد که ميزان صرفه جويي در فضاي ديسک، متفاوت است و به ماهيت و نوع داده ذخيره شده، بستگي دارد.
جان همچنين بررسي هايي را انجام داد تا مشخص شود که آيا، ضريب فشرده سازي داده، بعد از ايجاد تغييرات در آن، همان ميزان قبل خواهد بود يا خير. او دوباره کد ins_acc.sql را روي هر دو جدول اجرا کرد و نتيجه حاصل را مورد بررسي قرار داد:
کد:

select segment_name,blocks,from user_segments where segment_name like 'ACCOUNTS_%'
 

خروجي:

SEGMENT_NAME : BLOCKS
--------- -------------------
ACCOUNTS_COMP : 8192
ACCOUNTS_REG : 22528
 

ميزان ضريب فشرده سازي تغييري نکرد و تقريباً همان عدد 64 درصد باقي ماند:
((8192/22528)-1)

I/O و حافظه
 

براي نشان دادن ساير تاثيرات مثبت و صرفه جويي هاي حاصل در نتيجه استفاده از مکانيزم Oracle Advanced Compression، جان دو کد آزمايشي ديگر روي دو جدول فوق ايجاد کرد و اين بار آمار حاصل و الگوي بهينه سازي (Optimizer Plan) را با اجراي دستور SET AUTOT ، فعال کرده و زمان اجرا را يادداشت کرد. قبل از اجراي هر پرس و جو، او ناحيه Buffer pool را پاک يا به اصطلاح Flush مي کند تا اطمينان حاصل شود که داده ها به طور مستقيم از پايگاه داده و نه از ناحيه حافظه SGA استخراج مي شوند. ابتدا او کد پرس و جو را مطابق با کد فهرست 3 به ازاي جدول معمولي اجرا مي کند. خروجي اجراي اين کد در فهرست 4 مشاهده مي شود. حال براي اجراي همين کد به ازاي جدول فشرده شده، کافي است تا عبارت ACCOUNT_REG را با عبارت ACCOUNT_COMP جايگزين کنيد. خروجي حاصل از کد جديد نيز در فهرست 5 مشاهده مي شود.
زمان اجرا به ازاي جدول معمولي، 4/33 ثانيه و به ازاي جدول فشرده شده، 4/24 ثانيه است که معادل با افزايش بيست درصدي در سرعت اجراي کد است. تعداد پردازش هاي از نوع خواندن منطقي (logical read)، علت بهبود در سرعت اجراي کد را مشخص مي کند: در حالي که به ازاي جدول معمولي بايد 11/212 خواندن منطقي صورت گيرد، اين ميزان به ازاي جدول فشرده شده، به 4/122 خواندن منطقي کاهش پيدا مي کند. اين کاهش به صرفه جويي در مولفه CPU_CONSUMED نيز منجر مي شود (عدد ثبت شده براي اين مولفه به ازاي جدول معمولي 354 و به ازاي جدول فشرده شده، 304 است. هرچند که اين ميزان صرفه جويي در مصرف CPU خيلي زياد نيست (و حتي مستندات نشان مي دهد که در بعضي از موارد ميزان مصرف پردازنده به ازاي پرس و جو از جدول فشرده شده، ممکن است بيشتر نيز باشد)، اما ميزان صرفه جويي در استفاده از منابع I/O آن چنان قابل توجه است که به خوبي کاهش زمان پاسخ گويي پرس و جو را مي توان حس کرد. افزايش کارايي سيستم به واسطه استفاده از جدول هاي فشرده شده، به ويژه هنگام پيمايش يا اسکن کل اطلاعات جدول به خوبي نمايان مي شود و اين گونه پردازش ها به طور معمول در فرآيندهاي توليد گزارش و پردازش هايي از نوع گروهي، به دفعات تکرار مي شوند. از آنجا که در اين حالت هر بلاک از جدول فشرده شده، رکوردهاي بيشتري را شامل مي شود، در نتيجه، مي توان با استفاده از يک SGA کوچک تر، به همان ميزان قبل، داده را به صورت Cache شده، در RAM نگهداري کرد و به عبارتي حافظه حال حاضر سيستم مي تواند بلاک هاي بيشتري را در خود نگهداري کند و در نتيجه به علت Cache شدن رکوردهاي بيشتر، احتمال نياز به پيمايش و جست و جوي در سطح ديسک کمتر مي شود و اين کار در مراحل بعدي به بهبود I/O منجر شد و متعاقب آن، کارايي بهتر و سرعت پاسخ گويي کمتري به دست مي آيد.

begin
for 1_acc_no in 1..1000000 loop
insert into accounts_&reg_or_comp
values
(
no_acc_1,
First Name--
(decode
,))floor(dbms_random.value(1,21
1, 'Alan'
2,'Alan',
3,'Barbara',
4,'Barbara',
5,'Charles',
6,'David',
7,'Ellen',
8,'Ellen',
9,'Ellen',
10,'Frank',
11,'Frank',
12,'Frank',
13,'George',
14,'George',
15,'George',
16,'Hillary',
17,'Iris',
18,'Iris',
19,'Josh',
20,'Josh',
'XXX'
),
Last Name--
)decode
,))floor(dbms_random.value(1,5
1,'Smith',
dbms_random.string))A',dbms_random.value(4,30((,
Account Type--
)decode
floor(dbms_random.value(1,5,((
1, 'S' , 2 , 'C' ,3,'M' , 4, 'D', 'X'
),
Folio ID--
case
when dbms_random.value(1,100)< 51 then null
else
floor(dbms_random.value(1,100))+ 1_acc_no
,end
Sub Acc Type--
case
when dbms_random.value(1,100) <76 then null
else
decode(floor(dbms_random.value(1,6,((
1,'S', 2, 'C', 3,' C', 4, ' C', 5,' C', null)
,end
Acc Opening Date--
sysdate_dbms_random.value(1,500,(
Account Manager ID--
(\decode
floor(dbms_random.value(1,11,))
1,1,2,1,3,1,4,1,5,2,6,3,7,4,8,5,9,5,10,5,0
)
);
;end loop
;commit
;end
 

با در نظر گرفتن نتايج حاصل از بررسي هاي جان مشخص مي شود که صرفه جويي در فضاي ديسک، تنها مزيت حاصل از فشرده سازي نيست و اين روش، بازده مولفه هاي مختلف سيستم از جمله حافظه و I/O را از جهات مختلف بهبود مي بخشد و در مواردي که اسکن کلي يا قسمتي جدول ها مدنظر باشد، اين روش به دليل کاهش I/O، باعث صرفه جويي در ميزان مصرف پردازنده مي شود.

انواع فشرده سازي
 

تکنيک Oracle Advanced Compression، بيش از يک روش فشرده سازي را شامل مي شود که بررسي همه آن ها لازم است، زيرا بانک ACME، بايد از فشرده سازي براي انواع مختلفي از داده هاي مورد پردازش، نوع، مورد کاربرد، استفاده کند. جان انواع روش هاي فشرده سازي موجود را بررسي کرده و امکان استفاده از آن ها را براي برطرف کردن نيازهاي مختلف بانک مورد بررسي قرار مي دهد.
فشرده سازي جدول هاي OLTP: با استفاده از گزينه فشرده سازي جدول هاي OLTP، فرآيند فشرده سازي در سطح بلاک ها انجام مي شود و داده ها هنگام درج در جدول، فشرده نمي شوند. يعني به جاي فشرده سازي در مرحله درج داده، از يک الگوريتم دروني ايجاد استفاده مي شود تا مشخص شود که چه زماني ميزان داده فشرده نشده در بلاک، به اندازه کافي بوده و آن بلاک، آماده فشرده شدن است. وقتي که بلاک آماده باشد، الگوريتم فشرده سازي، مقداري از يک رکورد را خوانده و ارجاعي به آن مقدار را در جدول نمادها ايجاد مي کند که به هدر بلاک اشاره خواهد کرد، سپس الگوريتم، سعي مي کند مقادير مشابه در بلاک را شناسايي کند و به ازاي هريک از مقادير مشابه يافت شده، آن مقدار را با نماد معادل از جدول نمادها، جايگزين کند. به اين ترتيب فقط داده هاي يک رديف يا ستون خاص فشرده نمي شوند، بلکه داده در هر جاي بلاک که باشد، فشرده سازي مي شود. هر بلاک به طور مستقل، فشرده سازي مي شود و جدول نمادهاي خودش را دارد، در نتيجه، فشرده سازي معمولاً سريع تر از ساير روش هايي است که در سطح پايين تر و خارج از محيط اوراکل، داده ها را فشرده سازي مي کنند، زيرا در اين روش ها معمولاً از يک جدول نماد به ازاي کل داده ها، استفاده مي شود. اين روش مستقل فشرده سازي در سطح بلاک براي داده هاي جديد يا تغيير يافته، نيز قابل تطبيق است. در صورت لزوم مي توان بلاک ها را به منظور به روزرساني جدول نمادها، از حالت فشرده خارج و دوباره فشرده سازي کرد. در حالي که فشرده سازي يک جدول نماد عمومي بدون ايجاد مکانيزم هاي قفل گذاري، خيلي سخت تر است و اين به آن معنا است که الگوريتم هاي فشرده سازي مذکور براي اعمال تغيير ايجاد شده در داده، انطباق پذيري کمي دارند و اين مسئله به مرور زمان، درصد فشرده سازي را نيز کاهش مي دهد. مکانيزم Oracle Advanced Compression، در زمان درج يا تغيير داده اعمال نمي شود، بلکه داده به همان شکل معمولي و فشرده نشده درج شده و زماني که حجم داده به يک ميزان مشخص برسد که به عنوان معيار اجراي الگوريتم فشرده سازي در نظر گرفته مي شود، در اين صورت الگوريتم فشرده سازي کل داده بلاک را به صورت دسته اي دريافت کرده و آن را به روش مذکور فشرده سازي مي کند.
در نتيجه همه تراکنش هاي در سطح آن بلاک، با مسئله استفاده زياد از پردازنده به منظور فشرده سازي بلاک مواجه نيستند و تنها تراکنش هايي که به واسطه آن ها، حجم داده بلاک به ميزان مناسبي مي رسد، باعث اجراي مکانيزم فشرده سازي مي شوند و فقط به ازاي اين تراکنش ها است که با مدت انتظار بيشتري مواجه مي شويم که مقدار آن نيز ناچيز است. اين الگوريتم پردازش دسته اي، سرباره ايجاد شده براي پردازنده به ازاي عمليات هاي DML را به حداقل مي رساند و در نتيجه آن مکانيزم Oracle Advanced Compression را براي استفاده در سيستم هاي OLTP به عنوان يک مکانيزم، ايده آل مطرح مي کند.
فشرده سازي داده هاي بدون ساختار: بانک ACME همچنين مقدار زيادي داده بدون ساختار مي کند، نظير اسنادXML، امضاها (به صورت فايل هاي GIF) و بخش نامه ها (به صورت فايل هاي PDF) را نيز نگهداري به دليل قوانين متعدد دولتي و ساير الزامات و تعهداتي که بانک ملزم به رعايت آن ها است، بايد اين داده هاي بدون ساختار در پايگاه داده نگهداري شود که فضاي بسيار زيادي را اشغال مي کند.
مکانيزم Oracle Advanced Replication فقط براي داده هاي رابطه اي کاربرد ندارد. در پايگاه داده اوراکل 11g، ساير انواع داده را نيز مي توان فشرده سازي کرد، که البته در بعضي موارد کد مورد نياز براي فشرده سازي، به تغييرات کوچکي نياز دارد، به عنوان مثال نوع داده اي به نام Oracle SecureFiles (نسل بعدي اشياء بزرگ يا LOB که براي اولين بار در اوراکل 11g معرفي شده است) از دو تکنيک براي کم کردن نياز به فضاي ذخيره سازي استفاده مي کند. اين دو روش عبارتند از فشرده سازي و حذف تکرارها. جان براي ارائه اطلاعات بيشتر در مورد فشرده سازي در Oracle SecureFiles مقاله اي با نام SecureFiles:The New LOBs را در سايت اوراکل ارائه داده است. او براي نشان دادن مزيت هاي اين نوع داده، يک مثال از Oracle SecureFiles ايجاد مي کند که در آن جدول CONTRACT_SEC تغيير داده مي شود تا در آن، يک ستون فشرده شده از نوع LOB با نام ORIG_FILE وجود داشته باشد:

set serveroutput on size unlimited
alter system flush buffer_cache
/
col value noprint new_value start_cpu
select value
from v$sesstat s,v$statname n
where sid=(select sid from v$mystat where rownum < 2)
and s.statistic# = n.statistic#
and n.name in ( 'CPU used by this session')
/
col value noprint new_value start_reads
select value
from v$sesstat s, v$statname n
where sid=(select sid from v$mystat where rownum< 2)
and s.statistic# = n.statistic#
and n.name in ( 'session logical reads')
/
set autot on explain stat
set timing on
select acc_mgr_id , acc_type
avg((sysdate-acc_open_dt))
from accounts_reg
group by acc_mgr_id,acc_type
order by acc_mgr_id, acc_type
/
set autot off
select value- &start_cpu cpu_consumed
from v$sesstat s, v$statname n
where sid=(select sid from v$mystat where rownum < 2)
and s.statistic# = n.statistict#
and n.name in( ' CPU used by this session')
/
select value- &start_reads logical_reads
from v$sasstat s, v$statname n
where sid =(select sid from v$mystat where rownum < 2)
and s.statistic# = n.statistic#
and n.name in ('session logical reads')
/
alter table contracts_sec modiry lob (orig_file) (compress high)
 

اگر به ازاي نوع داده Oracle SecureFiles در ستون ORIG_FILE موارد تکراري ثبت شود، در اين صورت موارد تکراري در جدول CONTRACTS_SEC، حذف شده و تنها يک اشاره گر به آن ها داريم که در نتيجه نياز به رسانه ذخيره سازي کاهش مي يابد. بنابراين، اگر چهار کپي از يک سند مشابه در ستون ORIG_FILE نگهداري شود، اين فايل تنها يک بار ذخيره مي شود و فرآيند حذف کپي هاي تکراري، به صرفه جويي 75 درصدي در فضاي مورد استفاده منجر مي شود. جان کد مورد نياز را براي حذف موارد تکراري از ستون ORIG_FILE به صورت زير ارائه کرده است:

alter table contracts_sec modify lob(orig_file) deduplicate)
 

فشرده سازي فايل هاي Backup: به دو روش مي توان از Instance پايگاه داده اوراکل، نسخه پشتيبان تهيه کرد، روش اول استفاده از ابزار Oracle Data Pump است که روش منطقي به حساب مي آيد و روش ديگر استفاده از Oracle RMAN (سرنام Oracle Recovery Manager) است که به عنوان روش تهيه پشتيبان فيزيکي به حساب مي آيد.
مکانيزم Oracle Advanced Compression براي هر دو مورد کاربرد دارد. در Oracle RMAN، يک الگوريتم فشرده سازي جديد به نام ZLIB مي تواند داده ها را با کارايي بالاتري، فشرده سازي کند (در مورد RMAN ، مقاله اي در سايت اوراکل چاپ شده است). در مکانيزم Oracle Data Pump نيز مي توان فايل هاي داده را فشرده سازي کرد. جان دستورات مورد نياز را براي ايجاد يک dump file از جدول ACCOUNTS_REG با استفاده از دستور compression=all نشان مي دهد.

Expdp<User>/<Pass> directory = <DirName>
tables=accounts_reg dumpfile=reg.dmp compression=all
 

اين روش يک dumpfile فشرده شده با حجم 41 مگابايت ايجاد مي کند که reg.dmp نام دارد. جان همان دستور expdp را بدون استفاده از عبارت مربوط به فشرده سازي استفاده مي کند که اين کار باعث ايجاد فايل dump به حجم نود مگابايت مي شود. بنابراين، مکانيزم Oracle Advanced Compression مي تواند داده ها را با ضريب پنجاه درصد، فشرده سازي کند.
زماني که جان dumpfile فشرده شده را import مي کند، ابزار Oracle Data Pump، فايل فشرده شده را خوانده و به صورت دروني آن را از حالت فشرده، خارج مي کند. مکانيزم Oracle Advanced Compression، براي سيستم هاي Data Guard نيز کاربردهايي دارد، به اين ترتيب که فايل هاي Stream استخراج شده از Redo را فشرده سازي مي کند تا تاخير زماني بين پايگاه داده اصلي و پايگاه داده جانبي را به حداقل برساند و اين فشرده سازي در سطح شبکه، تاثير مثبت زيادي ايجاد مي کند.

جمع بندي
 

کاهش فضاي مورد نياز براي ذخيره سازي داده ها در پايگاه داده، به طور مستقيم باعث کاهش نياز به فضاي ذخيره سازي است. بنابراين، Acme Bank براي نگهداري فايل هاي پشتيبان، به خريد ديسک هاي اضافي نياز ندارد. از آنجا که تهيه نسخه پشتيبان، از تعداد بلاک هاي کمتري صورت مي گيرد در نتيجه، نسخه پشتيبان نيز سريع تر انجام مي شود و زمان در نظر گرفته شده براي تهيه نسخه پشتيبان پاسخ گوي نيازهاي آتي سيستم نيز خواهد بود.
Acme همچنين يک پايگاه داده مرحله گذر(Staging) دارد که يک کپي از پايگاه داده عملياتي در آن نگهداري مي شود. نياز به رسانه هاي ذخيره سازي به ازاي اين پايگاه داده نيز همانند ساير پايگاه داده ها، نظير QA و پايگاه داده محيط توسعه، کاهش يافته است. به طور خلاصه آن که، با استفاده از Oracle Advanced Compression ، ديگر به سخت افزار، ديسک، سرعت بالاتر براي I/O ، حافظه، نوارهاي ذخيره سازي و پهناي باند بيشتر نيازي نخواهد بود. جان اين آمار و ارقام را که خبر بسيار خوشايندي به حساب مي آمد، جمع آوري کرد و آن ها را در اختيار جيل قرار داد.

نتيجه گيري
 

در طول چند سال گذشته، پيشرفت هايي حاصل شده که قبل از آن حتي تصور آن هم ممکن نبود. از جمله اين پيشرفت ها مي توان به ارائه پردازنده هايي با شانزده هسته يا ديسک هايي با ظرفيت 720 گيگابايت و فراتر از آن اشاره کرد. حرکت در اين مسير همواره رو به جلو بوده است و با گذشت زمان، پردازنده هايي با قدرت پردازش بالاتر و ديسک هايي با ظرفيت بيشتر ارائه خواهند شد، اما آنچه که خيلي تغيير نکرده است و انتظار نمي رود تغيير زيادي در آن رخ دهد، به ميزان سرعت دسترسي به اين داده ها در سطح ديسک، مربوط مي شود. اين مقاله نشان دهده که چگونه جان با رشد کنترل نشده داده، دست و پنجه نرم کرد و چگونه توانست با استفاده از Oracle Advanced Compression، با مشکل رشد حجم داده و محدوديت فضاي ديسک، مقابله کند. او توانست داده بيشتري را به صورت موثري در فضاي کمتري ذخيره سازي کند، که در نتيجه آن به ازاي همان مقدار اطلاعات ارسالي قبلي، ميزان داده بيشتري مبادله مي شود. پس اين کار نه تنها نياز بانک Acme را به رسانه ذخيره سازي کاهش مي دهد، بلکه کارايي پايگاه داده اين بانک نيز افزايش مي يابد.
منبع:نشريه شبکه- ش 102