FLEX ASM

با نصب کلاستر به صورت standard ASM(روش رایج در نسخه 11g)، هر نود شامل یک ASM instance و یک db instance خواهد بود که با افتادن ASM instance در یک نود، db instance موجود در ان نود هم به خطا برخواهد خورد و امکان استفاده از ASM instanceهای دیگر برای این db instance ممکن نخواهد بود به عبارت دیگر، هر db instance تنها به ASM instance موجود در سرورش متکی می باشد. در اوراکل 12c ویژگی ای ارائه شد که می تواند این نقصان را برطرف کند، این ویژگی FLEX ASM نام دارد و می توان به کمک ان، همه نودهای موجود در فضای کلاستر را تنها به اعتبار یک ASM instance سرپا نگه داشت البته این ویژگی مزیتهای دیگری هم به همراه دارد که به تعدادی از انها در این نوشتار خواهیم پرداخت.

(بیشتر…)

(Asm Utility(AMDU,KFED,KFOD

همانطور که می دانید، در هر asm disk علاوه بر داده های بانک اطلاعاتی، نوع دیگری از داده هم ذخیره می شود که فراداده مربوط به ان دیسک می باشد و این نوع از داده ها معمولا در قسمت ابتدایی دیسک و به عبارتی در بلاک صفر ذخیره می شوند و کپی ای از ان هم در بلاک 510 برای مسائل امنیتی ذخیره می شود(2088960 bytes / 4096 = 510) البته قسمتی از فراداده داده ذخیره شده در این بلاکها، مربوط به خود دیسک نمی باشد بلکه اطلاعاتی در مورد دیسک گروهی هست که دیسک عضو ان می باشد.

(بیشتر…)

ارسال فایل بین asm و non-asm

همانطور که می دانید برای مدیریت فایلهای موجود در محیط asm نمی توان از دستورات سیستم عاملی استفاده کرد(البته در محیط acfs که بر روی asm پیاده می شود، این نقصان برطرف شده است) برای مثال نمی توان با دستوراتی چون cp ،mv و… در سطح لینوکس، بر روی فایلهای موجود در فضای asm اعمال مدیریت کرد. در صورتی که ممکن است برای یک مدیر بانک اطلاعاتی، انجام چنین کاری بسیار ضروری باشد(انتقال فایل به محیط بیرون، اصلاح و ….). روشهای دیگری در این زمینه وجود دارند که انجام این عملیات ها را ممکن می کنند.

(بیشتر…)

آشنایی و مدیریت JOBها

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

(بیشتر…)

همروندی در اوراکل

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

(بیشتر…)

Oracle Lock Management

زمانی که در یک بانک اطلاعاتی کاربران متعددی مشغول خواندن و نوشتن هستند، ممکن است دو کاربر به صورت همزمان قصد اصلاح یک شی را داشته باشند، و بطور بدیهی در صورت عدم کنترل این دسترسی، ممکن است داده ای از بین رفته و یا داده های ان شی ناسازگار شوند. برای مدیریت و کنترل این دسترسی همزمان، اوراکل از مکانیزمی به نام lock استفاده می کند.

(بیشتر…)

ویژگی های جدید اوراکل در نسخه 12c

بانک اطلاعاتی اوراکل با هر نسخه جدیدی که ارائه می کند معمولا بسیاری باگهای ایجاد شده در نسخه های قبلی را رفع و همراه با آن ویژگی های جدیدی را هم عرضه می کند به همین منوال، در نسخه 12c، بیش از 500 ویژگی جدید را ارائه کرده است که در این مقاله سعی داریم تا بعضی از این ویژگی ها را مورد بررسی قرار دهیم البته از مهمترین ویژگی این نسخه، Pluggable Database می باشد که در مقاله دیگری در مورد ان مطالبی آورده شد و در این مقاله به این ویژگی مهم نخواهیم پرداخت(مقاله مذکور در سایت www.usefzadeh.com موجود می باشد).

(بیشتر…)

MATERIALIZED VIEW

همانطور که می دانید ویو(view) ذخیره پرس و جو در بانک اطلاعاتی به یک اسم خاص می باشد که عمده  کاربرد آن در امنیت و استقلال منظقی داده ها می باشد ویوها هیچ فضایی را برای ذخیره داده مصرف نمی کنند و با هر بار اجرا، پرس وجو را هم اجرا می کنند. همانند ویو، شی دیگری نیز وجود دارد که شامل یک پروس و جو می باشد که برخلاف ویو، خروجی پرس و جو را هم در جایی ذخیره می کند و در مواقع ضروری می توان آن را بروز کرد این شی Materialized View نام دارد. (بیشتر…)

PLUGGABLE DATABASE

همانطور که می دانید تا قبل از اوراکل 12c، این امکان وجود داشت تا اطلاعات هر کاربر به صورت فیزیکی مستقل از دیگر کاربران ذخیره شود و نیز از نظر امنیتی این اطلاعات دور از دسترس دیگر کاربران قرار بگیرد و در صورت لزوم این قابلیت وجود داشت تا اطلاعات کاربر به بانک اطلاعاتی دیگری منتقل شود و از بانک جاری حذف شود به طور مثال ممکن بود از طریق Transportable Tablespace ، tablespace مربوط به کاربر را در صورت عدم وابستگی به دیگر tablespaceها، به بانک دیگری منتقل کرد ولی در عین حال ساختار موجود در نسخه های قبلی بسیار مستعد اختلاط بود و همه کاربران به یک data dictionary واحد وابسته بودند و همچنین انتقال بخشی از اطلاعات به بانک دیگر، با محدودیتهایی مواجه بود.

(بیشتر…)