ساختار فیزیکی ذخیره سازی داده ها در بانک اطلاعاتی اوراکل چگونه است؟ یکی از ویژگی های یک 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 دائمی ، اشیای پایای یک Schema یا شما را در بر می گیرد. این Object ها و یا اشیا ِ یک tablespace دائم در دیتا فایل ها ذخیره می شوند. tablespace موقت نیز تنها اشیای یک Schema در طی یک session را نگهداری می کند. برای مدیریت tablespace های موقت به صورت لوکال فایل های موقت یا temp file هایی وجود دارد که فایل های خاص طراحی شده برای ذخیره ی داده در hash، مرتب کردن و عملیات دیگری از این قبیل می باشند. Temp فایل ها همچنین هنگامی که فضای کافی در حافظه موجود نباشد، نتیجه ی مجموعه ی داده ها را ذخیره می کنند. Temp فایل ها یا همان فایل های موقت مشابه فایل های دائمی می باشند البته به استثنا موارد زیر:
هر فایل داده یا همان دیتا فایل می تواند آنلاین( در دسترس ) و یا آفلاین (غیر قابل دسترسی) باشد.می توانیم دسترسی پذیری دیتا فایل های 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 است که دیتابیس اراکل عموما از آن برای پیدا کردن فایل های دیتابیس و مدیریت وضعیت دیتابیس، استفاده می کند.یک کنترل فایل اطلاعات عنوان شده در ذیل را در برمی گیرد:
کنترل فایل ها برای رسیدن به اهداف زیر ایجاد شده است : همانطور که پیشتر گفتیم این فایل ها حاوی اطلاعاتی درمورد دیتافایل ها،فایل های آنلاین 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 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 برای یک 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 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 را نمایش می دهد.
اعداد موجود در تصویر بالا بیانگر ترتیب و سلسله مراتبی می باشد که LGWR عملیات نوشتن را روی هر Online redo log file انجام می دهد. دیتابیس به هر فایل یک log sequence number جدید را اختصاص می دهد زمانی که یک log switch انجام شده و LGWR عملیات نوشتن را روی فایل آغاز کند. وقتی که دیتابیس از یک Online redo log file مجددا استفاده می کند، این فایل log sequence number در دسترس بعدی را دریافت می کند.
Online redo log file های پر شده بسته به طریقه ی آرشیو شدن برای استفاده ی مجدد در دسترس خواهند بود:
در برخی شرایط، log writer ممکن است از استفاده مجدد یک Online redo log file موجود جلوگیری کند.برای مثال یک online redo log file ممکن است فعال باشد (مثلا برای ریکاوری یک instance مورد نیاز است) به جای اینکه غیر فعال باشد (به عنوان مثال برای ریکاوری instance لازم نیست).همچنین ممکن است که 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 هرگزعمل نوشتن را به طور همزمان بر روی اعضای گروه های مختلف انجام نمی دهد.
یک Archived redo log file در واقع کپی یک عضو پر شده و نوشته شده از یک گروه online redo log می باشد.این فایل به عنوان بخشی از دیتابیس در نظر گرفته نمی شود،اما یک کپی آفلاین از یک Online Redo Log File ساخته شده به وسیله ی دیتابیس می باشد و در یک مکان مشخص شده توسط کاربر نوشته شده است.Redo log file های آرشیو شده بخش مهمی از استراتژی بکاپ و ریکاوری محسوب می شود. می توان در شرایط زیر از redo log file های آرشیو شده استفاده کرد:
عبارت 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 file در واقع Redo رکورد ها را در بر می گیرد. یک redo record ازیک گروه از change vector ها ساخته شده است.که هر کدام آنها تغییرات یک Data block را توصیف می کنند. برای مثال به روز رسانی حقوق و دستمزد در جدول کارمندان یک redo رکورد را می سازد که تغییرات بلاک data segment را برای جدول، undo segment data block و تراکنش های جدول یا transaction table برای undo segment ها را توصیف می کند. Redo رکوردها تمامی ابر داده را برای تغییر داراهستند، از جمله موارد زیر:
در این مقاله ی دو قسمتی به شرح مفاهیم مربوط به ساختار فیزیکی ذخیره سازی در بانک اطلاعاتی اوراکل پرداختیم چرا آگاهی از وقایع پشت صحنه ی هر برنامه ای که با آن کار می کنیم دید بهتری برای انجام کار به بهترین نحو ممکن در اختیار ما قرار می دهد امیدوارم برای دوستان مفید واقع شود.
کارشناس شبکه های مایکروسافت و پایگاه داده
کارشناس سیستم عامل و زیرساخت های مایکروسافت MCTS:Active Directory 2008 MCTS:Network Infrastruture 2008 MCTS:Application Infrastructure 2008 MCTS:Active Directory 2008 MCITP:Enterprise Administrator MCSA 2008
زمان پاسخ گویی روز های شنبه الی چهارشنبه ساعت 9 الی 18
فقط به موضوعات مربوط به محصولات آموزشی و فروش پاسخ داده می شود