مكانيزم فشرده‌سازي پيشرفته در اوراكل

[Fahim 9,563]

در نگارش 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 است. فشرده‌سازي در پايگاه‌داده اوراكل، راه‌حل جديدي نيست. در Oracle8 i براي اولين بار امكان فشرده‌سازي انديس‌ها از طريق حذف انديس‌هاي تكراري در سطح برگ‌ها فراهم شد. در نگارش دوم از Oracle 9i نيز امكانات جديدي براي فشرده‌سازي جدول‌ها ارائه شد كه نياز به نگهداري مقادير تكراري در جدول‌ها را برطرف مي‌كرد. اين نوع جدول‌ها حتي از عمليات‌هاي دريافت حجمي داده (Bulk load) پشتيباني مي‌كردند و در محيط انبار داده، گزينه قدرتمندي به شمار مي‌آيند. گزينه Oracle Advanced Compression كه در Oracle 11g Enterprise Edition ارائه شده، امكانات غني‌تر و قدرتمندتري دارد كه آن را حتي براي محيط‌هاي OLTP كه حساسيت و نياز بالايي به انجام سريع‌ تراكنش‌ها دارند، نيز به عنوان يك گزينه ايده‌آل مطرح كرده‌است.

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

مراحل فعال‌كردن مكانيزم فشرده‌سازي، بسيار ساده است. جان براي بررسي اين موضوع، دو جدول ايجاد مي‌كند كه اطلاعات حساب‌ها در آن نگهداري مي‌شود، يكي از اين دو جدول از نوع فشرده و ديگري معمولي است (جدول‌هايn,g ihd ACCOUNTS_COMP و ACCOUNT_REG). جان جدول ACCOUNTS_COMP را با استفاده از كد فهرست1 ايجاد مي‌كند. در اين كد به عبارت «Compress For All Operations»، توجه كنيد كه جدول را به ازاي همه دستورات DML به صورت فشرده‌شده ايجاد مي‌كند تا امكان فشرده‌سازي را براي جدول‌هاي OLTP فراهم سازد. (گزينه فشرده‌سازي ديگر عبارت است از «فشرده‌سازي براي عمليات بارگذاري مستقيم يا Direct_load» كه امكان فشرده‌سازي را تنها به ازاي عمليات بارگذاري مستقيم داده «Direct Load Path» يعني عمل INSERT يا APPENT يا استفاده از SQL*Loader به همراه گزينه direct path فراهم مي‌كند.

جدول ACCOUNT_REG نيز با استفاده از همان كد فهرست1 ايجاد مي‌شود، با اين تفاوت كه نام جدول به ACCOUNT_REG تبديل مي‌شود و عبارت «Compress For All Operations» نيز حذف مي‌شود.

برای مشاهده این محتوا لطفاً ثبت نام کنید یا وارد شوید.

• ورود
• یا
• ثبت نام

فهرست 1

سپس از كد ins_acc.sql استفاده مي‌كند(کد فهرست2) تا محيط برنامه‌هاي بانك ACME را شبيه‌سازي كرده و ركوردهاي داده‌اي را در هر دو جدول ثبت كند. begin

for l_acc_no in 1..1000000 loop

insert into accounts_&reg_or_comp

values

)

l_acc_no,

-- 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)

else

