قابلیت Automatic In-Memory در اوراکل 18c

نویسنده مطلب: Vahid Yousefzadeh Leave a comment

قبلا در مطلب “ADO و مدیریت in-memory” بیان شد که چگونه می توان در سطوح مختلف(SET INMEMORY، MODIFY INMEMORY و NO INMEMORY) پالیسیهایی را به objectهایی که خصیصه inmmory برای انها فعال  شده است، اضافه کرد.

این پالیسها سبب می شد تا پس از گذشت مدتی زمانی از ایجاد، آخرین اصلاح و یا آخرین زمان دسترسی، خصیصه inememory برای objectای تنظیم یا حذف شود و یا آنکه سطح فشرده سازی شی در inememory تغییر کند. این قابلیت(“مدیریت in-memory از طریق ADO“) در اوراکل 12cR2 ارائه شده بود.

در نسخه 18c، اوراکل بهبود دیگری را در این زمینه ایجاد کرد. به این صورت که اگر قصد بارگذاری شی جدیدی را در inmemory داشته باشیم ولی فضای inmemory برای این کار کافی نباشد، اوراکل می تواند با کمک قابلیت  Automatic In-Memory که به اختصار، AIM هم شناخته می شود، objectهای که کمتر به آنها رجوع شده را از طریق آمارها شناسایی کند(نیازی به فعال کردن Heat Map نخواهد بود) و آنها را از inmemory خارج کند تا بتواند شی جدید را در inmemory قرار دهد البته با این شرط که شی جدید، بسیار پر استفاده باشد.

(بیشتر…)

ابزارهای گرافیکی برای کار با دیتابیس اوراکل

نویسنده مطلب: میلاد خالقی 5 Comments

زمانی که برخی از بانک های اطلاعاتی مانند SQL SERVER را نصب می کنیم، همراه با دیتابیس یک ابزار گرافیکی مناسب نصب می شود که می توانیم با استفاده از آن به بانک اطلاعاتی مقصد متصل شویم و دستورات مختلف را اجرا کنیم. اما در پکیج نصب دیتابیس اوراکل ابزار گرافیکی مناسب وجود ندارد و باید به صورت مجزا این ابزار را تهیه و نصب کنیم. علاوه بر مدیران دیتابیس، برنامه نویسان و توسعه دهندگان هم نیازمند یک ابزار گرافیکی جهت پیش برد پروژه های خود هستند.

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

(بیشتر…)

نگاهی به استثنائاتی در مورد پارامترهای PGA

نویسنده مطلب: Vahid Yousefzadeh Leave a comment

در مطلب “بررسی پارامترهای PGA” با پارامترهایی آشنا شدیم که قرار است محدودیتی را برای مصرف PGA در سطح پروسس و یا instance ایجاد کنند. در این مطلب خواهیم دید که در بعضی از شرایط مقدار در نظر گرفته شده برای پارامترهای pga_max_size، pga_aggrigate_target_ و حتی پارامتر PGA_AGGREGATE_LIMIT، نمی تواند PGA مصرف شده توسط پروسسها را محدود کند و پروسسها تا جایی که سرور و محدودیتهای سیستم عاملی اجازه می دهد، از RAM و SWAP استفاده می کنند.

به عنوان نمونه، مطابق با داکیومنتهای اوراکل، حداکثر PGA مورد استفاده یک پروسس توسط پارامتر مخفی pga_max_size_ کنترل می شود و علاوه بر این پارامتر، مقدار PGA استفاده شده برای یک پروسس به تنهایی نمی تواند بزرگتر از مقدار تنظیم شده برای پارامتر pga_aggrigate_target  باشد.

(بیشتر…)

چرا Huge Page؟

نویسنده مطلب: Vahid Yousefzadeh 4 Comments

مدیریت حافظه در سیستم عامل مبحث نسبتا پیچیده و گسترده ای است که ما در این نوشته قصد ورود به جزییات آن را نداریم ولی برای پاسخ دادن به سوال مطرح شده (“چرا Huge Page؟”)، به ناچار باید با اصطلاحاتی چون Page، Page Table، Page Table Entry و TLB آشنا باشیم، از اینرو، در ابتدای این متن، بعضی از مباحث مقدماتی مدیریت حافظه را مرور می کنیم.

در بیشتر پلتفرمها، فضای حافظه به قسمتهای هم اندازه که اصطلاحا Page نام دارد، تقسیم می شود اندازه صفحات در حالت پیش فرض، برابر با 4k می باشد.

مثلا اگر میزان فضای RAM اختصاص داده شده به سروری برابر با 1MB باشد، تعداد صفحات آن برابر با 256 خواهد بود و به همین شکل حافظه یک گیگابایتی به 256000 صفحه و حافظه 128GB حدودا به 32 میلیون صفحه خواهد رسید.

