انجمنصفحه اولجستجوی انجمن

[mos_hos]

در اعتراضاتی که به کلید سازمان سنج شده بود، دیدم که اکثرا دوستان به سوالات ۳۹ و ۴۱ پایگاه داده معترض بودند. بنده رابطه بسیار نزدیکی با طراح سوالات دیتابیس امسال دارم و باید بگم که ایشون به هیچ وجه اشتباه نکرده است. ایشان کسی است که دکتر روحانی را متقاعد کرد که در چند مورد در مطالب کتابش اشتباه کرده است. بعید می دانم که اعتراضات در مورد سوالات دیتابیس نتیجه ای داشته باشد. تمامی سوالات به نظر من درست هستند.
در مورد سوال ۳۹ دیتابیس نکته ای که وجود دارد این است تمامی پروتوکل های ۲PL به جز rigorous به دانستن درخواست های خواندن و نوشتن تراکنش ها در آینده نیاز دارند. زیرا اگر درخواست های آینده تراکنش را ندانند، چگونه می توانند اطمینان حاصل کنند که تراکنش تمام قفل های مورد نیازش را دریافت کرده و می تواند به مرحله lock point وارد شود و قفلی را آزاد کند؟ به طور کلی ۲PL نیاز دارد در زمان lock point که قرار است قفلی آزاد شود، اطمینان حاصل شود که تراکنش دیگر هیچ درخواست قفلی نخواهد داشت.پس strict 2PL نیز به دانستن درخواست های قفل در آینده نیاز دارد. ولی در rigorous، تا زمان تثبیت تراکنش هیچ قفلی آزاد نخواهد شد و در نتیجه نیازی به دانستن درخواست های قفل در آینده ندارد. تفاوت conservative با سایر ۲PLها نیز در این است که در زمان شروع، به دانستن همه درخواست های قفل دارد ولی در سایر ۲PL ها چنانچه تراکنشی درخواست آزادسازی قفلی را بدهد، در آن زمان نیاز است تا بداند تراکنش دیگر در آینده به قفلی نیاز ندارد.
در مورد سوال ۴۱ نیز اینگونه است:
تراکنش T2 قبل از نقطه وارسی بوده است پس در هر دو حالت نیازی به undo یا redo ندارد. تراکنش های T1 و T3 هر دو قبل از شروع نقطه وارسی آغاز شده اند و در زمان خراب هنوز به تثبیت نرسیده اند ولی چون نقطه وارسی انجام شده است، پس حتما بخشی از آنها در حافظه مانا ثبت شده است و در هر دو حالت deferred mode و immediate mode به undo نیاز دارند. T4 و T5 تثبیت شده اند و در حالت immediate به redo نیاز ندارند. ولی در حالت deferred نقطه وارسی بخشی از T4 را به حافظه مانا منتقل کرده است و به undo نیاز دارد ولی T5 بعد از نقطه وارسی بوده و هیچ تاثیری بر روی حافظه مانا نداشته و نیازی به undo ندارد. T6 نیز در حالت immediate به undo نیاز دارد و در حالت deferred چون بعد از نقطه وارسی بوده به undo نیاز ندارد. پس کلید کاملا درست است.

[گلاره]

(۱۷ اسفند ۱۳۹۵ ۰۳:۲۰ ب.ظ)mos_hos نوشته شده توسط:  در اعتراضاتی که به کلید سازمان سنج شده بود، دیدم که اکثرا دوستان به سوالات ۳۹ و ۴۱ پایگاه داده معترض بودند. بنده رابطه بسیار نزدیکی با طراح سوالات دیتابیس امسال دارم و باید بگم که ایشون به هیچ وجه اشتباه نکرده است. ایشان کسی است که دکتر روحانی را متقاعد کرد که در چند مورد در مطالب کتابش اشتباه کرده است. بعید می دانم که اعتراضات در مورد سوالات دیتابیس نتیجه ای داشته باشد. تمامی سوالات به نظر من درست هستند.
در مورد سوال ۳۹ دیتابیس نکته ای که وجود دارد این است تمامی پروتوکل های ۲PL به جز rigorous به دانستن درخواست های خواندن و نوشتن تراکنش ها در آینده نیاز دارند. زیرا اگر درخواست های آینده تراکنش را ندانند، چگونه می توانند اطمینان حاصل کنند که تراکنش تمام قفل های مورد نیازش را دریافت کرده و می تواند به مرحله lock point وارد شود و قفلی را آزاد کند؟ به طور کلی ۲PL نیاز دارد در زمان lock point که قرار است قفلی آزاد شود، اطمینان حاصل شود که تراکنش دیگر هیچ درخواست قفلی نخواهد داشت.پس strict 2PL نیز به دانستن درخواست های قفل در آینده نیاز دارد. ولی در rigorous، تا زمان تثبیت تراکنش هیچ قفلی آزاد نخواهد شد و در نتیجه نیازی به دانستن درخواست های قفل در آینده ندارد. تفاوت conservative با سایر ۲PLها نیز در این است که در زمان شروع، به دانستن همه درخواست های قفل دارد ولی در سایر ۲PL ها چنانچه تراکنشی درخواست آزادسازی قفلی را بدهد، در آن زمان نیاز است تا بداند تراکنش دیگر در آینده به قفلی نیاز ندارد.
در مورد سوال ۴۱ نیز اینگونه است:
تراکنش T2 قبل از نقطه وارسی بوده است پس در هر دو حالت نیازی به undo یا redo ندارد. تراکنش های T1 و T3 هر دو قبل از شروع نقطه وارسی آغاز شده اند و در زمان خراب هنوز به تثبیت نرسیده اند ولی چون نقطه وارسی انجام شده است، پس حتما بخشی از آنها در حافظه مانا ثبت شده است و در هر دو حالت deferred mode و immediate mode به undo نیاز دارند. T4 و T5 تثبیت شده اند و در حالت immediate به redo نیاز ندارند. ولی در حالت deferred نقطه وارسی بخشی از T4 را به حافظه مانا منتقل کرده است و به undo نیاز دارد ولی T5 بعد از نقطه وارسی بوده و هیچ تاثیری بر روی حافظه مانا نداشته و نیازی به undo ندارد. T6 نیز در حالت immediate به undo نیاز دارد و در حالت deferred چون بعد از نقطه وارسی بوده به undo نیاز ندارد. پس کلید کاملا درست است.

