مراحل Relink کردن Grid Infrastructure در محیط Cluster

انجام عملیات Relink برای نرم افزار oracle نیاز به پیش نیاز خاصی ندارد و صرفا توصیه می شود که قبل از انجام relink، دیتابیس و سرویس listener را استاپ کنیم اما relink کردن برای Grid Infrastructure کمی متفاوت است که در این متن مراحل آن را برای محیط Cluster مشاهده می کنید.

توجه: این متن برای اوراکل نسخه 12cR2 به بعد قابل استفاده می باشد.

 

(بیشتر…)

اضافه کردن نود به RAC 18c

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

 [grid@RAC2 ~]$ olsnodes -s -t

RAC2 Active  Unpinned

RAC1 Active  Unpinned

RAC4 Active  Unpinned

[oracle@RAC2 ~]$ srvctl status database -d db18c

Instance db18c1 is running on node RAC2

Instance db18c3 is running on node RAC1

Instance db18c4 is running on node RAC4

همانطور که در خروجی دستور مشاهده می کنید، سه نود با نامهای RAC1,RAC2,RAC4 در کلاستر موجود هستند و قصد داریم نود RAC3 را به این مجموعه اضافه کنیم.

(بیشتر…)

حذف نود در محیط کلاستر(اوراکل 18c,19c)

در این متن قصد داریم نودی(RAC3) را از یک کلاستر چهار نوده حذف کنیم. خصوصیات کلاستر را در قسمت زیر مشاهده می کنید:

[grid@RAC3 ~]$ srvctl config database -d db18c

Type: RAC

Database instances: db18c1,db18c2,db18c3,db18c4

Configured nodes: RAC2,RAC3,RAC1,RAC4

[oracle@RAC3 ~]$ srvctl status database -d db18c

Instance db18c1 is running on node RAC2

Instance db18c2 is running on node RAC3

Instance db18c3 is running on node RAC1

Instance db18c4 is running on node RAC4

قبل از وارد شدن به مراحل حذف RAC3، مهمترین قدمهای حذف یک نود در محیط کلاستر را مرور می کنیم:

1.متوقف کردن سرویس(database و asm) و حذف آنها در نود مورد نظر

2.حذف نرم افزار اوراکل

3.حذف نرم افزار grid

4.بروزرسانی oraInventory

 

در ادامه با جزییات بیشتری و در طی پنج مرحله عملیات حذف نود را شرح خواهیم داد.

 

(بیشتر…)

برگشت خودکار سرویس به preferred instance در اوراکل 19c

همانطور که می دانید در محیط RAC و در زمان ایجاد یک سرویس، می توان preferred instance و available instance را مشخص کرد در این صورت، سرویس بصورت پیش فرض در preferred instance اجرا خواهد شد.

اگر به هر دلیلی preferred instance دچار مشکل شود و یا به صورت کلی، نود مربوط به آن، از دسترس خارج شود، سرویس هم به available instance منتقل خواهد شد و حتی با استارت مجدد preferred instance، اصطلاحا failbackای برای این سرویس رخ نخواهد داد و سرویس کماکان در همان available instance به کارش ادامه خواهد داد و برای انتقال ان به  preferred instance، باید به صورت دستی، عملیات relocate را انجام داد.

(بیشتر…)

ویژگی Multi Instance Redo Apply

در اوراکل 11g با پیاده سازی دیتاگارد به صورت کلاستر، تنها نودی که دستور alter database manage recover بر روی ان اجرا شده(برای اولین بار!)، مسئولیت اعمال کردن redoها را برعهده خواهد داشت و مابقی نودها می توانند برای گزارش گیری، تهیه بکاپ و یا دریافت redo (یا آرشیو) و… مورد استفاده قرار بگیرند.

در اوراکل 12cR2، بهبودی در این زمینه رخ داد که می توان با کمک آن، همه نودها را در recovery سهیم کرد. این قابلیت که (Multi Instance Redo Apply (MIRA نام دارد، امکان اعمال redoها را با کمک چند instance ممکن می سازد.

(بیشتر…)

RAC – Dynamic Remastering

در محیط RAC هر instance بخشی از GRD را در SGA خود جای می دهد و همانطور که می دانید GRD هم حاوی اطلاعاتی از قبیل data block address، SCN، past image، current image و … می باشد پس در نتیجه هر instance، اطلاعات مجموعه ای از بلاکها را کنترل می کند و master آنها می باشد و متقابلا هر بلاک هم یک نود مستر دارد به طوری که اگر مستر فعلی بلاک دچار مشکل شود، نود دیگری مسئولیت این بلاکها را به عنوان مستر بر عهده می گیرد.

(بیشتر…)

data pump و RAC

در محیط RAC، این امکان وجود دارد تا از چند instance برای اجرای data pump بهره گرفته شود. برای این کار باید شرایط زیر رعایت شود:

  1. دایرکتوری که فایل دامپ قرار است در آنجا قرار گیرد، در فضای مشترک بین نودها ایجاد شود.
  2. پارامتر cluster به y و پارامتر parallel به مقداری بیشتر از یک تنظیم شود.
  3. Logها در مسیر local مربوط به نودها ایجاد شوند.

(بیشتر…)

افزودن نود جدید در محیط rac

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

(بیشتر…)

Cluster File System

همانطور که می دانید در محیط RAC، همه database fileها(از قبیل datafileها، کنترل فایلها و redo log fileها) و فایلهای voting disk و OCR باید در یک فضای مشترک بین نودها قرار بگیرند به همین دلیل در زمان راه اندازی RAC نوع سیستم فایل فضای مورد استفاده بین نودها، باید طوری انتخاب شود تا بتواند امکان sharing را به وجود آورد در حال حاضر سیستم فایلهای مختلفی وجود دارند تا این امکان را فراهم کنند البته مزیت بعضی از آنها، به وضوح بیشتر است برای مثال سیستم فایلی که امروزه اوراکل در مستنداتش به استفاده از آن تاکید دارد، ASM و ACFS می باشد. بعضی از سیستم فایلهایی که این قابلیت را فراهم می کنند، به این اسم هستند:

(بیشتر…)