مریم حیات رمضانی
کارشناس شبکه های مایکروسافت و پایگاه داده

ساختار فیزیکی ذخیره سازی در اوراکل ( Oracle ) چگونه است؟

ساختار فیزیکی ذخیره سازی داده ها در بانک اطلاعاتی اوراکل چگونه است؟ یکی از ویژگی های یک 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 ها، دیتافایل ها و سگمنت ها را نمایش می دهد:

تصویر شماره 1- توضیح Datafile ها و 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 ها یا استفاده می شوند که بدین معنی است که حاوی داده های یک سگمنت بوده و یا آزاد هستند که این به معنی آن است که برای استفاده مجدد در دسترس می باشند:

تصویر شماره2- انواع فضای دیتا فایل

مروری بر فایل های کنترلی

کنترل فایل یک فایل باینری کوچک است که ساختار فیزیکی یک دیتابیس را در خود ثبت کرده و نام و مکان 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 ها خواهیم پرداخت.

در قسمت اول مقاله ی ساختار فیزیکی ذخیره سازی در بانک اطلاعاتی به بررسی مفاهیم مرتبط با data file ها و control file ها پرداختیم حال در این بخش مفاهیم مرتبط با redo file ها را عنوان می کنیم:

مروری بر Online Redo Log ها

مهمترین ساختار برای بازیابی داده ها، Online redo log می باشد. که در بردارنده ی دو یا چند فایل از قبل اختصاص داده شده است که به محض وقوع تغییرات،آنها را ذخیره می کنند. online redo log تغییرات را در دیتا فایل ها ثبت می کند.

استفاده از Online Redo Log

Online Redo Log File ها پایگاه داده را در برابر از دست رفتن داده ها محافظت می کنند. به طور ویژه بعد از failure instance که خاتمه ی یک instance از دیتابیس به دلیل مشکل سخت افزاری ، خطاهای داخلی اوراکل و یا SHUTDOWN ABORT می باشد، در واقع online redo log file ها قادر به بازیابی داده های commit شده ای هستند که هنوز در دیتا فایل نوشته نشده اند.

پایگاه داده ی اوراکل هر تراکنشی را به طور همزمان در بافر redo log می نویسد که پس از آن درonline redo log ها ثبت می شوند.محتوای این log ها تراکنش های commit نشده، داده های undoو شماها و اشیای قطعنامه های مدیریتی را شامل می شود.پایگاه داده ی اوراکل از online redo log فقط برای ریکاوری استفاده می کند. با این حال مدیران پایگاه داده می توانند از online redo log file در رابط SQL با استفاده از ابزاری به نام LogMiner اوراکل،کوئری بگیریند. Redo log file ها یک منابعی مفید از پیشینه ی اطلاعات فعالیت های دیتابیس محسوب می شوند.

اوراکل دیتابیس چگونه اطلاعات را روی Online Redo Log ها می نویسد

Online redo log برای یک instance از دیتابیس،redo thread نامیده می شود. در پیکربندی single-instance، تنها یک instance دسترسی به یک دیتابیس را دارد بنابراین فقط یک redo thread موجود است. در پیکربندی Oracle Real Application Clusters که به صورت مخفف به آن Oracle RAC می گویند با اینکه دو یا تعداد بیشتری از instance ها به صورت همزمان به یک دیتابیس دسترسی دارند، هر instance در واقع redo thread خودش را دارا می باشد. یک redo thread مجزا برای هر instance از رقابت برای یک مجموعه واحد از online redo log file ها جلوگیری می کند.

Oracle RAC امکان کلاستر کردن دیتابیس های اوراکل را برای ما میسر می سازد.Oracle RAC از نرم افزار Oracle clusterware برای زیرساخت اتصال سرور های متعدد استفاده می کند به طوری که آنها به عنوان یک سیستم واحد عمل می کنند.یک Online redo log دو یا تعداد بیشتری از فایل های Online redo log را شامل می شود. دیتابیس اوراکل حداقل به دو فایل نیاز دارد برای تضمین اینکه یکی از فایل ها همیشه برای در دسترس باشد، در حالیکه دیگری آرشیو شده است (این مطلب در صورتی صادق است که دیتابیس در وضعیت ARCHIVE LOG قرار داشته باشد) .

سویچ های Online Redo Log

