مروری بر ویژگی IM Expressions

اوراکل از نسخه 12cR2 قابلیت expression tracking را ارائه کرد که بر اساس آن، توابع(اعم از سیستمی و pl/sqlای)، عملگرهای محاسباتی و بصورت کلی عبارتهای استفاده شده در متن پرس و جو ها در دیتابیس ذخیره می شوند مسئولیت این کار بر عهده optimizer است و optimizer در زمان انجام عملیات hard pars، این عبارات را در مخزنی بنام (Expression Statistics Store(ESS قرار می دهد که از طریق ویوی دیتا دیکشنری DBA_EXPRESSION_STATISTICS می توان لیستی از این عبارتها را مشاهده کرد.

(بیشتر…)

ویژگی In-Memory FastStart در اوراکل 12cR2

یکی از چالشهای قابلیت in-memory در نسخه 12cR1 به هزینه بر بودن load اولیه اطلاعات(در in-memory) بعد از restart شدن دیتابیس برمی گردد چرا که اطلاعات در دیسک به صورت row format ذخیره شده و در زمان بارگذاری باید به فرمت ستونی و (عمدتا) به شکل فشرده در حافظه(in-memory) قرار بگیرند که این کار می تواند مصرف بالای منابع(مخصوصا cpu) را به همراه داشته باشد.

اوراکل در نسخه 12cR2، برای حل این مسئله، قابلیت جدیدی به نام In-Memory FastStart را ارائه کرد که بر اساس آن، اطلاعات موجود در in-memory با همان فرمتی که در حافظه قرار دارند، در دیسک و در یک tablespace مجزا ذخیره می شوند.

(بیشتر…)

بررسی پارامترهای رسمی و مخفی مربوط به PGA

همانطور که می دانید PGA متشکل از قسمتهای مختلفی می باشد که میزان استفاده هر پروسس از هر کدام از این قسمتها را می توان با کمک پارامترهای نظیر sort_area_size، hash_area_size، bitmap_merge_area_size و… کنترل کرد.

با این حال از اوراکل 9i، پارامتر دیگری به نام PGA_AGGREGATE_TARGET اضافه شد که با مقداردهی آن، اندازه هر یک از قسمتهای PGA توسط خود اوراکل مدیریت می شود.

اوراکل تلاش می کند مجموع فضای PGA تخصیص داده شده(pga1+pga2+pga3+…) به پروسسها را به مقدار در نظر گرفته شده برای پارامتر PGA_AGGREGATE_TARGET محدود کند اما در مواقعی، به خصوص در زمان بالا رفتن بارکاری سیستم و یا پایین بودن مقدار پارامتر PGA_AGGREGATE_TARGET، ممکن است مجموع فضای PGA تخصیص داده شده، از مقدار تنظیم شده برای این پارامتر بیشتر شود.

از این رو، مقدار تعیین شده برای پارامتر PGA_AGGREGATE_TARGET صرفا به عنوان یک soft limit در نظر گرفته خواهد شد و حتی در شرایطی ممکن است فضای PGA تخصیص داده شده به یک پروسس، از مقدار تنظیم شده برای این پارامتر تجاوز کند!(مطلب “نگاهی به استثنائاتی در مورد پارامترهای PGA” را مطالعه کنید)

(بیشتر…)

پیدا کردن مقادیر متناظر bind variableها برای یک sql_id مشخص

قبلا در مقاله ای در مورد cursor sharing و bind variable مطالبی را ارائه کردیم و فواید و مخاطرات استفاده از bind variable را توضیح دادیم.

همانطور که در آن مطلب اشاره شد، زمانی که پارامتر cursor_sharing به مقدار exact تنظیم شده و در کنار آن از bind variable هم استفاده نشده باشد، با کمترین تغییر در متن دستور(به طور مثال تغییر مقدار id از 10 به 11)، برای اجرای بعدی آن، نیاز به پارس مجدد خواهیم داشت. این مسئله می تواند کندی اجرای دستور و یا حتی در مواردی کندی کلی دیتابیس را به همراه داشته باشد.
برای مثال، در شرایط گفته شده، با اجرای متوالی دو دستور زیر، دو بار عملیات پارس انجام خواهد شد:

delete mytbl where file#=1 and ts#=0;

delete mytbl where file#=1 and ts#=2;

در صورتی که با تبدیل آن به فرم زیر، دستورات با یک بار پارس شدن اجرا می شوند:

delete mytbl where file#=:B1 and ts#=:B2;

(بیشتر…)

چرا Huge Page؟

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

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

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

(بیشتر…)

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

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

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

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

(بیشتر…)

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

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

شکل اول:

select function_name

شکل دوم:

Select * from function_name

شکل سوم:

select function_name from [table_name,view, …]

(بیشتر…)

اوراکل 12c-بهبودهایی در زمینه جمع آوری آمار Global Temporary Table

تا قبل از اوراکل 12c، رفتار اوراکل در زمان جمع آوری آمار برای جداول از نوع (global temporary table(GTT تفاوتی با جداول معمولی نداشت و این مسئله می توانست در مواردی چالش برانگیز باشد.

در اوراکل 12c بهبودهایی در این زمینه حاصل شد که در ادامه دو مورد از این بهبودها را مشاهده می کنید.

(بیشتر…)

بررسی enq: TX – allocate ITL entry به همراه یک سناریو

دیتابیس اوراکل برای پیاده سازی مفاهیمی چون Data Concurrency و Read Consistency، مشخصات تراکنشها را در قسمتی از هدر بلاک ثبت می کند. این قسمت از هدر بلاک که به آن (Interested Transaction List(ITL هم گفته می شود، می تواند شامل تعدادی slot باشد.

تراکنشها برای تصاحب یک رکورد، باید slotای را در هدر بلاکی که رکورد در آن قرار دارد، در اختیار بگیرند و اطلاعاتی نظیر (transaction ID(XID و (undo block address(UBA و همچنین تعداد رکوردهایی که تراکنش در این بلاک قفل کرده را در این قسمت ثبت کنند البته هر slot صرفا به یک transaction تعلق دارد و هر transaction در هر بلاک، تنها می تواند یک slot را اشغال کند.

با انجام commit و rollback و متعاقب آن، پایان یافتن تراکنش، itl slot می تواند توسط تراکنش دیگری استفاده شود.

(بیشتر…)

اوراکل 12c – بهبودی در جمع آوری آمار به صورت Incremental برای جداول پارتیشن شده

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

در این صورت با هر بار اجرای بسته dbms_stat، از همه پارتیشنهای این جدول، مجددا امار جمع اوری خواهد شد حتی پارتیشنهایی که اطلاعات ان بروزرسانی نشده است.

(بیشتر…)