(بیشتر…)

پیکربندی Huge Page برای دیتابیس اوراکل

نویسنده مطلب: Vahid Yousefzadeh 1 Comment

در مطلب “چرا Huge Page” در مورد مزایا و دلایل استفاده از Huge Page مطالبی را ارائه کردیم در این مطلب قصد داریم نکاتی را در مورد Huge Page برای دیتابیس اوراکل ارائه کنیم.

همانند دیتابیس پستگرس، دیتابیس اوراکل هم در صورت پیکربندی Huge Page در محیط سیستم عامل، به صورت خودکار و در زمان استارت شدن instance، برای فضای shared memory از Huge Page استفاده خواهد کرد.

اوراکل برای کنترل استفاده و یا عدم استفاده از Huge Page، پارامتر USE_LARGE_PAGES را ارائه کرده که در همین ابتدای متن، توضیحاتی را در مورد این پارامتر ارائه می کنیم.

(بیشتر…)

پیکربندی Huge Page برای دیتابیس پستگرس

نویسنده مطلب: Vahid Yousefzadeh Leave a comment

در مطلب “چرا Huge Page” در مورد چرایی و مزیتهای استفاده از Huge Page مطالبی را ارائه کردیم. در این مطلب قصد داریم مطالبی را در مورد نحوه پیکربندی Huge Page برای دیتابیس پستگرس ارائه کنیم.

دیتابیس پستگرس هم همانند دیگر دیتابیسها از Huge Page پشتیبانی می کند و امکان استفاده از این قابلیت در محیط لینوکس از نسخه 9 و 10 وجود دارد و در نسخه 11، پستگرس، علاوه بر محیط لینوکس، Huge Page را در محیط ویندوز هم ساپورت می کند.

(بیشتر…)

تفاوتهای Transparent Huge Page با standard Huge Page

نویسنده مطلب: Vahid Yousefzadeh 2 Comments

Transparent Huge Page سعی می کند بصورت خودکار و با کمترین مداخله ادمین سیستم عامل وهمچنین صرف نظر از applicationای که در سرور در حال اجرا است، Huge Page را مدیریت کند.

این ویژگی(THP) برخلاف standard Huge Page به صورت پیش فرض در بسیاری از توزیع های لینوکس فعال است.

(بیشتر…)

نکاتی در مورد جدول dual و فراخوانی توابع در اوراکل و پستگرس

نویسنده مطلب: Vahid Yousefzadeh 2 Comments

در دیتابیس پستگرس، در زمان فراخوانی توابع به همراه دستور select الزامی به استفاده از کلمه کلیدی from نخواهد بود و انجام این کار، به اشکال زیر قابل انجام است:

شکل اول:

select function_name

شکل دوم:

Select * from function_name

شکل سوم:

select function_name from [table_name,view, …]

(بیشتر…)

بهبودهای DBMS_SCHEDULER در اوراکل 12c

نویسنده مطلب: Vahid Yousefzadeh 2 Comments

زمانی که  DBMS_SCHEDULER در اوراکل 10g ارائه شد، تنها سه نوع جاب PLSQL_BLOCK، STORED_PROCEDURE و EXECUTABLE را پشتیانی می کرد در اوراکل 11g هم تغییر قابل توجهی در این مسئله رخ نداد تا اینکه در نسخه 12c اوراکل job_typeهای جدیدی را به این مجموعه اضافه کرد تا تنظیم بعضی از جابها به شکل ساده تر و با وابستگی کمتری به محیط سیستم عامل قابل انجام باشد:

 SHELL_SCRIPT – SQL_SCRIPT –  BACKUP_SCRIPT

در این متن با هر کدام از این نوع جابها آشنا خواهیم شد.

(بیشتر…)

rollback کردن عملیات REDEFINITION(اوراکل 12c)

نویسنده مطلب: Vahid Yousefzadeh 1 Comment

زمانی را تصور کنید که ساختار جدول حجیمی را با کمک بسته DBMS_REDEFINITION تغییر داده ایم. بعد از اتمام عملیات redefinition، به این نتیجه رسیده ایم که تغییر انجام شده، سبب کندی در عملیاتی که بر روی این جدول انجام می شوند، شده است. قصد داریم جدول را به ساختار پارتشن نشده قبل برگردانیم، راهکار چیست؟

یکی از بهبودهایی که در نسخه 12c به بسته DBMS_REDEFINITION اضافه شد، قابلیت rollback کردن عملیات انجام شده می باشد این کار به کمک پارامتر enable_rollback از بسته DBMS_REDEFINITION قابل انجام است.

(بیشتر…)