با توجه به اینکه ترجمه برخی از عبارت ها مفهوم دقیق و قابل درکی را نمی رساند قبل از پرداختن به توضیحات این بخش بهتر این است که برای راحت تر درک کردن مفاهیم به توضیح برخی از کلماتی بپردازیم که در این مقاله ترجمه نخواهند شد چرا که ترجمه این کلمات مفهوم دقیقی را بیان نمی کند و باید با مفهوم کاری این عبارت آشنا شویم و ترجمه این عبارت ها کمکی به ما نخواهد کرد:

  • Process: مکانیزمی در سیستم عامل است که می تواند یک سری از مراحل را اجرا کند. این پردازش با تقسیم کار دیتابیس اوراکل و نرم افزارهای کاربردی اوراکل به پردازش های متعدد، چندین کاربر و نرم افزار های کاربردی می توانند به طور همزمان با یک Instance واحد از دیتابیس، ازتباط برقرار کنند. که شامل سه بخش Background process یا پردازش های پشت صحنه، Oracle process یا پردازش های اوراکل و client process یا پردازش های کاربر می شود.
  • Background process: پایگاه داده ی اوراکل تنها یک online redo log file را در یک زمان برای ذخیره ی رکوردهای نوشته شده از بافر redo log، استفاده می کند. یک Online redo log file ای که پردازش های Log writer یا (LGWR) به طور فعال روی آن داده ها را می نویسد Online redo log file فعلی نامیده می شود.
  • Oracle process: پردازشی است که کدهای دیتابیس اوراکل را اجرا می کند. و Server process ها و background process ها را شامل می شود.
  • Client Process: پردازش های سطح کاربر پردازشی است که نرم افزار کاربردی یا ابزارهای کدنویسی اوراکل را اجرا می کند. وقتی کاربران از برنامه های سطح کاربر همچون sql*Plus را اجرا می کنند،سیستم عامل پردازش های کلاینت را برای اجرای نرم افزار ایجاد می کند.
  • Server process: یک پردازش اوراکل است که با پردازش های کاربر و دیتابیس اوراکل برای به انجام رساندن درخواست کاربر ارتباط برقرار می کند.sever processها با یک instance دیتابیس در ارتباط هستند اما بخشی از آن instance محسوب نمی شوند.
  • Instance: ترکیبی از system global areaیا SGA و background process ها می باشد. یک instance با یک و تنها یک دیتابیس در ارتباط است.در پیکربندی یک RAC یا کلاستر کردن برنامه های اوراکل چندین instance به طور همزمان با یک دیتابیس اوراکل در ارتباط هستند.
  • Log Writer یا LGWR: یک background process در برابر مدیریت بافر redo log و نوشتن بافر redo log روی Online redo log مسئول است. LGWR تمام ورودی های redo را که از آخرین زمانی که روی آن نوشته شده و در بافر کپی شده اند، را می نویسد.
  • Log switch:نقطه ای که LGWR نوشتن روی Active redo log فایل ها را متوقف کرده و روی Redo log file در دسترس بعدی سوییچ می کند. LGWR وقتی کهactive redo log file فعلی با redo رکوردها پر شود سوییچ کرده و یا یک سوییچ به صورت دستی را انجام می دهد.
  • Log sequence number: یک عدد است که به طور منحصر بفرد یک مجموعه ازredo record ها را در یک redo log file شناسایی می کند. وقتی که دیتابیس یک online redo log file پر می کند و روی دیگری سوییچ می کند، دیتابیس به صورت اتوماتیک به فایل جدید یک log sequence number تخصیص می دهد.
  • SGA یا System Global Area: یک گروه از ساختارهای حافظه ی به اشتراک گذاشته شده می باشد که داده ها و اطلاعات کنترلی را برای یکInstance از دیتابیس اراکل، شامل می شود.
  • Data blocks: کوچکترین واحد منطقی ذخیره سازی داده ها در پایگاه داده اوراکل می باشد. نام های دیگر در نظر گرفته شده برای آن بلاک های اوراکل و یا صفحات اوراکل می باشد.یک بلاک از داده با یک شماره خاص از بایت های فضای فیزیکی روی دیسک مرتبط می باشد.
  • Database buffer cache: بخشی از SGA است که کپی های بلوک های داده یا Data block ها را نگه می دارد تمامی پردازش های سطح کاربر به صورت همزمان با instance ای ارتباط برقرار می کنند که دسترسی به کش بافر را به اشتراک می گذارد.
  • Database writer یا DBW: یک background process است که که بافرها را در کش بافر دیتابیس یا همان Database buffer cache موجود در دیتا فایل ها می نویسد.

