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

نویسنده مطلب: وحید یوسف زاده 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  باشد.

(بیشتر…)

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

نویسنده مطلب: وحید یوسف زاده 4 Comments

همانطور که می دانید 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” را مطالعه کنید)

(بیشتر…)

توضیحی در مورد خطای bash- Argument list too long

نویسنده مطلب: وحید یوسف زاده Leave a comment

خطای Argument list too long یکی از خطاهای رایج در محیط لینوکس می باشد که معمولا در زمان کار با تعداد زیادی از فایل در یک دایرکتوری رخ می دهد:

 [root@LinuxHost mydir]# rm –rf *.html

-bash: /bin/rm: Argument list too long

[root@LinuxHost mydir]# cp * /dir1

-bash: /usr/bin/cp: Argument list too long

[root@LinuxHost mydir]# ls -l *

-bash: /usr/bin/ls: Argument list too long

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

ls -l file1 file2 file3 … fileN

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

[root@LinuxHost  ~]# getconf ARG_MAX

2097152

(بیشتر…)

عملگرهای SET در SQL

نویسنده مطلب: میلاد خالقی 1 Comment

در دستورات SQL عملگرهای SET سطرهای چندین دستور SELECT را ترکیب کرده و ترتیب نمایش آنها را مشخص می کند. در این متن انواع روش های استفاده از عملگرهای SET توضیح داده می شود.

دستوراتی که در آنها از عملگر SET استفاده می شوند COMPOUND QUERY نام دارند. اولویت اجرای تمام روش های عملگر SET یکسان است. اگر در یک دستور SQL از چند عملگر SET استفاده شود ترتیب اجرای آنها از سمت چپ به راست خواهد بود مگر اینکه از علامت پرانتز استفاده شده باشد.

(بیشتر…)

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

نویسنده مطلب: وحید یوسف زاده 2 Comments

قبلا در مقاله ای در مورد 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;

(بیشتر…)

SUBQUERY در SQL

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

گاهی اوقات لازم است یک دستور SQL طوری نوشته شود که در داخل آن دستورات SQLای دیگری قرار بگیرند و با اجرای دستورات درونی، نتیجه لازم به دستور اصلی برگردد. در این حالت دستور اول Main Query نام دارد و دستورات داخلی را SUBQUERY می نامند.هر SUBQUERY نتیجه لازم را برای Main Query ارسال می کند.

در این متن روش های مختلف استفاده از SUBQUERY در دستورات SQL توضیح داده می شود.

(بیشتر…)

چرا Huge Page؟

نویسنده مطلب: وحید یوسف زاده 4 Comments

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

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

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

(بیشتر…)

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

نویسنده مطلب: وحید یوسف زاده 1 Comment

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

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

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

(بیشتر…)

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

نویسنده مطلب: وحید یوسف زاده Leave a comment

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

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

(بیشتر…)

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

نویسنده مطلب: وحید یوسف زاده 2 Comments

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

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

(بیشتر…)