سلام
ببخشید میشه ایشون رو معرفی کنین که ما برای سال آینده از اسلایدها و جزوات ایشون هم استفاده کنیم؟

[esi2]

(۱۷ اسفند ۱۳۹۵ ۰۳:۲۰ ب.ظ)mos_hos نوشته شده توسط:  در اعتراضاتی که به کلید سازمان سنج شده بود، دیدم که اکثرا دوستان به سوالات ۳۹ و ۴۱ پایگاه داده معترض بودند. بنده رابطه بسیار نزدیکی با طراح سوالات دیتابیس امسال دارم و باید بگم که ایشون به هیچ وجه اشتباه نکرده است. ایشان کسی است که دکتر روحانی را متقاعد کرد که در چند مورد در مطالب کتابش اشتباه کرده است. بعید می دانم که اعتراضات در مورد سوالات دیتابیس نتیجه ای داشته باشد. تمامی سوالات به نظر من درست هستند.
در مورد سوال ۳۹ دیتابیس نکته ای که وجود دارد این است تمامی پروتوکل های ۲PL به جز rigorous به دانستن درخواست های خواندن و نوشتن تراکنش ها در آینده نیاز دارند. زیرا اگر درخواست های آینده تراکنش را ندانند، چگونه می توانند اطمینان حاصل کنند که تراکنش تمام قفل های مورد نیازش را دریافت کرده و می تواند به مرحله lock point وارد شود و قفلی را آزاد کند؟ به طور کلی ۲PL نیاز دارد در زمان lock point که قرار است قفلی آزاد شود، اطمینان حاصل شود که تراکنش دیگر هیچ درخواست قفلی نخواهد داشت.پس strict 2PL نیز به دانستن درخواست های قفل در آینده نیاز دارد. ولی در rigorous، تا زمان تثبیت تراکنش هیچ قفلی آزاد نخواهد شد و در نتیجه نیازی به دانستن درخواست های قفل در آینده ندارد. تفاوت conservative با سایر ۲PLها نیز در این است که در زمان شروع، به دانستن همه درخواست های قفل دارد ولی در سایر ۲PL ها چنانچه تراکنشی درخواست آزادسازی قفلی را بدهد، در آن زمان نیاز است تا بداند تراکنش دیگر در آینده به قفلی نیاز ندارد.
در مورد سوال ۴۱ نیز اینگونه است:
تراکنش T2 قبل از نقطه وارسی بوده است پس در هر دو حالت نیازی به undo یا redo ندارد. تراکنش های T1 و T3 هر دو قبل از شروع نقطه وارسی آغاز شده اند و در زمان خراب هنوز به تثبیت نرسیده اند ولی چون نقطه وارسی انجام شده است، پس حتما بخشی از آنها در حافظه مانا ثبت شده است و در هر دو حالت deferred mode و immediate mode به undo نیاز دارند. T4 و T5 تثبیت شده اند و در حالت immediate به redo نیاز ندارند. ولی در حالت deferred نقطه وارسی بخشی از T4 را به حافظه مانا منتقل کرده است و به undo نیاز دارد ولی T5 بعد از نقطه وارسی بوده و هیچ تاثیری بر روی حافظه مانا نداشته و نیازی به undo ندارد. T6 نیز در حالت immediate به undo نیاز دارد و در حالت deferred چون بعد از نقطه وارسی بوده به undo نیاز ندارد. پس کلید کاملا درست است.

در مورد سوال ۳۹ ، طرز تفکر جالبیه در مورد پروتکل ۲pl. در مورد این عبارت : "ولی در rigorous، تا زمان تثبیت تراکنش هیچ قفلی آزاد نخواهد شد و در نتیجه نیازی به دانستن درخواست های قفل در آینده ندارد." : نیگاه کنید سیستم پایگاه داده ذاتا از آینده تراکنش ها خبر نداره مگر اینکه تراکنش رو مجبور کنه از آینده کاریش سیستم رو مطلع کنه مثل پرتوکل Conservative، تویه ۲pl برای پیدا کردن نقطه قفل نیازی به دانستن داده های آینده نیست( بحز Conservative)، به محض رسیدن به یک دستور Unlock سیستم متوجه میشه که به این نقطه رسید است، چون تراکنش ها ممکن است دارای ساختار شرطی بسیار پیچیده باشه و امکان بررسی نقطه قفل از قبل واقعا کار دشواریه. لذا تمامی ۲PL ها( به جز Conservative) نیازی به دونستن درخواست های آینده تراکنش نمی باشد. نیگاه کنید نقطه قفل یک مفهوم فقطه منطقی است برای بررسی عملکرد تراکنش مطابق پروتکل کنترل همروندی و این نقطه در زمان اجرا مشخص میشه. شما هیچ زبانی رو پیدا نمیکنید که نقطه قفل رو بشه تو ساختار تراکنش مشخص نمود: Oracle, DB2, MySQL, Postgres و ... آره حرف شما درسته که در زمان اجرا نیازی به تثبیت نقطه قفل نیست تو روش Rigorous و این نقطه با رسیدن به تثبیت مشخص میشه اما این به معنی نیست که همه ۲pl ها مثل strict نیازی به دانستن قفل های آینده هستن، خود سیستم راحت میتونه به صورت ضمنی این نقطه پیداکنه. دانستن داده های آینده به معنی اجبار تراکنش به استفاده از دستوری جهت مشخص نمودن یه حالت خاص هستش متل Conservative. تویه Strict به رسیدن به دستور Unlock میشه فهمید به نقطه قفل رسیده و تویه Rigoroud با رسیدن به دستور Commit، این تنها تفاوت در پیدا کردن نقطه قفل توسط DBMS هستش.

