رسول_57
سه شنبه 14 مهر 1394, 09:18 صبح
یک سرور اوراکل می تواند در یکی از سه حالت زیر پیکربندی گردد :
1-معماری Dedicated server
2-معماری Shared Server
3-معماری Database Resident Connection Pooling یا DRCP
معماری Dedicated Server :
هنگامیکه یک درخواست SQL از طرف فرآیند کاربر به سمت سرور اوراکل ارسال می گردد ، فرآیند سرور آن را دریافت نموده و به عنوان یک فرمان ، اجرا و نتیجه را به فرآیند کاربر باز می گرداند . در معماری Dedicated Server به ازای هر ارتباط یک فرآیند سرور جهت پاسخگویی به آن ایجاد می شود . این فرایند سرور تا زمانیکه Session کاربر خاتمه نیافته باشد در سیستم باقی می ماند . اگر تعداد درخواست ها افزایش یابد ، Listener مجبور خواهد شد تا آنها را در صف قرار دهد . جهت حل این مشکل می توان چندین listener در سیستم پیکربندی نمود . اما روی تعداد بالای listener ها به علت محدودیت فضایی و اورهد سیستم نمی توان حساب کرد .
معماری Shared Server
در این نوع معماری تعاملی که بین فرآیند سرور و فرآیند کاربر صورت می پذیرد دقیقا مانند حالت قبل می باشد ولی نحوه پیکربندی و عملیاتی که در سمت سرور انجام می گیرد کاملا متفاوت از حالت قبل است . در این معماری علاوه بر فرآیندهای خود Instance از دو نوع فرآیند اضافی زیر که به هنگام راه اندازی Instance اجرا می گردند ، استفاده می شود :
Dispatcher
Shared Server
هنگامیکه فرآیند کاربر درخواست ایجاد ارتباط را صادر می کند ، listener آن را دریافت نموده و به جای ایجاد یک فرآیند سرور جهت پاسخگویی به آن ، آدرس یک dispatcher را به آن بر می گرداند . اگر فقط یک Dispatcher وجود داشته باشد تمام فرآیندهای کاربر از آن استفاده خواهد نمود و در صورت وجود چندین dispatcher ، لیسنر با ایجاد توازن از یکی از dispatcher ها جهت پاسخگویی به آن استفاده خواهد نمود . پس از ایجاد Session ، فرآیند کاربر دستور SQL خود را جهت اجرا به سمت dispatcher ارسال می نماید . dispatcher مورد نظر آن را دریافت نموده و در صف مشترکی به نام Common Queue قرار می دهد . تمام فرآیندهای Shared Server این صف را مانیتور می کنند . هنگامیکه درخواست جدیدی در صف قرار می گیرد ، اولین فرآیند Shared Server آزاد آن را برداشته و اجرا می کند . اما از آنجا که هیچ ارتباطی بین فرآیند سرور و فرآیند کاربر وجود ندارد ، بنابراین این فرآیند نمی تواند نتیجه را به کاربر باز گرداند . هر dispatcher صفی به نام Response Queue دارد که از آن برای نگهداری نتایج مربوط به دستور SQL ای که از طرف فرآیند کاربر دریافت نموده بود ، استفاده می کند . فرآیند Shared Server نتایج بدست آمده را در صف پاسخ dispatcher ای که آن کار را دریافت کرده بود قرار می دهد . هر dispatcher نیز صف Response خود را مانیتور کرده و در صورت وجود نتیجه در آن ، آن را به سمت فرآیند کاربر ارسال می کند .
معماری DRCP
این روش نسبت به روش های قبلی از حافظه کمتری استفاده می کند ولی از نظر نحوه انجام عملیات شبیه dedicated Server عمل می کند با این تفاوت که در این روش کاربران نیازی به حفظ ارتباط با بانک اطلاعاتی تا زمان خاتمه Session ندارند. هر کاربر در مواقع مور نیاز یکی از فرآیندهای سرور موجود در منبع فرآیندهای سرور را به خدمت گرفته ، کار خود را انجام داده و سپس ارتباط خود را قطع نموده و فرآیند سرور به منبع فرآیندها بر می گردد . برخلاف معماری Dedicated Server که در آن مقدار حافظه استفاده شده متناسب با تعداد Session ها می باشد ، در DRCP مقدار حافظه متناسب با تعداد فرآیندهای سرور فعال می باشد . در ادامه مثالی را جهت درک تفاوت مقدار حافظه استفاده شده با استفاده از سه روش پیکربندی ذکر می کنیم :
فرض کنید که تعداد 5000 کلاینت وجود دارد . هر Session کاربر نیاز به 200 کیلو بایت و هر فرآیند سرور نیز نیاز به 5 مگابایت حافظه دارد . همچنین فرض کنید که تعداد فرآیندهای سرور موجود در مخزن (Shared Server ها) برابر با 200 باشد . با توجه به فرضیات فوق ، مقدار کل حافظه لازم در هر یک از سه روش پیکربندی به صورت زیر می باشد :
[*=1|left] 26 گیگا بایت =(Dedicated Server : 5000*(200 Kb + 5 Mb
[*=1|left]11 گیگا بایت =(Shared Server : (5000*200 Kb) +(200 * 5 Mb
[*=1|left]502 مگا بایت =(DRCP : 200*(200 Kb + 5 Mb
همانطور که ملاحظه می کنید مقدار کل حافظه لازم در DRCP نسبت به دو روش دیگر خیلی کم می باشد .
1-معماری Dedicated server
2-معماری Shared Server
3-معماری Database Resident Connection Pooling یا DRCP
معماری Dedicated Server :
هنگامیکه یک درخواست SQL از طرف فرآیند کاربر به سمت سرور اوراکل ارسال می گردد ، فرآیند سرور آن را دریافت نموده و به عنوان یک فرمان ، اجرا و نتیجه را به فرآیند کاربر باز می گرداند . در معماری Dedicated Server به ازای هر ارتباط یک فرآیند سرور جهت پاسخگویی به آن ایجاد می شود . این فرایند سرور تا زمانیکه Session کاربر خاتمه نیافته باشد در سیستم باقی می ماند . اگر تعداد درخواست ها افزایش یابد ، Listener مجبور خواهد شد تا آنها را در صف قرار دهد . جهت حل این مشکل می توان چندین listener در سیستم پیکربندی نمود . اما روی تعداد بالای listener ها به علت محدودیت فضایی و اورهد سیستم نمی توان حساب کرد .
معماری Shared Server
در این نوع معماری تعاملی که بین فرآیند سرور و فرآیند کاربر صورت می پذیرد دقیقا مانند حالت قبل می باشد ولی نحوه پیکربندی و عملیاتی که در سمت سرور انجام می گیرد کاملا متفاوت از حالت قبل است . در این معماری علاوه بر فرآیندهای خود Instance از دو نوع فرآیند اضافی زیر که به هنگام راه اندازی Instance اجرا می گردند ، استفاده می شود :
Dispatcher
Shared Server
هنگامیکه فرآیند کاربر درخواست ایجاد ارتباط را صادر می کند ، listener آن را دریافت نموده و به جای ایجاد یک فرآیند سرور جهت پاسخگویی به آن ، آدرس یک dispatcher را به آن بر می گرداند . اگر فقط یک Dispatcher وجود داشته باشد تمام فرآیندهای کاربر از آن استفاده خواهد نمود و در صورت وجود چندین dispatcher ، لیسنر با ایجاد توازن از یکی از dispatcher ها جهت پاسخگویی به آن استفاده خواهد نمود . پس از ایجاد Session ، فرآیند کاربر دستور SQL خود را جهت اجرا به سمت dispatcher ارسال می نماید . dispatcher مورد نظر آن را دریافت نموده و در صف مشترکی به نام Common Queue قرار می دهد . تمام فرآیندهای Shared Server این صف را مانیتور می کنند . هنگامیکه درخواست جدیدی در صف قرار می گیرد ، اولین فرآیند Shared Server آزاد آن را برداشته و اجرا می کند . اما از آنجا که هیچ ارتباطی بین فرآیند سرور و فرآیند کاربر وجود ندارد ، بنابراین این فرآیند نمی تواند نتیجه را به کاربر باز گرداند . هر dispatcher صفی به نام Response Queue دارد که از آن برای نگهداری نتایج مربوط به دستور SQL ای که از طرف فرآیند کاربر دریافت نموده بود ، استفاده می کند . فرآیند Shared Server نتایج بدست آمده را در صف پاسخ dispatcher ای که آن کار را دریافت کرده بود قرار می دهد . هر dispatcher نیز صف Response خود را مانیتور کرده و در صورت وجود نتیجه در آن ، آن را به سمت فرآیند کاربر ارسال می کند .
معماری DRCP
این روش نسبت به روش های قبلی از حافظه کمتری استفاده می کند ولی از نظر نحوه انجام عملیات شبیه dedicated Server عمل می کند با این تفاوت که در این روش کاربران نیازی به حفظ ارتباط با بانک اطلاعاتی تا زمان خاتمه Session ندارند. هر کاربر در مواقع مور نیاز یکی از فرآیندهای سرور موجود در منبع فرآیندهای سرور را به خدمت گرفته ، کار خود را انجام داده و سپس ارتباط خود را قطع نموده و فرآیند سرور به منبع فرآیندها بر می گردد . برخلاف معماری Dedicated Server که در آن مقدار حافظه استفاده شده متناسب با تعداد Session ها می باشد ، در DRCP مقدار حافظه متناسب با تعداد فرآیندهای سرور فعال می باشد . در ادامه مثالی را جهت درک تفاوت مقدار حافظه استفاده شده با استفاده از سه روش پیکربندی ذکر می کنیم :
فرض کنید که تعداد 5000 کلاینت وجود دارد . هر Session کاربر نیاز به 200 کیلو بایت و هر فرآیند سرور نیز نیاز به 5 مگابایت حافظه دارد . همچنین فرض کنید که تعداد فرآیندهای سرور موجود در مخزن (Shared Server ها) برابر با 200 باشد . با توجه به فرضیات فوق ، مقدار کل حافظه لازم در هر یک از سه روش پیکربندی به صورت زیر می باشد :
[*=1|left] 26 گیگا بایت =(Dedicated Server : 5000*(200 Kb + 5 Mb
[*=1|left]11 گیگا بایت =(Shared Server : (5000*200 Kb) +(200 * 5 Mb
[*=1|left]502 مگا بایت =(DRCP : 200*(200 Kb + 5 Mb
همانطور که ملاحظه می کنید مقدار کل حافظه لازم در DRCP نسبت به دو روش دیگر خیلی کم می باشد .