دانلود با لینک مستقیم و پر سرعت .
لینک پرداخت و دانلود *پایین مطلب*
فرمت فایل:Word (قابل ویرایش و آماده پرینت)
تعداد صفحه:35
فهرست مطالب
REAL_TIME
( A) Real_Time Query Processing
Our Foues ( B )
Related Work (2)
Basic Real time Scheduling (3)
Admission Control (A)
Miss Ratio Projection A –1
Resource Utilizing Heuristic A –2 Memory Allocatoin – B
Dealing with Workload Charges - C
4- Multi Class Real _Time Query Scheduling Ov erview of PAQRS Algorithm -A Admission Control & Memory Allocaton in PAQRS - B
Weighted Miss Ratios = Σ Weight i X Miss Ratio i
Bias Control in PAQRS - C Database System Simulation Model – 5 Database and Work load Model –A Physical Resource Model – B Memory – Adoptiرe Query Primitive – C
Conclusion –5
خلاصه : در سالهای اخیر ، یک درخواست برای سیستمهای REAL_TIME که میتواند حجم گستردهای از دادههای به اشتراک گذاشته شده را دستکاری کند ، به یک امر حتمی و لازم در سیستمهای REAL_TIME Data BASE RTDBS به عنوان یک زمینة تحقیقی تبدیل شده است . این مقاله بر روی مسئلة زمانبندی QUERY ها در RTDBS ها متمرکز شده است .
ما الگوریتم جدیدی به نام Priority Adaptation Query Reource Scheduling PAQRS برای اداره کردن کارهای Multi Class Query و Single Class Query را معرفی و ارزیابی میکنیم . هدف عمدة الگوریتم به حداقل رساندن تعداد Deadline های از دست داده شده است و در عین حال اطمینان پیدا کردن از اینکه dead line های از دست داده شده در بین کلاسهای متفاوت مربوط به یک توزیع اجرایی از دست دادن پخش شده باشد . این منظور با تعدیل پویای پذیرش ورودی ، تخصیص حافظه و سیاستهای اعمال اولویت بر طبق پیکربندی منبع معنی آن و خصوصیات کلی کار بدست میآید . یک سری از آزمایشات نشان دادهاند که PAQRS برای زمانبندی Query های Real _Time بسیار مؤثر هستند .
معرفی : در تعدادی از Data Base application های پدیداری شامل ـ کنترل پرواز ، مدیریت شبکه و اتوماسیون کارخانه ـ باید تعداد زیادی از دادههای به اشتراک گذاشته شده به یک روش به هنگام دستکاری شوند . به صورت مخصوص تری ،این application ها ممکن است که transaction ها و Query هایی تولید کنند که باید تا Dead line های مشخصی انجام شوند تا نتایج کاملی ( یا اصلاً نتیجهای ) را در برداشته باشند . نیاز به سیستمهایی که میتوانند از چنین مدیریتهای زمانی میزان اصلی دادهها ، پشتیبانی کنند ،توجه محققین را به سمت زمینة سیستمهای Real _ Time Data buse RTDBS در هر دو زمینة اجتماعات محاسبهای Real _ Time و Data base ای کشانده است . امروزه بیشتر کار در زمینة RTDBS بر روی موارد مدیریت Tran ssaction و زمانبندی منابع سطح پایین CPU , I/O متمرکز شده است .
بسته به اینکه چگونه application های یک سیستم Real _Time Data base میتوانند فشار زمانی اشان را تحمل کنند به عنوان یک سیستم Hard ، Soft یا Firm شناخته میشوند . در این مطالعه ، ما بر روی Firm RTDBS ها تمرکز میکنیم که در آن Job ای که از زمان dead line اش بگذرد به عنوان یک Job بدون استفاده ( غیرمفید ) در نظر گرفته میشود . برای رویارویی با فشارهای زمانی Job هایش ، یک Firm RTDBS باید Mulit Program باشند ، بنابر این تمامی منابع آن میتواند به صورت پرباری مورد استفاده قرار بگیرد . به علاوه ، باید زمان تکمیل Job های منفرد که تنظیم کند ؛ برای این کار باید از زمانبندی الویتبندی برای رفع هرگونه درگیری منبعی Multi Programming باعث آن میشود استفاده کند . در Firm RTDBS هنگامی که فضای کاری آن شامل Job هایی است که از کلاسهای متفاوتی نشأت گرفتهاند رسیدن به هدف اصلی آن سختتر میشود . برای چنین فضاهای کاری ، RTDBS باید مواردی مانند چگونگی توزیع از دست دادن Dead line ها در بین کلاسهای مختلف را هم اداره کند . چون توزیع مطلوب از دست دادنهای Dead line از یک محیط به محیط دیگر ممکن است فرق داشته باشد ، RTDBS باید بتواند سیاستهای زمانبندی منبعهایش را بر مبنای توزیع اعمال شده توسط System Administer سازگار کند . بنابر این هدف یک RTDBS با یک فضای کاری چند کلاسه multi class باید به حداقل رساندن کل تعداد موارد از دست رفتن Dead line ها باشد و هر از دست رفتنی باید با توجه به تنظیمات Administer بین کلاسها توزیع شود .
( A) Real_Time Query Processing
بازده Query ها میتواند بسته به میزان حافظهای که برای کار به آنها داده شده است بسیار متفاوت باشد . هنگامی که حافظة کافی در اختیار Query ها قرار میگیرد ،اکثر آنها میتوانند به آسانی یکباره Operand Relation هایشان را بخوانند و نتایج لازم را به صورت مستقیم تولید کنند . این مقدار به عنوان حداکثر حافظة مورد نیاز Query در نظر گرفته میشود . اگر حافظة کمتری به آنها اختصاص داده شود ، تا زمانیکه این مقدار بیشتر از حداقل حافظة مورد نیاز Query باشد ، باز هم اکثر Query ها میتوانند با بیرون نوشتن فایلهای Temporary و خواندن دوبارة آنها در Process های بعدی اجر شوند . برای مثال ، یک Hash Join هم میتواند با داشتن حداکثر حافظة مورد نیاز برای Query اش اجرا شود که یکی بزرگتر از اندازة Inner Relation اش است و هم میتواند فقط در یک عبور اضافی با تعداد Buffer Page هایی به کمی ریشة دوم اندازة inner Relation اش کار کند . برای کمک به اینکه تمامی کلاسهای Query بتوانند به سطح بازدهی موردنظرشان برسند ، یک RTDBS حتماً باید به تعدادی از Query ها کمتر از حداکثر حافظة موردنیازشان تخصیص دهد به ویژه هنگامی که مقدار حافظة موردنیازشان بزرگ است . در هر حال ، اگر تعداد زیادی Query پذیرفته شود ، I/o اضافی که در نتیجة آن ایجاد میشود باعث Thrashing میشود و به جای کمک بودن برای هم روندی ایجاد اشکال میکند . بنابر این RTDBS ها باید به دقت پذیرفتن Query به سیستم را کنترل کنند .
بعد از مشخص شدن اینکه کدام Query ها باید پذیرفته شوند مسئلةبعدی که RTDBS با آن رو برو سست تخصیص حافظه است . هنگامیکه با اولویتترین Query ایی که Cpu یا Disk را در اختیار دارد ، از آن منبع به صورت کاملاً انحصاری استفاده میکند ، ولی حافظه باید بین تمام Query های پذیرفته شده به اشتراک گذاشته شود . هنگامیکه حداکثر حافظة موردنیاز کل Query های پذیرفته شده از حافظة قابل دسترسی بیشتر باشد ، RTDBS باید در مورد میزان حافظهای که باید بر هر Query بدهد تصمیمگیری کند . در این تصمیمگیری هم بازده موردنیاز کلاسها و هم فشار محدودیت زمانی هر Query در نظر گرفته شود . به علاوه ، تأثیر تخصیص حافظه در کاهش زمان پاسخگویی Query های منفرد هم باید در نظر گرفته شود اینکه بهترین استفاده از حافظة در دسترس بشود . در آخر ، چون اولویت نسبی تا یک Query در حال اجرا ممکن است با گذشت زمان به علت آمدن و رفتن Query های دیگر به سیستم تغییر کند ، تخصیص حافظه به یک Query احتمالاً نوسان و بالا و پایین خواهد داشت . برای ساده کردن پردازش َquery مؤثر در رویارویی با چنین نوسان حافظهای ، RTDBS ها نیازمندquery operator هایی هستند که بصورت دینامیکدر حال اجرا هم بتوانند حافظه آزاد کنند و هم حافظة بیشتری را بپذیرند . تا این تاریخ ، کنترل ورودی و تخصیص حافظه مسائلی هستند که در زمانبندی Real _Time Query آدرس دهی نشدهاند .