انتقال دیتابیس فایلها از محیط non-ASM به ASM

برای انتقال فایلهای دیتابیس(اعم از دیتافایل، کنترل فایل، redo log و …) از محیط non-ASM به محیط ASM روشهای مختلفی وجود دارد که در این قسمت سعی داریم این کار را با کمک ابزار RMAN انجام دهیم.

در ادامه متن، این کار با طی چند مرحله، انجام خواهد شد.

(بیشتر…)

cursor shring و bind variable

وقتی که اوراکل دستوری را اجرا می کند، سعی دارد تا فرم قابل اجرای دستور اجرا شده(که plan آن مشخص شده) را در library cache نگهدارد تا در صورت امکان، از آن استفاده مجدد کند حال اگر این فرم پارس شده برای دستور دیگری مورد استفاده قرار بگیرد می گویند یک soft parse انجام شده است و در صورتی که اوراکل مجبور شود یک فرم جدید قابل اجرا(که در library cache موجود نیست) برای دستور وارده بسازد، hard parse صورت گرفته است.

(بیشتر…)

enq: TM – contention

Enqueue ها کنترل دسترسی همزمان به یک شی واحد توسط چند نفر را بر عهده دارند تا به شی مورد نظر آسیبی وارد نشود و یکپارچگی آن حفظ شود پس از این نظر یک قابلیت مفید برای پیشبرد کار ما هستند ولی باید ساختار بانک اطلاعاتی طوری باشد که رقابت دو فرد برای دسترسی به یک شی به حداقل ممکن برسد تا wait هم کمتر رخ دهد. نمونه ای از waitای که بواسطه مدیریت Enqueue ایجاد می شود، enq: TM – contention می باشد که در اینجا سعی داریم تا علل رخ دادن آن و نحوه جلوگیری از آنرا به طور مختصر بیان کنیم.

(بیشتر…)

بازیابی کنترل‏ فایل با پکیج dbms_backup_restore

به صورت معمول در هنگام بازیابی بکاپ RMAN ، برای بازیابی کنترل فایل از روشهایی نظیر CONTROLFILE AUTOBACKUP  و recovery catalog استفاده می شود.

حال زمانی را فرض کنید که به هر دلیلی امکان استفاده از این روشها برای بازیابی کنترل فایل وجود نداردد(مخصوصا به خاطر خطا در زمان بکاپ گیری) در این حالت ممکن است استفاده از پکیج dbms_backup_restore کارساز باشد.

(بیشتر…)

Full Transportable Export/Import

قبلا در مطلبی نحوه ارتقا به اوراکل 12c از طریق ویژگی Transportable Tablespace را توضیح دادیم همانطور که در ان مطلب اشاره شد، ارتقا از طریق Transportable Tablespace زمانی روش مناسبی خواهد بود که اطلاعات کاربران در tablespaceهای غیرسیستمی موجود باشند.

در صورتی که حم قابل توجهی از اطلاعات کاربران در درون tablespaceهای سیستمی قرار موجود باشند، شاید به صرفه باشد این اطلاعات را به طور مستقیم به بانک جدید منتقل کنیم(بدون انتقال به user tablespaceها) برای این کار می توانیم از ویژگی Full Transportable Export/Import استفاده کنیم.

فرق اصلی این روش با روش قبلی(Transportable Tablespace) در استفاده از عبارت full=y transportable=always در هنگام تهیه دامپ می باشد که سبب خواهد شد تا اطلاعات کاربری موجود در tablespaceهای سیستمی از طریق EXPDP، همراه اطلاعات متادیتا در دامپ ذخیره شوند.

(بیشتر…)

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

زمانی که یک بانک اطلاعاتی به محیط 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 ارتقا دهیم.

(بیشتر…)