ساختار فیزیکی ذخیره سازی داده ها در بانک اطلاعاتی اوراکل چگونه است؟ یکی از ویژگی های یک RDBMS یا همان سیستم های پایگاه داده ی رابطه ای، استقلال ساختار داده های منطقی از قبیل جدول ها،ویوها،اندیس ها از ساختار فیزیکی ذخیره سازی می باشد. از آنجا که ساختار فیزیکی و منطقی از یکدیگر مجزا هستند، می توانیم ذخیره سازی فیزیکی داده ها را بدون تاثیر دسترسی به ساختار منطقی داده ها، مدیریت کنیم.برای مثال تغییر نام یک فایل دیتابیس، نام جدول ذخیره شده در آن را تغییر نمی دهد. یک پایگاه داده ی اراکل مجموعه ای از فایل ها است که دیتای اوراکل در حافظه دیسک پایا ذخیره می کند.ساختار فیزیکی بانک اطلاعاتی بخش های مختلفی را شامل می شود که مهمترین آنها می توان به می توان به Data File ها، Control Fileها و Redo File ها اشاره کرد.که در این مقاله به بررسی این انواع می پردازیم:
مروری بر دیتا فایل ها
در سطح سیستم عامل، پایگاه داده ی اوراکل ،داده های دیتابیس را در Data file ها ذخیره می کند. هر دیتابیس اوراکل حداقل یک Data file دارد.از طریق این فایل ها امکان نگهداری Object های موجود در قسمت Schema همچون اندیس ها، جدول ها، ویو ها و ... میسر می شود.برای سهولت مدیریت، دیتابیس اراکل فضایی را برای داده ی کاربر در table space ها اختصاص می دهد که همانند سگمنت ها ساختار منطقی ذخیره سازی می باشد.
هر بخش یا سگمنت تنها متعلق به یک table space می باشد.برای مثال داده ها برای یک جدول nonpartitioned یا بخش بندی نشده تنها در یک سگمنت ذخیره می شوند که آن نیز به نوبه ی خود در یک tablespace ذخیره می شود .در نکته ای مجزا به توضیح مفاهیم segment و table space خواهیم پرداخت.در اینجا اشاره می کنیم که tablespace پل بین اجزای فیزیکی ومنطقی در اوراکل دیتابیس محسوب شده و دیتا فایل ها در table space ذخیره می شوند. چون datafile ها به طور مستقیم در دسترس قرار نمی گیرند از طریق این لایه مدیریت می شوند. دیتابیس اراکل به طور فیزیکی داده های table space ها را در دیتا فایل ها ذخیره می کند.tablespace ها و دیتا فایل ها بسیار به هم مرتبط هستند اما تفاوتهای مهمی دارند:
- هر Tablespace یک و یا تعداد بیشتری از دیتا فایل ها را شامل می شود که با سیستم عاملی که دیتابیس اراکل روی آن اجرا شده،مطابقت خواهد داشت.
- داده ها برای یک دیتابیس مجموعا در دیتافایل های واقع شده در هر tablespace دیتابیس ذخیره شده اند.
- یک سگمنت می تواند یک یا تعداد بیشتری دیتافایل گسترده شود، اما قابلیت پوشش چندین tablespace را ندارد.
- یک دیتابیس باید tablespace های SYSTEM و SYSAUX را داشته باشد.دیتا بیس اوراکل به صورت اتوماتیک اولین دیتا فایل های دیتابیس را برای SYSTEM table space در طول ایجاد دیتابیس اختصاص می دهد.
تصویر زیر ارتباط بین tablespace ها، دیتافایل ها و سگمنت ها را نمایش می دهد:
دیتا فایل های دائم و موقت (permanent و temporary):
Tablespace دائمی ، اشیای پایای یک Schema یا شما را در بر می گیرد. این Object ها و یا اشیا ِ یک tablespace دائم در دیتا فایل ها ذخیره می شوند. tablespace موقت نیز تنها اشیای یک Schema در طی یک session را نگهداری می کند. برای مدیریت tablespace های موقت به صورت لوکال فایل های موقت یا temp file هایی وجود دارد که فایل های خاص طراحی شده برای ذخیره ی داده در hash، مرتب کردن و عملیات دیگری از این قبیل می باشند. Temp فایل ها همچنین هنگامی که فضای کافی در حافظه موجود نباشد، نتیجه ی مجموعه ی داده ها را ذخیره می کنند. Temp فایل ها یا همان فایل های موقت مشابه فایل های دائمی می باشند البته به استثنا موارد زیر:
- اشیای پایگاه داده ی دائم مانند جداول هرگز در temp file ها ذخیره نمی شوند.
- فایل های موقت همیشه روی وضعیت NOLOGGING تنظیم می شوند و به این معنی است که هرگز فایل های redo برای آن ها ایجاد نخواهد شد و واسطهای ریکاوری قادر به تشخیص temp فایل ها نیستند.
- مانمی توانیم temp فایل هارا به صورت فقط خواندنی یا read only ایجاد کنیم.
- هنگامی که temp فایل ها را ایجاد کرده و یا تغییر اندازه می دهیم، تضمینی برای تخصیص فضای دیسک با اندازه فایل مشخص شده برای این temp فایل ها وجود نخواهد داشت.در فایل سیستم هایی چون لینوکس و یونیکس، temp فایل ها به عنوان فایل های پراکنده ایجاد شده اند. در این مورد، بلاک های دیسک نه به هنگام ایجاد فایل و نه تغییر اندازه اختصاص داده نمی شوند اما به عنوان بلاک هایی برای اولین بار قابل دسترسی هستند.
- اطلاعات یک temp فایل در data dictionary (که در بردارنده ی لیستی از تمامی فایل های پایگاه داده است ( و در بخش ویو DBADATAFILES و عملکرد پویای آن در ویو V$TEMPFILE نشان داده شده است نه در ویو مربوط به DBADATAFILEA و یا V$DATAFILE
دیتا فایل های آنلاین و آفلاین
هر فایل داده یا همان دیتا فایل می تواند آنلاین( در دسترس ) و یا آفلاین (غیر قابل دسترسی) باشد.می توانیم دسترسی پذیری دیتا فایل های individual و یا temp file ها را با در نظر گرفتن آنها به صورت آنلاین و یا آفلاین تغییر دهیم.فایل های آفلاین قابل دسترسی نخواهند بود تا زمانی که آنلاین شوند.مدیران ممکن است دیتا فایل ها را به دلایل مختلفی به صورت آفلاین نگه دارند از جمله پشتیبان گیری به صورت آفلاین، تغییر نام دیتا فایل و یا بلاک کردن فایل دچار مشکل.پایگاه داده دیتا فایل ها را به صورت خودکار آفلاین در نظر می گیرد اگر که دیتابیس قادر به نوشتن (write) روی آن فایل داده نباشد.
همانند دیتا فایل یک tablespace نیز خود می تواند آنلاین و یا آفلاین باشد. وقتی که یک دیتا را در یک tablespace آنلاین، آفلاین کنیم خود table space همچنان آنلاین باقی می ماند.می توان تمامی دیتا فایل های یک tablespace را با قرار دادن آن در وضعیت آفلاین tablespace ،به طور موقت از دسترس خارج کرد.
ساختار دیتا فایل ها
پایگاه داده ی اوراکل یک دیتافایل را برای یک tablespace با تخصیص مقدار مشخص شده ای از هارد به علاوه ی سربار برای هدر دیتا فایل ایجاد می کند.سیستم عاملی که دیتابیس اراکل روی آن اجرا شده است وظیفه پاکسازی اطلاعات قدیمی و authorize یک فایل را قبل ازاختصاص آن به دیتابیس به عهده دارد. هدر دیتا فایل در بردارنده متادیتاهای مربوط به دیتافایل از قبیل سایز آن و checkpointو SCN می باشد.هر هدر شامل یک شماره فایل مطلق و یک شماره فایل نسبی می باشد. شماره فایل مطلق منحصر به شناسایی دیتافایل در پایگاه داده می باشد. شماره فایل نسبی منحصر به شناسایی دیتا فایل در یک tablespace می باشد.
هنگامی که پایگاه داده ی اوراکل برای اولین بار یک دیتا فایل را ایجاد می کند،فضای دیسک اختصاص داده شده فرمت و قالب بندی می شود اما هیچ گونه داده ی کاربری را در بر نمی گیرد. با این حال پایگاه داده فضا را برای نگه داشتن داده برای سگمنت های آینده ی tablespace های مرتبط، رزرو می کند.از آنجایی که داده ها در tablespace رشد و افزایش می یابند، دیتابیس اوراکل فضای آزاد در دیتا فایل ها را برای اختصاص extent ها به سگمنت استفاده می کند. تصویر زیر انواع مختلف فضای یک دیتافایل را نشان می دهد .extent ها یا استفاده می شوند که بدین معنی است که حاوی داده های یک سگمنت بوده و یا آزاد هستند که این به معنی آن است که برای استفاده مجدد در دسترس می باشند:
مروری بر فایل های کنترلی
کنترل فایل یک فایل باینری کوچک است که ساختار فیزیکی یک دیتابیس را در خود ثبت کرده و نام و مکان redo log ها،time stamp ایجاد یک پایگاه داده و اطلاعات checkpoint ها و ... را شامل می شود. این فایل باینری کوچک تنها با یک پایگاه داده مرتبط است.هر دیتابیس تنها یک کنترل فایل منحصربفرد دارد، هر چند که از این کنترل فایل ها کپی هایی نیز می تواند موجود باشد.
استفاده از کنترل فایل ها
کنترل فایل یک فایل ریشه یا root است که دیتابیس اراکل عموما از آن برای پیدا کردن فایل های دیتابیس و مدیریت وضعیت دیتابیس، استفاده می کند.یک کنترل فایل اطلاعات عنوان شده در ذیل را در برمی گیرد:
- نام پایگاه داده و شناسه منحصربفرد پایگاه داده یا DBID
- زمان ایجاد بانک اطلاعاتی
- اطلاعاتی در مورد دیتا فایل ها و فایل های redo log آنلاین و فایل های آرشیو شده redo log
- اطلاعات مربوط به tablespace ها
- اطلاعات بکاپ های RMAN
کنترل فایل ها برای رسیدن به اهداف زیر ایجاد شده است : همانطور که پیشتر گفتیم این فایل ها حاوی اطلاعاتی درمورد دیتافایل ها،فایل های آنلاین redo log و ... که اینها باز کردن یک دیتابیس مورد نیازهستند. ساختار تغییرات دیتابیس را می توان در کنترل فایل دنبال کرد. برای مثال کنترل فایل ها این تغییرات را منعکس می کنند: وقتی یک ادمین اضافه می کنیم،تغییر نام ها و یا drop کردن یک دیتافایل یا یک فایل online redo log و به روزرسانی های پایگاه داده.
همچنین کنترل فایل دربردارنده ی متادیتایی است که باید زمانی که پایگاه داده باز نمی شود، در دسترس باشد. برای مثال کنترل فایل حاوی اطلاعات مورد نیاز برای بازیابی پایگاه داده، شامل checkpoint ها یا استگاههای بازرسی می باشد. برای اینکه ادامه ی توضیحات رابهتر درک کنیم ابتدا به توضیح مختصر مفهوم عبارت checkpoint و SCN می پردازیم .checkpoint ساختار داده ای است که موقعیت checkpoint ها و یا ایستگاه بازرسی یک checkpoint در واقع SCN را در جریان redo نشان می دهد، جایی که instance recovery برای شروع به آن نیاز داشته باشد.هر تغییر commit شده قبل از یک checkpoint SCN با ذخیره روی دیسک در دیتافایل ها، تضمین می شود.حداقل هر سه ثانیه یک بار پردازش checkpoint اطلاعات مربوط به محل و موقعیت checkpoint ها در کنترل فایل ها را روی redolog های آنلاین ثبت می کند(در انتهای مطلب استفاده از کنترل فایل ها به توضیح واضح مفاهیم SCNو Checkpiont می پردازیم).
Checkpoint ساختار داده ای است که "موقعیت checkpoint" تعیین شده توسط dirty buffer های قدیمی موجود در کش بافر دیتابیس را نشان می دهد (dirty بافرها، بافرهایی هستند که در حافظه تغییر یافته اما روی دیسک نوشته نشده اند). از نظر ساعت اوراکل موقعیت و مکان یک SCN روی Redo stream، در واقع جایی است که بازیابی instance باید آغاز شود. موقعیت یک checkpoint به عنوان یه اشاره گر روی redo stream عمل کرده و در کنترل فایل و در هر هدر دیتافایل ذخیره خواهد شد.
هر زمان که می گوییم یک checkpoint اتفاق افتاده، منظور ما این است که بافرهای پایگاه داده ی ویرایش شده موجود در کش بافر دیتابیس روی دیسک نوشته می شوند.یک checkpoint موفق تضمین می کند که تمامی تغییرات صورت گرفته تا checkpoint SCN در دیتافایل ها ثبت شده است. SCNهای ثبت شده در هدر فایل ها نیز ضمانت می کند که تمامی تغییرات بلوک های دیتابیس که قبل از SCN بوجود آمده اند روی دیسک نوشته شده اند. در نتیجه تنها تغییرات صورت گرفته پس از یک checkpoint نیازمند ریکاوری می باشند.
پایگاه داده ی اوراکل به طور مداوم قابلیت خواندن و نوشتن روی کنترل فایل را در طول استفاده از دیتابیس دارا می باشد و هر جایی که پایگاه داده باز است، باید برای نوشتن در دسترس باشد. به عنوان مثال بازیابی دیتابیس خواندن نام تمامی دیتافایل های موجود در پایگاه داده را از کنترل فایل ها را در بر می گیرد. همچنین این عملکرد برای انجام عملیات دیگر از قبیل اضافه کردن یک دیتافایل و به روز رسانی اطلاعات ذخیره شده در کنترل فایل حائز اهمیت است.
حال در انتهای این بخش از مقاله با مفاهیم مربوط به SCN و Checkpoint را برای درک بهتر مثال عنوان شده آشنا خواهیم شد :
SCN که مخفف عبارت System Change Number یا رقم تغییرسیستم می باشد. SCN یک شماره متغیر داخلی است که توسط سیستم مدیریت پایگاه داده یا DBMS، تغییرات ایجاد شده در دیتابیس را نگهداری می کند. به عبارتی SCN یک مقدار رو به افزایش منحصر بفرد است هر گاه که تراکنش commit شده ای در دیتابیس رخ دهد که وضعیت آن را تغییر دهد، اراکل یک SCN جدید ثبت کرده و تمام تغییرات رخ داده در طول زمان را نگهداری می کند.
بنابراین SCNمکانیزمی برای حفظ یکنواختی و انسجام داده ها در پایگاه داده اوراکل محسوب می شود.مثلا اگر یک جدول را که در دو دیتا فایل متفاوت ذخیره شده،آپدیت کنیم هدر دیتا فایل ها واطلاعات نوشته شده در کنترل فایل ها بعد از “commit’ آپدیت خواهند شد.قبل از باز کردن دیتابیس ابتدا بررسی می شود که هدر های کنترل فایل و دیتافایل SCN های مشابه داشته باشد. اگر این SCN ها با هم منطبق نبودند به این معنی است که دیتابیس احتیاج به ریکاوری دارد. بنابراین این عدد برای بازیابی دیتابیس حائز اهمیت می باشد.
تعریف checkpoint به زبان ساده بیانگر این مطلب است که checkpoint یک رویداد در پایگاه داده می باشد که بلوک های داده ی ویرایش شده درحافظه را با دیتا فایل های روی دیسک همزمان سازی می کند. این عملکرد به اوراکل وسیله ای برای حصول اطمینان از انسجام داده هایی که توسط تراکنش ها ویرایش می شوند را عرضه می کند. مکانیزم نوشتن بلوک های ویرایش شده روی دیسک در اوراکل با تراکنش های Commit شده ی مربوط هماهنگ نیست. یک checkpoint دو هدف را دنبال می کند اولین هدف ایجاد انسجام و ثبات داده ها و دومین آن سرعت بخشیدن به بازیابی دیتابیس می باشد.
یک checkpoint باید از اینکه تمامی بافرهای ویرایش شده ی موجود در کش بر روی دیتافایل های مربوطه نوشته شده اند،اطمینان حاصل کند برای جلوگیری از ازدست دادن داده ها که ممکن است به هنگام crash کردن (مثلا به هنگام خرابی دیسک یا instance) رخ دهد. از آنجایی که همه ی هدر های دیتا فایل ها در طول checkpoint در وضعیتی ثابت و بی حرکت باقی می مانند، بسته به تعداد دیتا فایل های موجود در دیتابیس یک checkpoint می تواند منبع عظیمی از عملیات فشرده باشد. وجود Checkpoint های پی در پی و مکرر عملیات بازیابی دیتابیس را سرعت می بخشند اما ممکن است موجب تخریب و تنزل عملکرد شوند.
کنترل فایل های چندگانه
پایگاه داده ی اوارکل قادر به ایجاد کنترل فایل های چندگانه و یکسان برای بازکردن و قابلیت نوشتن برای یک دیتابیس می باشد. بواسطه ایجاد کنترل فایل های چند گانه یا multiplexing یک کنترل فایل روی دیسک های مختلف، دیتابیس می تواند به redundancy دست یافته و در نتیجه از single point of failure اجتناب کند. اوراکل توصیه می کند که کپی هایی از کنترل فایل های چند گانه بر روی دیسک های مختلف در نظر بگیریم.
اگر یک کنترل فایل بلا استفاده شود، سپس instance یا نمونه پایگاه داده به هنگام تلاش برای دسترسی به کنترل فایل آسیب دیده، fail خواهد شد.وقتی که دیگر کپی های کنترل فایل فعلی موجود باشد،دیتابیس بدون انجام media recovery مجددا mount و باز خواهد شد. اگر تمامی کنترل فایل های پایگاه داده از بین بروند در این شرایط instance با شکست مواجه شده و نیازمند استفاده ازmedia recovery خواهد بود این عمل ساده نیست اگر که از یک بکاپ قدیمی از کنترل فایل استفاده کنیم چون کپی فعلی در دسترس نیست.
ساختار کنترل فایل ها
اطلاعات در مورد دیتابیس در سکشن های مختلفی از یک کنترل فایل ذخیره می شود.هر سکشن مجموعه ای از رکورد ها در مورد جنبه ای از پایگاه داده می باشد. برای مثال یک سکشن در کنترل فایل مرتبط با دیتا فایل ها بوده و مجموعه ای از رکوردها را که یکی برای هر دیتا فایل است، در برمی گیرد .هر سکشن در بلاک های چندگانه ی منطقی کنترل فایل ها ذخیره می شود.رکورد ها می توانند بلاک ها را در یک سکشن گسترش دهند. یک کنترل فایل انواع رکورد های زیر را شامل می شود:
- رکوردهای چرخشی با قابلیت استفاده مجدد:
این رکوردها حاوی اطلاعاتی هستند که حساس و یا بحرانی نیستند.این اطلاعات قابلیت overwrite یا رو نویسی را در صورت نیاز دارا می باشند. زمانی که تمامی اسلات های رکورد در دسترس کامل و یا پر شدند، دیتابیس همچنین کنترل فایل را برای ساخت یک room برای یک رکورد جدید گسترش داده و یا روی رکوردهای قدیمی رو نویسی می کند. مثال هایی از این کورد ها می تواند در مورد redo log فایل های آرشیو شده و بکاپ های RMAN باشد.
- رکوردهای غیر چرخشی فاقد قابلیت استفاده مجدد:
این رکوردها دربردارنده ی اطلاعات حساس می باشند که اغلب تغییر نمی کنند و قابلیت رونویسی برای آنها وجود ندارد. tablespace ها، دیتا فایل ها،redo log های آنلاین و نخ ها یا thread های redo نمونه ای از این اطلاعات حساس می باشند. دیتابیس اراکل از این رکورد ها هرگز استفاده مجدد نمی کند مگر اینکه اشیای مشابه از tablespace ها drop شوند.
خواندن و نوشتن بلاک های کنترل فایل متفاوت از خواندن و نوشتن بلاک های دیتا می باشد. برای کنترل فایل، دیتابیس اراکل خواندن و نوشتن را مستقیما از دیسک به PGA یا program global area انجام می دهد. هر پردازش مقدار مشخصی از حافظه ی PGA را برای بلاک های کنترل فایل اختصاص داده است.در این قسمت از مقاله ی ساختار فیزیکی ذخیره سازی بانک اطلاعاتی اوراکلبه توضیح دیتا فایل ها و فایل های کنترلی پرداختیم.در قسمت بعدی مقاله نیز به بررسی مفاهیم مربوط به redo file ها خواهیم پرداخت.