زمانی که یک بانک اطلاعاتی به محیط rac منتقل می شود، ممکن است نتوان از همان ابتدا تعداد نودهای مورد نیاز برای این بانک را به خوبی تشخیص داد به همین دلیل شاید در آینده لازم باشد تا نودی از نودهای فعلی را حذف کرد تا در هزینه صرفه جویی شود و یا اینکه تعداد نودها را بالا برد تا بتوان از مزایای آن برای سیستم استفاده کرد.
ارتقا به 12c به روش Transportable Tablespace
همانطور که می دانید با ایجاد دیتابیس اوراکل، تعدادی از tablespaceها به صورت پیش فرض ایجاد می شوند که بعضی از انها اطلاعات سیستمی را در خود نگه می دارند نظیر SYSTEM، SYSAUX(به این نوع از tablespaceها در این متن admin tablespace می گوییم) علاوه بر این نوع از tablespaceها، tablespaceهای دیگری را هم میتوان برای نگهداری دیتای کاربران ایجاد کرد که به آنها، user tablespace گفته می شود.
در صورتی که همه اطلاعات کاربران در user tablespaceها قرار داشته باشند، الزامی برای ارتقا admin tablespaceها نخواهیم داشت و تنها می توانیم tablespaceهایی که اطلاعات کاربر در آنها موجود هست را به نسخه جدید ارتقا دهیم.
همچنین در صورتی که اطلاعات کاربر در admin tablespace قرار گرفته باشد، می توانیم ابتدا آنها را به user tablespace منتقل کرده و سپس این tablespaceها را به نسخه جدید ارتقا دهیم.
با توجه به ویژگی Transportable Tablespace این قابلیت وجود دارد که tablespaceها را به بانک جدیدی که نسخه اوراکل آن متفاوت است، منتقل کنیم.
در ادامه قصد داریم tablespaceهایی که اطلاعات کاربر در آنها قرار دارند را از طریق ویژگی Transportable Tablespace به اوراکل 12c ارتقا دهیم.
table reorganization
معمولا بعد از مدتی کار بر روی جداول و یا در پی اتفاقاتی خاص، ممکن است که نیاز شود تا جدولی خاص از یک tablespace و یا کل objectهای tablespace را دوباره سازماندهی کنیم tablespace reorganization معمولا به عنوان یک امر خطیر در حیطه وظایف dba محسوب می شود. آنچه که در این قسمت قصد داریم در مورد آن مطالبی را ارائه کنیم، دلایل نیاز به reorganization و چگونگی انجام آن می باشد.
تاثیر log strand بر اندازه آرشیولاگ
از اوراکل نسخه 9i به بعد این امکان وجود دارد تا log buffer به چند قسمت مساوی تقسیم شود و هر قسمتآن به قسمتی از redo log مپ شود و به این طریق انتفال اطلاعات صورت گیرد به این ویژگی public redo strand می گویند.
بررسی Block Corruption در اوراکل
خرابی بلاکهای دیتابیس که block corruption خوانده می شود، برای اکثر dbaها آشناست. این خطا که ممکن است سبب از دست رفتن دیتا شود معمولا به دلایل سخت افزاری و یا سیستم عاملی رخ می دهد و در صورت نداشتن backup سالم از بلاکهای خراب شده، به ناچار باید از اطلاعات ذخیره شده در آن قسمت، صرف نظر کنیم.
RMAN در محیط RAC
در هنگام بکاپ گیری با RMAN در محیط RAC، می توان CHANNELها را طوری تنظیم کرد که بار ناشی از عملیات بکاپ گیری، بر روی instanceهای مختلف، توزیع شود. در ادامه این متن، به شیوه انجام این کار، خواهیم پرداخت. (بیشتر…)
بازیابی سریع datafile با کمک file descriptor لینوکس
در صورت حذف اتفاقی datafile از روی سیستم عامل لینوکس، می توانیم با طی مراحلی، datafile حذف شده را برگردانیم(البته با اقدام فوری).البته این کار تا زمانی که بانک اطلاعاتی کماکان در حال اجرا باشد، قابل انجام است در غیر این صورت، لینکی که file descriptor به آن اشاره می کند، برای همیشه حذف خواهد شد.
ارتقا به اوراکل 12c از طریق dbua
در این روش نیاز است تا هر دو نسخه اوراکل(11g و 12c) به طور همزمان بر روی سرور نصب شده باشند.در صورتی که در حین اجرای DBUA، خطایی رخ دهد یا اجرای آن توسط dba کنسل شود، باید مراحل ارتقا را با دستورات cmd ادامه دهیم به عبارت دیگر این روش، restartable نیست.
Cluster File System
همانطور که می دانید در محیط RAC، همه database fileها(از قبیل datafileها، کنترل فایلها و redo log fileها) و فایلهای voting disk و OCR باید در یک فضای مشترک بین نودها قرار بگیرند به همین دلیل در زمان راه اندازی RAC نوع سیستم فایل فضای مورد استفاده بین نودها، باید طوری انتخاب شود تا بتواند امکان sharing را به وجود آورد در حال حاضر سیستم فایلهای مختلفی وجود دارند تا این امکان را فراهم کنند البته مزیت بعضی از آنها، به وضوح بیشتر است برای مثال سیستم فایلی که امروزه اوراکل در مستنداتش به استفاده از آن تاکید دارد، ASM و ACFS می باشد. بعضی از سیستم فایلهایی که این قابلیت را فراهم می کنند، به این اسم هستند:
enq: TX – row lock contention
این نوع wait معمولا زمانی که چند نفر بخواهند به صورت همزمان یک رکورد را تغییر دهند، اتفاق می افتد. و برای کم رنگ کردن آن باید برنامه را طوری تغییر داد تا کاربر زودتر مجبور به rollback یا commit شود.