و اما بررسی سویچ های Online Redo Log

دیتابیس اوراکل در لحظه تنها از یک Online redo log file برای ذخیره ی رکوردهای نوشته شده از بافر redo log استفاده می کند. Online redo log فایلی که پردازش های LGWR برای نوشتن روی آن انجام می شود،Online redo log file فعلی نامیده می شود.یک Log switch زمانی اتفاق می افتد که دیتابیس نوشتن روی یک online redo log file را متوقف کرده و نوشتن روی دیگری را شروع می کند. عموما، یک سوییچ زمانی اتفاق می افتد که Online redo log file فعلی پر شده ولی عمل نوشتن می بایست ادامه پیدا کند.با این حال می توانیم پیکربندی را به گونه ای انجام دهیم که log switch در فواصل منظم زمانی رخ دهد بدون توجه به اینکه Online redo log file فعلی پر شده است و عمل log switch به صورت دستی اجباری می شود.

LGWR به صورت متناوب و چرخه ای عملیات نوشتن را رویOnline redo log file ها را انجام می دهد. وقتی که Log writer یا LGWR آخرین Redo log file در دسترس را پر می کند روند نوشتن به اولین log file برگشته و چرخه مجددا اجرا می شود. تصویر زیر روند چرخشی نوشتن روی Redo log را نمایش می دهد.

تصویر1- روند چرخشی نوشتن روی Redo log

اعداد موجود در تصویر بالا بیانگر ترتیب و سلسله مراتبی می باشد که LGWR عملیات نوشتن را روی هر Online redo log file انجام می دهد. دیتابیس به هر فایل یک log sequence number جدید را اختصاص می دهد زمانی که یک log switch انجام شده و LGWR عملیات نوشتن را روی فایل آغاز کند. وقتی که دیتابیس از یک Online redo log file مجددا استفاده می کند، این فایل log sequence number در دسترس بعدی را دریافت می کند.

Online redo log file های پر شده بسته به طریقه ی آرشیو شدن برای استفاده ی مجدد در دسترس خواهند بود:

  • اگر وضعیت آرشیو شدن غیر فعال باشد،بدین معنی است که پایگاه داده در وضعیت NOARCHIVELOG قرار داشته بنابراین یک Online redo log file پر شده بعد از آن که تغییرات ثبت شده روی آن توسط DBW روی دیسک نوشته شد، در دسترس خواهد بود.
  • اگر وضعیت آرشیو فعال باشد، دیتابیس در وضعیت ARCHIVELOG قرار خواهد داشت. بتابراین یک Online redo log file پر شده پس از آنکه تغییرات روی دیتا فایل ها نوشته و فایل آرشیو شد برای LGWR دسترس می باشد.

در برخی شرایط، log writer ممکن است از استفاده مجدد یک Online redo log file موجود جلوگیری کند.برای مثال یک online redo log file ممکن است فعال باشد (مثلا برای ریکاوری یک instance مورد نیاز است) به جای اینکه غیر فعال باشد (به عنوان مثال برای ریکاوری instance لازم نیست).همچنین ممکن است که Online redo log file در طی پردازش ،پاک شده باشد.

کپی های چندگانه از Online Redo Log File ها

دیتابیس اوراکل می تواند به طور خودکار دو یا تعداد بیشتری از کپی های یکسان از online redo log را در مکان های جداگانه نگهداری کند. یک گروه online redo log در واقع یک online redo log file وکپی های اضافی از آن را شامل می شود. هر کپی مشابه، یک عضو از گروه online redo log محسوب می شود.هر گروه به کمک یک شماره تعریف می شود مثلا گروه1 ، گروه2 و ... . نگهداری اعضای متعدد از یک گروه Online redo log آن را در برابر از دست دادن redo log محافظت می کند.به طور ایده آل مکان اعضا باید روی دیسک های مجزا باشد به طوری که شکست یک دیسک موجب از بین رفتن کل online redo log نشود.

تصویر زیر نحوه ی ایجاد کپی های متعدد از online redo log file ها را نمایش می دهد.در تصویر زیر ALOG1 و BLOG2 اعضای مشابه گروه 1 می باشند.در حالی که ALOG2 و BLOG2 اعضای یکسان گروه 2 هستند.هر عضو از یک گروه باید اندازه ی یکسان داشته باشند.LGWR به صورت همزمان عمل نوشتن را روی اعضای گروه 1 (ALOG1 و BLOG2 ) انجام می دهد سپس به همین ترتیب نوشتن را بر روی گروه دوم با اعضای ALOG2 و BLOG2 ادامه می دهد و مجددا بر روی گروه 1 می نویسد و ... . LGWR هرگزعمل نوشتن را به طور همزمان بر روی اعضای گروه های مختلف انجام نمی دهد.