l_acc_no + floor(dbms_random.value(1,100((

end,

-- Sub Acc Type

case

when dbms_random.value (1,100)

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;

فهرست2

بعد از درج داده، جان با استفاده از كد زير تعداد بلاك‌هاي درج شده در هر جدول را بررسي مي‌كند:

كد:

select segment_name, blocks, from user_segments where segment_name like ‘ACCOUNTS_%’

خروجي:

SEGMENT_NAME BLOCKS

------------------------- -----------

ACCOUNTS_COMP 4096

ACCOUNTS_REG 11264

خروجي پرس‌وجوي فوق، به خوبي ميزان صرفه‌جويي در فضا، به واسطه نوع جدول را نشان مي‌دهد. هر دو جدول تعداد يكساني از ستون‌هاي هم‌نوع را دارند، اما جدول ACCOUNTS_COMP فقط 096/4 بلاك فضا اشغال كرده‌است كه در مقايسه با 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 درصد باقي ماند:

(1-(8192/22528))

[Fahim 9,563]

I/O و حافظه

براي نشان دادن ساير تأثیرات مثبت و صرفه‌جويي‌هاي حاصل در نتيجه استفاده از مكانيزم Oracle Advanced Compression، جان دو كد آزمايشي ديگر روي دو جدول فوق ايجاد كرد و اين بار آمار حاصل و الگوي بهينه‌سازي (Optimizer Plan) را با اجراي دستور SET AUTOT، فعال كرده و زمان اجرا را يادداشت كرد. قبل از اجراي هر پرس‌وجو، او ناحيه Buffer pool را پاك يا به اصطلاح Flush مي‌كند تا اطمينان حاصل شود كه داده‌ها به‌طور مستقيم از پايگاه‌داده و نه از ناحيه حافظه SGA استخراج مي‌شوند. ابتدا او كد پرس‌وجو را مطابق با كد فهرست 3 به ازاي جدول معمولي اجرا مي‌كند. خروجي اجراي اين كد در فهرست 4 مشاهده مي‌شود. حال براي اجراي همين كد به ازاي جدول فشرده‌شده، كافي است تا عبارت ACCOUNT_REG را با عبارت ACCOUNT_COMP جايگزين كنيد. خروجي حاصل از كد جديد نيز در فهرست 5 مشاهده مي‌شود.

برای مشاهده این محتوا لطفاً ثبت نام کنید یا وارد شوید.

• ورود
• یا
• ثبت نام

فهرست 3

برای مشاهده این محتوا لطفاً ثبت نام کنید یا وارد شوید.

• ورود
• یا
• ثبت نام

فهرست 4

برای مشاهده این محتوا لطفاً ثبت نام کنید یا وارد شوید.

• ورود
• یا
• ثبت نام

شكل 5

زمان اجرا به ازاي جدول معمولي، 4,33ثانيه و به ازاي جدول فشرده‌شده، 4,24 ثانيه است كه معادل با افزيش بيست درصدي در سرعت اجراي كد است. تعداد پردازش‌هاي از نوع خواندن منطقي (logical read)، علت بهبود در سرعت اجراي كد را مشخص مي‌كند: در حالي‌كه به ازاي جدول معمولي بايد 11,212 خواندن منطقي صورت گيرد، اين ميزان به ازاي جدول فشرده‌شده، به 4,122 خواندن منطقي كاهش پيدا مي‌كند. اين كاهش به صرفه‌جويي در مؤلفه CPU_CONSUMED نيز منجر مي‌شود (عدد ثبت شده براي اين مؤلفه به ازاي جدول معمولي 354 و به ازاي جدول فشرده‌شده، 304 است. هر چند كه اين ميزان صرفه‌جويي در مصرف CPU خيلي زياد نيست (و حتي مستندات نشان مي‌دهد كه در بعضي از موارد ميزان مصرف پردازنده به ازاي پرس‌وجو از جدول فشرده‌شده، ممكن است بيشتر نيز باشد)، اما ميزان صرفه‌جويي در استفاده از منابع I/O آن‌چنان قابل توجه است كه به خوبي كاهش زمان پاسخ‌گويي پرس‌وجو را مي‌توان حس كرد. افزايش كارايي سيستم به واسطه استفاده از جدول‌هاي فشرده‌شده، به ويژه هنگام پيمايش يا اسكن كل اطلاعات جدول به خوبي نمايان مي‌شود و اين گونه پردازش‌ها به طور معمول در فرآيندهاي توليد گزارش و پردازش‌هايي از نوع گروهي، به دفعات تكرار مي‌شوند. از آنجا كه در اين حالت هر بلاك از جدول فشرده‌شده، ركوردهاي بيشتري را شامل مي‌شود، در نتيجه، مي‌توان با استفاده از يك SGA كوچك‌تر، به همان ميزان قبل، داده را به صورت Cache شده،‌ در RAM نگهداري كرد و به عبارتي حافظه حال حاضر سيستم مي‌تواند بلاك‌هاي بيشتري را در خود نگهداري كند و در نتيجه به علت Cache شدن ركوردهاي بيشتر، احتمال نياز به پيمايش و جست‌وجوي در سطح ديسك كمتر مي‌شود و اين كار در مراحل بعدي به بهبود I/O منجر شد و متعاقب آن، كارايي بهتر و سرعت پاسخ‌گويي كمتري به دست مي‌آيد.

با در نظر گرفتن نتايج حاصل از بررسي‌هاي جان مشخص مي‌شود كه صرفه‌جويي در فضاي ديسك، تنها مزيت حاصل از فشرده‌سازي نيست و اين روش، بازده مؤلفه‌هاي مختلف سيستم از جمله حافظه و 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 وجود داشته‌باشد:

alter table contracts_sec modify 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 Comperssion براي هر دو مورد كاربرد دارد. در Oracle RMAN، يك الگوريتم فشرده‌سازي جديد به نام ZLIB مي‌تواند داده‌ها را با كارايي بالاتري، فشرده‌سازي كند (در مورد RMAN، مقاله‌‌اي در سايت اوراكل چاپ شده‌است). در مكانيزم Oracle Data Pump نيز مي‌توان فايل‌هاي داده را فشرده‌سازي كرد. جان دستورات مورد نياز را براي ايجاد يك dump file از جدول ACCOUNTS_REG با استفاده از دستور compression=all نشان مي‌دهد.

Expdp / directory= tables=accounts_reg dumpfile=reg.dmp compression=all

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

 

جمع‌بندي

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

 

نتيجه‌گيري

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

 

پایان

منبع : ماهنامه شبکه