در مورد سوال ۴۱ هم کاملا با شما موافقم و سوال مشکلی نداره.

نظرتون در مورد سوال ۴۲ چیه ؟ جواب این سوال گزینه ۴ میشه اما کلید گزینه ۳ رو زده !!
مطابق شکل داده شده، از روش فازی ساده جهت ایجاد نقطه وارسی Check Point استفاده شده است. در این روش، ابتدا یک نقطه شروع وارسی begin ایجاد شده و لیست تمامی صفحات تغییر یافته ثبت شده و سپس شروع به انقال این صفحات از حافظه اصلی به دیسک می شود. هنگامیکه انتقال تمامی صفحات به دیسک انجام شد یک نقطه اتمام وارسی End ثبت می شود و نشان می دهد که تمامی صفحات تغییر یافته قبل از نقطه Begin منتقل شده است. لذا اگر تراکنشی قبل از نقطه begin تثبیت شده باشد آنگاه وجود نقطه End بعد از آن ، نشاندهنده انتقال صفحات تراکنش بوده و لذا در صورت بروز خرابی بعد از نقطه End نیازی به redo کرده تراکنش نمی باشد( حتما صفحات آن به دیسک منتقل شده است).
مطابق تصویر داده شده، تمامی صفحات تغییر یافته از نقظه Begin-CheckPoint(n-1) به حافظه منتقل شده( به علت مشاهده End-CheckPoint(n-1) ) و لذا تمامی تراکنش های تثبیت شده قبل از نقطه Begin-CheckPoint(n-1) حتما به دیسک منتقل شده و نیازی به redo نمی باشد. گزینه ۳ صحیح نمی باشد؛ زیرا بین نقطه Begin-CheckPoint(n-1) و End-CheckPoint(n-1 اگر تراکنشی ثبیت شود، هنوز به دیسک منتقل نشده و این کار باید در ایجاد نقظه وارسی بعدی یعنی Begin-CheckPoint(n) انجام شود که در این نقطه نیز به علت عدم مشاهده End-CheckPoint(n) عملیات انتقال صفحات هنوز به طور کامل انجام نشده است. بعبارت دیگر، تنها توسط نقطه Begin صفحات تغییر یافته لیست شده و در صورت انتقال صحیح آنها نقطه End ثبت خواهد شد.
در منبع مربوطه ( رانکوهی) عبارت زیر به طور واضح ذکر شده است : " عمل Redo باید بعد از نقطه Begin-CheckPoint شروع شود. اما مطمئن هستیم که قبل از این رکورد حتما در پایگاه داده مانا وجود دارند"
نتیجه میگیرم در صورت مشاهده نقطه End برای یک نقطه Begin نیازی به redo برای تراکنش های تثبیت شده قبل از نقطه Begin نخواهد بود.

[shahryar711]

(۱۸ اسفند ۱۳۹۵ ۰۹:۲۲ ق.ظ)esi2 نوشته شده توسط:  

(17 اسفند ۱۳۹۵ ۰۳:۲۰ ب.ظ)mos_hos نوشته شده توسط:  در اعتراضاتی که به کلید سازمان سنج شده بود، دیدم که اکثرا دوستان به سوالات ۳۹ و ۴۱ پایگاه داده معترض بودند. بنده رابطه بسیار نزدیکی با طراح سوالات دیتابیس امسال دارم و باید بگم که ایشون به هیچ وجه اشتباه نکرده است. ایشان کسی است که دکتر روحانی را متقاعد کرد که در چند مورد در مطالب کتابش اشتباه کرده است. بعید می دانم که اعتراضات در مورد سوالات دیتابیس نتیجه ای داشته باشد. تمامی سوالات به نظر من درست هستند.
در مورد سوال ۳۹ دیتابیس نکته ای که وجود دارد این است تمامی پروتوکل های ۲PL به جز rigorous به دانستن درخواست های خواندن و نوشتن تراکنش ها در آینده نیاز دارند. زیرا اگر درخواست های آینده تراکنش را ندانند، چگونه می توانند اطمینان حاصل کنند که تراکنش تمام قفل های مورد نیازش را دریافت کرده و می تواند به مرحله lock point وارد شود و قفلی را آزاد کند؟ به طور کلی ۲PL نیاز دارد در زمان lock point که قرار است قفلی آزاد شود، اطمینان حاصل شود که تراکنش دیگر هیچ درخواست قفلی نخواهد داشت.پس strict 2PL نیز به دانستن درخواست های قفل در آینده نیاز دارد. ولی در rigorous، تا زمان تثبیت تراکنش هیچ قفلی آزاد نخواهد شد و در نتیجه نیازی به دانستن درخواست های قفل در آینده ندارد. تفاوت conservative با سایر ۲PLها نیز در این است که در زمان شروع، به دانستن همه درخواست های قفل دارد ولی در سایر ۲PL ها چنانچه تراکنشی درخواست آزادسازی قفلی را بدهد، در آن زمان نیاز است تا بداند تراکنش دیگر در آینده به قفلی نیاز ندارد.
در مورد سوال ۴۱ نیز اینگونه است:
تراکنش T2 قبل از نقطه وارسی بوده است پس در هر دو حالت نیازی به undo یا redo ندارد. تراکنش های T1 و T3 هر دو قبل از شروع نقطه وارسی آغاز شده اند و در زمان خراب هنوز به تثبیت نرسیده اند ولی چون نقطه وارسی انجام شده است، پس حتما بخشی از آنها در حافظه مانا ثبت شده است و در هر دو حالت deferred mode و immediate mode به undo نیاز دارند. T4 و T5 تثبیت شده اند و در حالت immediate به redo نیاز ندارند. ولی در حالت deferred نقطه وارسی بخشی از T4 را به حافظه مانا منتقل کرده است و به undo نیاز دارد ولی T5 بعد از نقطه وارسی بوده و هیچ تاثیری بر روی حافظه مانا نداشته و نیازی به undo ندارد. T6 نیز در حالت immediate به undo نیاز دارد و در حالت deferred چون بعد از نقطه وارسی بوده به undo نیاز ندارد. پس کلید کاملا درست است.

در مورد سوال ۳۹ ، طرز تفکر جالبیه در مورد پروتکل ۲pl. در مورد این عبارت : "ولی در rigorous، تا زمان تثبیت تراکنش هیچ قفلی آزاد نخواهد شد و در نتیجه نیازی به دانستن درخواست های قفل در آینده ندارد." : نیگاه کنید سیستم پایگاه داده ذاتا از آینده تراکنش ها خبر نداره مگر اینکه تراکنش رو مجبور کنه از آینده کاریش سیستم رو مطلع کنه مثل پرتوکل Conservative، تویه ۲pl برای پیدا کردن نقطه قفل نیازی به دانستن داده های آینده نیست( بحز Conservative)، به محض رسیدن به یک دستور Unlock سیستم متوجه میشه که به این نقطه رسید است، چون تراکنش ها ممکن است دارای ساختار شرطی بسیار پیچیده باشه و امکان بررسی نقطه قفل از قبل واقعا کار دشواریه. لذا تمامی ۲PL ها( به جز Conservative) نیازی به دونستن درخواست های آینده تراکنش نمی باشد. نیگاه کنید نقطه قفل یک مفهوم فقطه منطقی است برای بررسی عملکرد تراکنش مطابق پروتکل کنترل همروندی و این نقطه در زمان اجرا مشخص میشه. شما هیچ زبانی رو پیدا نمیکنید که نقطه قفل رو بشه تو ساختار تراکنش مشخص نمود: Oracle, DB2, MySQL, Postgres و ... آره حرف شما درسته که در زمان اجرا نیازی به تثبیت نقطه قفل نیست تو روش Rigorous و این نقطه با رسیدن به تثبیت مشخص میشه اما این به معنی نیست که همه ۲pl ها مثل strict نیازی به دانستن قفل های آینده هستن، خود سیستم راحت میتونه به صورت ضمنی این نقطه پیداکنه. دانستن داده های آینده به معنی اجبار تراکنش به استفاده از دستوری جهت مشخص نمودن یه حالت خاص هستش متل Conservative. تویه Strict به رسیدن به دستور Unlock میشه فهمید به نقطه قفل رسیده و تویه Rigoroud با رسیدن به دستور Commit، این تنها تفاوت در پیدا کردن نقطه قفل توسط DBMS هستش.

در مورد سوال ۴۱ هم کاملا با شما موافقم و سوال مشکلی نداره.

نظرتون در مورد سوال ۴۲ چیه ؟ جواب این سوال گزینه ۴ میشه اما کلید گزینه ۳ رو زده !!
مطابق شکل داده شده، از روش فازی ساده جهت ایجاد نقطه وارسی Check Point استفاده شده است. در این روش، ابتدا یک نقطه شروع وارسی begin ایجاد شده و لیست تمامی صفحات تغییر یافته ثبت شده و سپس شروع به انقال این صفحات از حافظه اصلی به دیسک می شود. هنگامیکه انتقال تمامی صفحات به دیسک انجام شد یک نقطه اتمام وارسی End ثبت می شود و نشان می دهد که تمامی صفحات تغییر یافته قبل از نقطه Begin منتقل شده است. لذا اگر تراکنشی قبل از نقطه begin تثبیت شده باشد آنگاه وجود نقطه End بعد از آن ، نشاندهنده انتقال صفحات تراکنش بوده و لذا در صورت بروز خرابی بعد از نقطه End نیازی به redo کرده تراکنش نمی باشد( حتما صفحات آن به دیسک منتقل شده است).
مطابق تصویر داده شده، تمامی صفحات تغییر یافته از نقظه Begin-CheckPoint(n-1) به حافظه منتقل شده( به علت مشاهده End-CheckPoint(n-1) ) و لذا تمامی تراکنش های تثبیت شده قبل از نقطه Begin-CheckPoint(n-1) حتما به دیسک منتقل شده و نیازی به redo نمی باشد. گزینه ۳ صحیح نمی باشد؛ زیرا بین نقطه Begin-CheckPoint(n-1) و End-CheckPoint(n-1 اگر تراکنشی ثبیت شود، هنوز به دیسک منتقل نشده و این کار باید در ایجاد نقظه وارسی بعدی یعنی Begin-CheckPoint(n) انجام شود که در این نقطه نیز به علت عدم مشاهده End-CheckPoint(n) عملیات انتقال صفحات هنوز به طور کامل انجام نشده است. بعبارت دیگر، تنها توسط نقطه Begin صفحات تغییر یافته لیست شده و در صورت انتقال صحیح آنها نقطه End ثبت خواهد شد.
در منبع مربوطه ( رانکوهی) عبارت زیر به طور واضح ذکر شده است : " عمل Redo باید بعد از نقطه Begin-CheckPoint شروع شود. اما مطمئن هستیم که قبل از این رکورد حتما در پایگاه داده مانا وجود دارند"
نتیجه میگیرم در صورت مشاهده نقطه End برای یک نقطه Begin نیازی به redo برای تراکنش های تثبیت شده قبل از نقطه Begin نخواهد بود.

اقا یعنی منبع رانکوهی هست و سیلبرشاتس نیست ؟

[گلاره]

(۲۰ اسفند ۱۳۹۵ ۱۱:۲۵ ق.ظ)shahryar711 نوشته شده توسط:  

(18 اسفند ۱۳۹۵ ۰۹:۲۲ ق.ظ)esi2 نوشته شده توسط:  

(17 اسفند ۱۳۹۵ ۰۳:۲۰ ب.ظ)mos_hos نوشته شده توسط:  در اعتراضاتی که به کلید سازمان سنج شده بود، دیدم که اکثرا دوستان به سوالات ۳۹ و ۴۱ پایگاه داده معترض بودند. بنده رابطه بسیار نزدیکی با طراح سوالات دیتابیس امسال دارم و باید بگم که ایشون به هیچ وجه اشتباه نکرده است. ایشان کسی است که دکتر روحانی را متقاعد کرد که در چند مورد در مطالب کتابش اشتباه کرده است. بعید می دانم که اعتراضات در مورد سوالات دیتابیس نتیجه ای داشته باشد. تمامی سوالات به نظر من درست هستند.
در مورد سوال ۳۹ دیتابیس نکته ای که وجود دارد این است تمامی پروتوکل های ۲PL به جز rigorous به دانستن درخواست های خواندن و نوشتن تراکنش ها در آینده نیاز دارند. زیرا اگر درخواست های آینده تراکنش را ندانند، چگونه می توانند اطمینان حاصل کنند که تراکنش تمام قفل های مورد نیازش را دریافت کرده و می تواند به مرحله lock point وارد شود و قفلی را آزاد کند؟ به طور کلی ۲PL نیاز دارد در زمان lock point که قرار است قفلی آزاد شود، اطمینان حاصل شود که تراکنش دیگر هیچ درخواست قفلی نخواهد داشت.پس strict 2PL نیز به دانستن درخواست های قفل در آینده نیاز دارد. ولی در rigorous، تا زمان تثبیت تراکنش هیچ قفلی آزاد نخواهد شد و در نتیجه نیازی به دانستن درخواست های قفل در آینده ندارد. تفاوت conservative با سایر ۲PLها نیز در این است که در زمان شروع، به دانستن همه درخواست های قفل دارد ولی در سایر ۲PL ها چنانچه تراکنشی درخواست آزادسازی قفلی را بدهد، در آن زمان نیاز است تا بداند تراکنش دیگر در آینده به قفلی نیاز ندارد.
در مورد سوال ۴۱ نیز اینگونه است:
تراکنش T2 قبل از نقطه وارسی بوده است پس در هر دو حالت نیازی به undo یا redo ندارد. تراکنش های T1 و T3 هر دو قبل از شروع نقطه وارسی آغاز شده اند و در زمان خراب هنوز به تثبیت نرسیده اند ولی چون نقطه وارسی انجام شده است، پس حتما بخشی از آنها در حافظه مانا ثبت شده است و در هر دو حالت deferred mode و immediate mode به undo نیاز دارند. T4 و T5 تثبیت شده اند و در حالت immediate به redo نیاز ندارند. ولی در حالت deferred نقطه وارسی بخشی از T4 را به حافظه مانا منتقل کرده است و به undo نیاز دارد ولی T5 بعد از نقطه وارسی بوده و هیچ تاثیری بر روی حافظه مانا نداشته و نیازی به undo ندارد. T6 نیز در حالت immediate به undo نیاز دارد و در حالت deferred چون بعد از نقطه وارسی بوده به undo نیاز ندارد. پس کلید کاملا درست است.

در مورد سوال ۳۹ ، طرز تفکر جالبیه در مورد پروتکل ۲pl. در مورد این عبارت : "ولی در rigorous، تا زمان تثبیت تراکنش هیچ قفلی آزاد نخواهد شد و در نتیجه نیازی به دانستن درخواست های قفل در آینده ندارد." : نیگاه کنید سیستم پایگاه داده ذاتا از آینده تراکنش ها خبر نداره مگر اینکه تراکنش رو مجبور کنه از آینده کاریش سیستم رو مطلع کنه مثل پرتوکل Conservative، تویه ۲pl برای پیدا کردن نقطه قفل نیازی به دانستن داده های آینده نیست( بحز Conservative)، به محض رسیدن به یک دستور Unlock سیستم متوجه میشه که به این نقطه رسید است، چون تراکنش ها ممکن است دارای ساختار شرطی بسیار پیچیده باشه و امکان بررسی نقطه قفل از قبل واقعا کار دشواریه. لذا تمامی ۲PL ها( به جز Conservative) نیازی به دونستن درخواست های آینده تراکنش نمی باشد. نیگاه کنید نقطه قفل یک مفهوم فقطه منطقی است برای بررسی عملکرد تراکنش مطابق پروتکل کنترل همروندی و این نقطه در زمان اجرا مشخص میشه. شما هیچ زبانی رو پیدا نمیکنید که نقطه قفل رو بشه تو ساختار تراکنش مشخص نمود: Oracle, DB2, MySQL, Postgres و ... آره حرف شما درسته که در زمان اجرا نیازی به تثبیت نقطه قفل نیست تو روش Rigorous و این نقطه با رسیدن به تثبیت مشخص میشه اما این به معنی نیست که همه ۲pl ها مثل strict نیازی به دانستن قفل های آینده هستن، خود سیستم راحت میتونه به صورت ضمنی این نقطه پیداکنه. دانستن داده های آینده به معنی اجبار تراکنش به استفاده از دستوری جهت مشخص نمودن یه حالت خاص هستش متل Conservative. تویه Strict به رسیدن به دستور Unlock میشه فهمید به نقطه قفل رسیده و تویه Rigoroud با رسیدن به دستور Commit، این تنها تفاوت در پیدا کردن نقطه قفل توسط DBMS هستش.

در مورد سوال ۴۱ هم کاملا با شما موافقم و سوال مشکلی نداره.

نظرتون در مورد سوال ۴۲ چیه ؟ جواب این سوال گزینه ۴ میشه اما کلید گزینه ۳ رو زده !!
مطابق شکل داده شده، از روش فازی ساده جهت ایجاد نقطه وارسی Check Point استفاده شده است. در این روش، ابتدا یک نقطه شروع وارسی begin ایجاد شده و لیست تمامی صفحات تغییر یافته ثبت شده و سپس شروع به انقال این صفحات از حافظه اصلی به دیسک می شود. هنگامیکه انتقال تمامی صفحات به دیسک انجام شد یک نقطه اتمام وارسی End ثبت می شود و نشان می دهد که تمامی صفحات تغییر یافته قبل از نقطه Begin منتقل شده است. لذا اگر تراکنشی قبل از نقطه begin تثبیت شده باشد آنگاه وجود نقطه End بعد از آن ، نشاندهنده انتقال صفحات تراکنش بوده و لذا در صورت بروز خرابی بعد از نقطه End نیازی به redo کرده تراکنش نمی باشد( حتما صفحات آن به دیسک منتقل شده است).
مطابق تصویر داده شده، تمامی صفحات تغییر یافته از نقظه Begin-CheckPoint(n-1) به حافظه منتقل شده( به علت مشاهده End-CheckPoint(n-1) ) و لذا تمامی تراکنش های تثبیت شده قبل از نقطه Begin-CheckPoint(n-1) حتما به دیسک منتقل شده و نیازی به redo نمی باشد. گزینه ۳ صحیح نمی باشد؛ زیرا بین نقطه Begin-CheckPoint(n-1) و End-CheckPoint(n-1 اگر تراکنشی ثبیت شود، هنوز به دیسک منتقل نشده و این کار باید در ایجاد نقظه وارسی بعدی یعنی Begin-CheckPoint(n) انجام شود که در این نقطه نیز به علت عدم مشاهده End-CheckPoint(n) عملیات انتقال صفحات هنوز به طور کامل انجام نشده است. بعبارت دیگر، تنها توسط نقطه Begin صفحات تغییر یافته لیست شده و در صورت انتقال صحیح آنها نقطه End ثبت خواهد شد.
در منبع مربوطه ( رانکوهی) عبارت زیر به طور واضح ذکر شده است : " عمل Redo باید بعد از نقطه Begin-CheckPoint شروع شود. اما مطمئن هستیم که قبل از این رکورد حتما در پایگاه داده مانا وجود دارند"
نتیجه میگیرم در صورت مشاهده نقطه End برای یک نقطه Begin نیازی به redo برای تراکنش های تثبیت شده قبل از نقطه Begin نخواهد بود.

اقا یعنی منبع رانکوهی هست و سیلبرشاتس نیست ؟

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

[mos_hos]

(۱۸ اسفند ۱۳۹۵ ۰۹:۲۲ ق.ظ)esi2 نوشته شده توسط:  

(17 اسفند ۱۳۹۵ ۰۳:۲۰ ب.ظ)mos_hos نوشته شده توسط:  در اعتراضاتی که به کلید سازمان سنج شده بود، دیدم که اکثرا دوستان به سوالات ۳۹ و ۴۱ پایگاه داده معترض بودند. بنده رابطه بسیار نزدیکی با طراح سوالات دیتابیس امسال دارم و باید بگم که ایشون به هیچ وجه اشتباه نکرده است. ایشان کسی است که دکتر روحانی را متقاعد کرد که در چند مورد در مطالب کتابش اشتباه کرده است. بعید می دانم که اعتراضات در مورد سوالات دیتابیس نتیجه ای داشته باشد. تمامی سوالات به نظر من درست هستند.
در مورد سوال ۳۹ دیتابیس نکته ای که وجود دارد این است تمامی پروتوکل های ۲PL به جز rigorous به دانستن درخواست های خواندن و نوشتن تراکنش ها در آینده نیاز دارند. زیرا اگر درخواست های آینده تراکنش را ندانند، چگونه می توانند اطمینان حاصل کنند که تراکنش تمام قفل های مورد نیازش را دریافت کرده و می تواند به مرحله lock point وارد شود و قفلی را آزاد کند؟ به طور کلی ۲PL نیاز دارد در زمان lock point که قرار است قفلی آزاد شود، اطمینان حاصل شود که تراکنش دیگر هیچ درخواست قفلی نخواهد داشت.پس strict 2PL نیز به دانستن درخواست های قفل در آینده نیاز دارد. ولی در rigorous، تا زمان تثبیت تراکنش هیچ قفلی آزاد نخواهد شد و در نتیجه نیازی به دانستن درخواست های قفل در آینده ندارد. تفاوت conservative با سایر ۲PLها نیز در این است که در زمان شروع، به دانستن همه درخواست های قفل دارد ولی در سایر ۲PL ها چنانچه تراکنشی درخواست آزادسازی قفلی را بدهد، در آن زمان نیاز است تا بداند تراکنش دیگر در آینده به قفلی نیاز ندارد.
در مورد سوال ۴۱ نیز اینگونه است:
تراکنش T2 قبل از نقطه وارسی بوده است پس در هر دو حالت نیازی به undo یا redo ندارد. تراکنش های T1 و T3 هر دو قبل از شروع نقطه وارسی آغاز شده اند و در زمان خراب هنوز به تثبیت نرسیده اند ولی چون نقطه وارسی انجام شده است، پس حتما بخشی از آنها در حافظه مانا ثبت شده است و در هر دو حالت deferred mode و immediate mode به undo نیاز دارند. T4 و T5 تثبیت شده اند و در حالت immediate به redo نیاز ندارند. ولی در حالت deferred نقطه وارسی بخشی از T4 را به حافظه مانا منتقل کرده است و به undo نیاز دارد ولی T5 بعد از نقطه وارسی بوده و هیچ تاثیری بر روی حافظه مانا نداشته و نیازی به undo ندارد. T6 نیز در حالت immediate به undo نیاز دارد و در حالت deferred چون بعد از نقطه وارسی بوده به undo نیاز ندارد. پس کلید کاملا درست است.

در مورد سوال ۳۹ ، طرز تفکر جالبیه در مورد پروتکل ۲pl. در مورد این عبارت : "ولی در rigorous، تا زمان تثبیت تراکنش هیچ قفلی آزاد نخواهد شد و در نتیجه نیازی به دانستن درخواست های قفل در آینده ندارد." : نیگاه کنید سیستم پایگاه داده ذاتا از آینده تراکنش ها خبر نداره مگر اینکه تراکنش رو مجبور کنه از آینده کاریش سیستم رو مطلع کنه مثل پرتوکل Conservative، تویه ۲pl برای پیدا کردن نقطه قفل نیازی به دانستن داده های آینده نیست( بحز Conservative)، به محض رسیدن به یک دستور Unlock سیستم متوجه میشه که به این نقطه رسید است، چون تراکنش ها ممکن است دارای ساختار شرطی بسیار پیچیده باشه و امکان بررسی نقطه قفل از قبل واقعا کار دشواریه. لذا تمامی ۲PL ها( به جز Conservative) نیازی به دونستن درخواست های آینده تراکنش نمی باشد. نیگاه کنید نقطه قفل یک مفهوم فقطه منطقی است برای بررسی عملکرد تراکنش مطابق پروتکل کنترل همروندی و این نقطه در زمان اجرا مشخص میشه. شما هیچ زبانی رو پیدا نمیکنید که نقطه قفل رو بشه تو ساختار تراکنش مشخص نمود: Oracle, DB2, MySQL, Postgres و ... آره حرف شما درسته که در زمان اجرا نیازی به تثبیت نقطه قفل نیست تو روش Rigorous و این نقطه با رسیدن به تثبیت مشخص میشه اما این به معنی نیست که همه ۲pl ها مثل strict نیازی به دانستن قفل های آینده هستن، خود سیستم راحت میتونه به صورت ضمنی این نقطه پیداکنه. دانستن داده های آینده به معنی اجبار تراکنش به استفاده از دستوری جهت مشخص نمودن یه حالت خاص هستش متل Conservative. تویه Strict به رسیدن به دستور Unlock میشه فهمید به نقطه قفل رسیده و تویه Rigoroud با رسیدن به دستور Commit، این تنها تفاوت در پیدا کردن نقطه قفل توسط DBMS هستش.

در مورد سوال ۴۱ هم کاملا با شما موافقم و سوال مشکلی نداره.

نظرتون در مورد سوال ۴۲ چیه ؟ جواب این سوال گزینه ۴ میشه اما کلید گزینه ۳ رو زده !!
مطابق شکل داده شده، از روش فازی ساده جهت ایجاد نقطه وارسی Check Point استفاده شده است. در این روش، ابتدا یک نقطه شروع وارسی begin ایجاد شده و لیست تمامی صفحات تغییر یافته ثبت شده و سپس شروع به انقال این صفحات از حافظه اصلی به دیسک می شود. هنگامیکه انتقال تمامی صفحات به دیسک انجام شد یک نقطه اتمام وارسی End ثبت می شود و نشان می دهد که تمامی صفحات تغییر یافته قبل از نقطه Begin منتقل شده است. لذا اگر تراکنشی قبل از نقطه begin تثبیت شده باشد آنگاه وجود نقطه End بعد از آن ، نشاندهنده انتقال صفحات تراکنش بوده و لذا در صورت بروز خرابی بعد از نقطه End نیازی به redo کرده تراکنش نمی باشد( حتما صفحات آن به دیسک منتقل شده است).
مطابق تصویر داده شده، تمامی صفحات تغییر یافته از نقظه Begin-CheckPoint(n-1) به حافظه منتقل شده( به علت مشاهده End-CheckPoint(n-1) ) و لذا تمامی تراکنش های تثبیت شده قبل از نقطه Begin-CheckPoint(n-1) حتما به دیسک منتقل شده و نیازی به redo نمی باشد. گزینه ۳ صحیح نمی باشد؛ زیرا بین نقطه Begin-CheckPoint(n-1) و End-CheckPoint(n-1 اگر تراکنشی ثبیت شود، هنوز به دیسک منتقل نشده و این کار باید در ایجاد نقظه وارسی بعدی یعنی Begin-CheckPoint(n) انجام شود که در این نقطه نیز به علت عدم مشاهده End-CheckPoint(n) عملیات انتقال صفحات هنوز به طور کامل انجام نشده است. بعبارت دیگر، تنها توسط نقطه Begin صفحات تغییر یافته لیست شده و در صورت انتقال صحیح آنها نقطه End ثبت خواهد شد.
در منبع مربوطه ( رانکوهی) عبارت زیر به طور واضح ذکر شده است : " عمل Redo باید بعد از نقطه Begin-CheckPoint شروع شود. اما مطمئن هستیم که قبل از این رکورد حتما در پایگاه داده مانا وجود دارند"
نتیجه میگیرم در صورت مشاهده نقطه End برای یک نقطه Begin نیازی به redo برای تراکنش های تثبیت شده قبل از نقطه Begin نخواهد بود.

در پاسخ قبلی در مورد سوال ۳۹ من نظر شخصی خودم رو نوشتم. ولی گویا منظور طراح سوال همان conservative 2PL بوده و اشتباهی رخ داده است. دوست عزیز در مورد سوال ۳۹ حق با شماست و بنده هم با شما موافق هستم. به دلیل وجود ساختارهای شرطی پیچیده، ممکن است DBMS قادر به تشخیص درخواست های آینده تراکنش نباشد و به همین دلیل تفسیر منطقی تر به نظر اینگونه است: DBMS در زمان دریافت درخواستی برای آزادسازی یک قفل، بدون هیچ گونه بررسی درخواست های دریافت قفل توسط تراکنش در آینده، آن قفل را آزاد می کند و تراکنش به lock point خواهد رسید و چنانچه آن تراکنش در آینده دریافت قفلی را درخواست کند، آن تراکنش پروتکل ۲PL را نقض کرده است و توسط DBMS لغو خواهد شد. در نتیجه تنها در پروتکل conservative 2PL به دانستن read/write set تراکنش ها نیاز است. ولی باید بگم که گزینه ۴ هم صحیح نیست چون در rigorous ترتیب تثبیت تراکنش ها همان ترتیب توالی پذیری آنها است ولی در Strict 2PL چنین نیست و این یک مزیت حساب می شود. پس هیچ یک از گزینه ها صحیح نیست و احتمالا این سوال حذف خواهد شد.

در رابطه با سوال ۴۲ نیز حق با شماست و کلید اشتباه است. البته این اشتباه از سوی طراح نبوده و مقصر سنجش بوده است زیرا پاسخ اعلام شده از سوی طراح گزینه ۳ بوده است و سنجش گزینه ها را جابجا کرده ولی همچنان پاسخ را در کلید همان گزینه ۳ اعلام کرده است. من خودم کنکور شرکت نکردم و متوجه این اشتباه هم نشده بودم. و اگر به این اشتباه اعتراض نمی شد، به ضرر کسانی میشد که پاسخ درست رو زده بودند! پاسخ این سوال در کلید نهایی قطعا تغییر خواهد کرد.

[yasna2008]

(۱۷ اسفند ۱۳۹۵ ۰۳:۲۰ ب.ظ)mos_hos نوشته شده توسط:  در اعتراضاتی که به کلید سازمان سنج شده بود، دیدم که اکثرا دوستان به سوالات ۳۹ و ۴۱ پایگاه داده معترض بودند. بنده رابطه بسیار نزدیکی با طراح سوالات دیتابیس امسال دارم و باید بگم که ایشون به هیچ وجه اشتباه نکرده است. ایشان کسی است که دکتر روحانی را متقاعد کرد که در چند مورد در مطالب کتابش اشتباه کرده است. بعید می دانم که اعتراضات در مورد سوالات دیتابیس نتیجه ای داشته باشد. تمامی سوالات به نظر من درست هستند.
در مورد سوال ۳۹ دیتابیس نکته ای که وجود دارد این است تمامی پروتوکل های ۲PL به جز rigorous به دانستن درخواست های خواندن و نوشتن تراکنش ها در آینده نیاز دارند. زیرا اگر درخواست های آینده تراکنش را ندانند، چگونه می توانند اطمینان حاصل کنند که تراکنش تمام قفل های مورد نیازش را دریافت کرده و می تواند به مرحله lock point وارد شود و قفلی را آزاد کند؟ به طور کلی ۲PL نیاز دارد در زمان lock point که قرار است قفلی آزاد شود، اطمینان حاصل شود که تراکنش دیگر هیچ درخواست قفلی نخواهد داشت.پس strict 2PL نیز به دانستن درخواست های قفل در آینده نیاز دارد. ولی در rigorous، تا زمان تثبیت تراکنش هیچ قفلی آزاد نخواهد شد و در نتیجه نیازی به دانستن درخواست های قفل در آینده ندارد. تفاوت conservative با سایر ۲PLها نیز در این است که در زمان شروع، به دانستن همه درخواست های قفل دارد ولی در سایر ۲PL ها چنانچه تراکنشی درخواست آزادسازی قفلی را بدهد، در آن زمان نیاز است تا بداند تراکنش دیگر در آینده به قفلی نیاز ندارد.
در مورد سوال ۴۱ نیز اینگونه است:
تراکنش T2 قبل از نقطه وارسی بوده است پس در هر دو حالت نیازی به undo یا redo ندارد. تراکنش های T1 و T3 هر دو قبل از شروع نقطه وارسی آغاز شده اند و در زمان خراب هنوز به تثبیت نرسیده اند ولی چون نقطه وارسی انجام شده است، پس حتما بخشی از آنها در حافظه مانا ثبت شده است و در هر دو حالت deferred mode و immediate mode به undo نیاز دارند. T4 و T5 تثبیت شده اند و در حالت immediate به redo نیاز ندارند. ولی در حالت deferred نقطه وارسی بخشی از T4 را به حافظه مانا منتقل کرده است و به undo نیاز دارد ولی T5 بعد از نقطه وارسی بوده و هیچ تاثیری بر روی حافظه مانا نداشته و نیازی به undo ندارد. T6 نیز در حالت immediate به undo نیاز دارد و در حالت deferred چون بعد از نقطه وارسی بوده به undo نیاز ندارد. پس کلید کاملا درست است.

با سلام
سوال ۴۱ به نظر من توضیح شما دارای اشکالات زیادی هست، اول اینکه در روش deferred تا commit شدن تراکنش بروز رسانی که در پایگاه داده اعمال نمی شود و فقط در فایل log قرار می گیرد. در این جا گفتید چون قبل از check point هست پس تاثیراتی داشته بر روی حافظه مانا باز هم صحیح نیست، چون نقطه وارسی برای اینه که الگوریتم ریکاوری نخواد برگرده تموم پایگاه رو چک کنه و تکلیک اونهایی که commit شدن که مشخصه هست ریدو شدن ولی اونهایی که هنوز تثبیت نشدن باز هم تاثیری در پایگاه داده ندارد چون فقط در فایل ثبت نوشته شدند. در نهایت ما این روش رو NO UNDO/ REDO می گوییم چرا که به هیچ وجه نیازی به اندو نیست.

[nick2006]

سلام اگه میشه در مورد سوال ۳۶ هم توضیح بدید. در قفل گذاری چند اسلوبی عمل خواندن قفل اشتراکی داره و عمل نوشتن قفل انحصاری. وقتی سه تراکنش قفل خواندن روی D گذاشته باشند هیچکدام نمی توانند قفل نوشتن روی D بگذارند و بن بست بوجود میاد. در هر دو حالت مجاز بودن یا مجاز نبودن تبدیل قفل بن بست وجود دارد(گزینه ۱). ولی در کلید سنجش گزینه ۴ درست اعلام شده (در صورت مجاز نبودن تبدیل قفل مقدار D مساوی ۳۵ است وگرنه بن بست دارد)