تصویر2- نحوه ی ایجاد کپی های متعدد از online redo log file  ها

Redo Log File های آرشیو شده

یک Archived redo log file در واقع کپی یک عضو پر شده و نوشته شده از یک گروه online redo log می باشد.این فایل به عنوان بخشی از دیتابیس در نظر گرفته نمی شود،اما یک کپی آفلاین از یک Online Redo Log File ساخته شده به وسیله ی دیتابیس می باشد و در یک مکان مشخص شده توسط کاربر نوشته شده است.Redo log file های آرشیو شده بخش مهمی از استراتژی بکاپ و ریکاوری محسوب می شود. می توان در شرایط زیر از redo log file های آرشیو شده استفاده کرد:

  • بازیابی نسخه ی پشتیبان پایگاه داده
  • آپدیت کردن Standby Database (یک کپی مستقل از یک دیتابیس می باشد که می توان از آن به هنگام وقوع یک فاجعه در یک محیط با دسترسی سطح بالا استفاده کرد)
  • به دست آوردن اطلاعات در مورد سوابق یک پایگاه داده به کمک ابزار LogMiner.این ابزار امکان گرفتن کوئری از redo log file ها را به کمک رابط SQL برای ما فراهم می آورد.

عبارت Archiving یا آرشیو کردن در اصل عملیاتی است برای تولید یک redo log file آرشیو شده.عمل آرشیو کردن می تواند هم به صورت دستی و هم اتوماتیک انجام شده و تنها در زمانی ممکن است که دیتابیس در وضعیت ARCHIVELOG قرار داشته باشد.یک redo log file آرشیو شده یک redo نوشته شده و log sequence number یک عضو یکسان با گروه Online redo log را در بر می گیرد.در تصویر بالا فایل های ALOG1 و BLOG2 اعضای یکسان گروه 1 می باشند، اگر دیتابیس در وضعیت ARCHIVELOG قرار داشته باشد و آرشیو کردن به صورت خوردکار نیز فعال باشد، سپس روند آرشیو یا ARCn یکی از آن فایل ها را آرشیو خواهد کرد.اگر فایل ALOG1 خراب شود، سپس ARCn می تواند BLOG1 را بایگانی کند. یک کپی از redo log آرشیو شده هر گروه ساخته شده که قابلیت بایگانی را برای آن فعال کردیم ، شامل می شود.

ساختار یک Online Redo Log

Online redo log file در واقع Redo رکورد ها را در بر می گیرد. یک redo record ازیک گروه از change vector ها ساخته شده است.که هر کدام آنها تغییرات یک Data block را توصیف می کنند. برای مثال به روز رسانی حقوق و دستمزد در جدول کارمندان یک redo رکورد را می سازد که تغییرات بلاک data segment را برای جدول، undo segment data block و تراکنش های جدول یا transaction table برای undo segment ها را توصیف می کند. Redo رکوردها تمامی ابر داده را برای تغییر داراهستند، از جمله موارد زیر:

  • SCN و time stamp تغییرات
  • ID تراکنش برای تراکنشی که تغییرات ایجاد می کند
  • SCN و time stamp وقتی که تراکنش commit می شود
  • نوع عملیاتی که تغییرات را ممکن می سازد
  • نام و نوع data segment های ویرایش شده.

در این مقاله ی دو قسمتی به شرح مفاهیم مربوط به ساختار فیزیکی ذخیره سازی در بانک اطلاعاتی اوراکل پرداختیم چرا آگاهی از وقایع پشت صحنه ی هر برنامه ای که با آن کار می کنیم دید بهتری برای انجام کار به بهترین نحو ممکن در اختیار ما قرار می دهد امیدوارم برای دوستان مفید واقع شود.


مریم حیات رمضانی
مریم حیات رمضانی

کارشناس شبکه های مایکروسافت و پایگاه داده

کارشناس سیستم عامل و زیرساخت های مایکروسافت MCTS:Active Directory 2008 MCTS:Network Infrastruture 2008 MCTS:Application Infrastructure 2008 MCTS:Active Directory 2008 MCITP:Enterprise Administrator MCSA 2008

09 آبان 1394 این مطلب را ارسال کرده

نظرات