درباره نویسنده

مسعود طاهری

مسعود طاهری

عاشق علیرضا (پسرم) و همسرم. در ضمن SQL Server را هم دوست دارم.

62 Comments

  1. Mostapha

     متاسفانه فیلم صدا نداره. یا لااقل روی سیستم من صدا نداره

    پاسخ دادن
    1. فرید طاهری

      فرید طاهری

       سلام
      فیلم از بابت صدا مشکلی ندارد. شاید چون MP4 هست باید Codec نصب کنید روی سیستم خودتان. البته شاید.
      ولی الان باز دانلود کردم و صدا کاملا گویا هست.

      موفق باشید

      پاسخ دادن
  2. بهزاد عبادی

    خسته نباشید جانانه به تمامی تیم بزرگ نیک اموز

    پاسخ دادن
  3. حسین خوش رفتار منفرد

    حسین خوش رفتار منفرد

     جواب سوال ۱ :

    در جداول کوچک fragmentation نمیتونه تاثیر زیادی روی بازدهی داشته باشه. چرا که تخصیص  هشت page اول از بسط ترکیبی بهره میبره و این میتونه در هرجایی از دیتابیس قراربگیره. هرمقدار هم که rebuild صورت بگیره در این فرآیند تغییر حاصل نمیشه. 
    بهترین نتیجه معمولا وقتی حاصل می شود که حداقل ۱۰۰۰تا page وجود داشته باشد سپس rebuild انجام شود. در حقیقت این عمل در یک آستانه خاص باید انجام بشه تا بهترین نتیجه رو داشته باشه.
    جواب سوال۲ :
    به دلیل استفاده از nolock .  هنگامی که صفحه ای split می شود،برروی  تمامی داده های آن تاثیر گذاشته  میشود حتی آنهایی که دقیقا مربوط به رکورد مورد نظر نیستند. البته بستگی به حالت page split و نحوه ذخیره سازی داده هم دارد.
    پاسخ دادن
    1. مسعود طاهری

      مسعود طاهری

      حسین جان سلام

      پاسخ شما کاملا درست و علمی بود
      متشکر
      پاسخ دادن
  4. حسین خوش رفتار منفرد

    حسین خوش رفتار منفرد

    ادامه جواب۲ : راهکاری جایگزین استفاده از nolock استفاده از Snapshot isolation level است. با این روش کاربران در حال خواندن از بانک مزاحم کاربران در حال نوشتن در بانک نمیشوند و تاثیر بسزایی در کاهش lock block ها خواهد داشت.

    پاسخ دادن
  5. رامین

    جواب سوال اول)

    این موضوع بر میگرده به اندازه ایندکس. در ابتدا تعداد Page های جدول ۹ تا است و دیتاهای وارد شده هر کدوم بخشی از این ۹ صفحه رو
    پر کرده اند و بنابراین اندازه fragment_count =page_count شده است. با Rebuild کردن ایندکس تمامی داده ها Defrag ‌شده اما
    همچنان پراکندگی وجود داره (fragment_count=4). Rebuild
    کردن های بعدی هم بعلت کوچک بودن سایز ایندکس توسط SQL Server نادیده گرفته می شوند و بنابراین بی تاثیر خواهند بود. دلیل این امر هم این هست که ایندکس های با سایز
    کوچک بر روی mixed extent ها ایجاد
    می شوند و از اونجا که این نوع extent ها توسط اشیاء دیگر هم
    مورد استفاده اشتراکی قرار می گیرند ممکن است rebuild یا reorganize باعث کاهش میزان پراکندگی
    نشود.

    جواب سوال دوم)

    شما با نوشتن عبارت With(NoLock)‌ در
    واقع سطح Isolation Level رو به ReadUnCommited تغییر داده اید. با این کار گرچه میزان همزمانی
    تراکنش ها بالا رفته اما به تراکنش Select این امکان رو دادید که بتونه داده های Commit نشده
    سایر تراکنش ها رو هم بخونه که در این صورت احتمال بروز خطا در داده های واکشی شده
    بالا رفته. این کار همون خوندن داده های کثیف یا Read dirty
    data است.
    برای جلوگیری از این شرایط کافیه که سطح Isolation Level رو بر روی یکی از گزینه های Snapshot یا Read
    Commited‌قرار بدید.

    پاسخ دادن
    1. مسعود طاهری

      مسعود طاهری

      جناب رامین عزیز

      پاسخ شما هم کاملا صحیح است. فقط اگر در قسمت دوم هم به مسئاله Page Split اشاره می کرده اید نور علی نور می شد. 
      خیلی عالی
      پاسخ دادن
  6. سید سیاوش گلچوبیان

    سید سیاوش گلچوبیان

     سلام و تشکر از ویدیو خوب شما. در جواب سوال اول باید گفت اگر، از TF 1118 استفاده نکرده باشیم، به صورت پیش فرض هشت Page اول دیتا (۶۴ کیلوبایت اول) در Mixed Extent ها ذخیره میشوند (و دستور Rebuild بر روی Page های درون Mixed Extent نمیتوانند اقدام موثری انجام دهند زیرا Page های جداول دیگر نیز در آن وجود دارد و آنها را Move نمیکند) و زمانیکه حجم دیتای جدول بیش از ۶۴KB شد SQL Server دیگر از Uniform Extent ها جهت ذخیره سازی استفاده میکند (و این جایی است که دستور Rebuild اثر گذار میشود)، به همین دلیل معمولا جداول کوچک Fragmentation های بالایی دارند.

    در پاسخ به سوال دوم نیز، با توجه به آنکه در جدول به طور مداوم در حال Insert هستیم و همچنین بر روی جدول Index نیز داریم، پس طبیعتا همزمان با درج یا حتی آپدیت رکورد های جدول فرایند به روز شدن ایندکس ها را نیز داریم و از آنجا که کلید ایندکس ما بدلیل استفاده از GUID به صورت فزاینده-ترتیبی (Sequential) نمیباشد، پس مدام با مشکل Page Split (نصف شدن Page ها) در ایندکس ها روبرو میشویم (چه ایندکس ما کلاستر باشد و چه نباشد این اتفاق رخ میدهد)، حال وقتی با With (Nolock) اقدام به کوئری زدن میکنیم، مشکل Page Split خود را در حین Range Scan/Allocation Scan نشان میدهد و باعث میشود که رکوردهای کمتر یا گاها رکوردهای تکراری (بیشتر) خوانده شوند. راه حل نیز میتواند عدم استفاده از Nolock یا استفاده از Isolation Level باشد
    (متاسفانه نوشتن از صحبت کردن خیلی سخت تره و بیشتر حوصله طلب میکنه، به همین دلیل از کم بودن توضیح عذر خواهی میکنم)

    پاسخ دادن
    1. مسعود طاهری

      مسعود طاهری

       سیاوش جان پاسخ شما کاملا درست و علمی است

      شما دقیقا مثل حسین عزیز پاسخ کامل را ارئه داده اید.
      متشکرم
      پاسخ دادن
  7. سپهر صفایی

     پاسخ سوال اول:
    به دلیل اینکه با ساخت جدول برای بار اول ۸ page به جدول اختصاص داده می شود و دیتای این جدول ناچیز می باشد و در همین ۸ page گنجانده شده است و این جحم دیتا برای defrag شدن ناچیز می باشد. بهتز است ReIndex برای حداقل ۱۰۰۰page انجام شود.

     پاسخ سوال دوم:

    مشکل به دلیل وجود  PK جدول از نوع GUID می باشد و دستور NEWID به صورت ترتیبی Incremental عمل نمی کند. و داده ها در Index به همان ترتیبی که توسط دستور insert ذخیره شده اند ذخیره نمی شوند. 
    راه حل می توانید درون اپلیکیشن از دستورات C# جهت ایجاد GUID ترتیبی استفاده نمایید.
    پاسخ دادن
    1. مسعود طاهری

      مسعود طاهری

      جناب صفای پاسخ شما هم درست بود

      درباره پساخ اول شما باید بگم درست به بحث Mixed Extent اشاره ای نشده است. اما باز هم پاسخ شما مورد قبول بود.
      در مورد پاسخ دوم شما هم باید بگم بلی روش ارائه شده توسط شما می تواند مشکل را رفع کند. البته لزومی هم نیست که GUID را از سورس ارسال کرد. می توان با تابع NewSequentialID بوسیله Default Value هم در SQL اینکار را انجام داد.
      اما در هر حال پاسخ های خوب شما در حوزه پاسخ های درست قرار گرفته است.
      موفق باشید
      پاسخ دادن
  8. علی حاجی آبادی

    علی حاجی آبادی

     1- با توجه به نوع ایندکس (Primary key و  Unique CLUSTERED INDEX) مشخصا داده های موجود در فیلدهای تاثیرگذار در ایندکس، منحصر بفرد هستند – یعنی هیچ دو رکوردی (در مثال در فیلد RecordID) داده یکسان ندارند، در نتیجه Fragmentation این نوع ایندکسها (PKey ها) از مقدار مشخصی کمتر نخواهد شد

    ۲- وقتی در یک دستور Select از کیورد (WITH (NOLOCK استفاده میشود، رکوردهایی که transaction آنها هنوز COMMIT نشده اند، خوانده میشوند – یعنی داده هایی که ممکن است هرگز در بانک ثبت نشوند خوانده میشوند – اتفاقی که در حلقه loop مثال زده شده رخ میدهد

    پاسخ دادن
  9. مجتبی شهریور

    مجتبی شهریور

     سلام
    من دانلود کردم  عالی بود
    امیدوارم برنده بشم

    پاسخ دادن
    1. فرید طاهری

      فرید طاهری

       سلام. متشکرم از شما
      برای برنده شدن در مسابقه بایستی پاسخ ارسال کنید.

      پاسخ دادن
  10. بهرام رمضانی

     پاسخ ۱ : از انجا که بعد از هر بار پاک کردن فرگمنشن در واقع دیتا های موجود در page های دیتابیس مرتب شده و فضای اضافی موجود در انها پاک می شود پس بعد از یک بار اعمال کردن این دستور دیگر فضای زایدی وجود ندارد و این عدد ثابت می ماند.
    پاسخ ۲ : به دلیل استفاده از WITH(NOLOCK) در کوئری مذکور مشکل ایجاد می شود.زیرا متغیر سالاری توسط چندین کوئری که اجرا کرده ایم در حال تغییر هست و نیز از transaction استفاده نمی شود و متغیر سالاری بین این اجراهای ما در واقع به نوعی به اشتراک گذاشته می شود و ممکن است در لحظه اتمام یک اجرا ان متغیر توسط اجرایی دیگر تغییر کند.یعنی ممکن است در لحظه اتمام اجرا ۱۰۰ باشد ولی در یک لحظه توسط کوئری که هنوز تمام نشده است به ۹۰ تبدیل شود و جواب کوئری تمام شده ۹۰ شود و راه حل این است که باید هر کوئری در یک ترانزکشن جدا اجرا شود و بدن دستور nolock

    پاسخ دادن
  11. بشیر محمودی

     پاسخ سوال ۱: به علت اینکه تعداد پیج های جدول ۸ عدد است. و ظاهرا sql  8 صفحه اول ایندکس ها و جداول را از extent های غیر یکپارچه استفاده می کند. و ممکن است که همه پیج ها از یک extent نباشند می توان گفت که ممکن است که حداکثر ۸ فراگمنت برای هر پیج داشته باشیم.

    پاسخ سوال ۲: به علت دستور WITH(NOLOCK) ممکن است یک ردیف را دوبار یا بیشتر بخوانیم یا اصلا نخوانیم.

    پاسخ دادن
    1. مسعود طاهری

      مسعود طاهری

       آقای محمودی عزیز پاسخ اول شما درست است. این موضوع همان مسئاله Mixed Extent است. در مورد پاسخ دوم هم باید بگم که شما به یکی از مباحث مهم هم اشاره کرده اید همان بحث Duplicate Record در With Nolock است. 

      استفاده از With Nolock در شرایطی ممکن است باعث Duplicate Record شود. دقیقا همین شرایط مثال که با بوجود آمدن Page Split بوجود می آید.
      در هر حال پاسخ شما جزء پاسخ های صحیح بود
      موفق باشید
      پاسخ دادن
  12. محسن ولی زاده

     

        

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

    پاسخ سوال ۲: به نظر میرسه برای جواب به این سوال باید به سراغ شیوه اجرای کوئری ها در اس کیو ال سرور رفت. از اونجاییکه هر رکورد بیشتر از یک کیلوبایت فضا میگیره و قراره ۵۰۰۰۰۰ بار این رکورد درج ببشه، حجم فایل دیتابیس به سرعت رشد میکنه و چون ایندکس بر روی کلید اصلی صورت میگیره و کوئری بر اساس فیلد دیگری جستجو میشه، ضمن اینکه کوئری ها به صورت موازی در حال اجرا شدن هستند و نتیجه حاصله زمان زیادی از سی پی یو را مصرف می کند، احتمالا اس کیو ال سرور از استراتژی های دیگری برای جستجو استفاده می کند. به نظر میرسه در این حالت، اس کیو ال سرور از بافر یا Cache جواب را استخراج کرده باشد. یا شاید اتفاق دیگری رخ می دهد که من نمیدانم! (مثلا هنگام ثبت نظر با مرورگر اینترنت اکسپلورر پیغام “خطا: لطفا دیدگاهتان را بنویسید.” ظاهر می شود!!)

    پاسخ دادن
  13. محمد آریان پور

    پاسخ سوال ۱: هشت پیج اول در mixed extends قرار می گیرند و rebuild کردن روی آنها تاثیر ندارد.

    پاسخ سوال ۲: هنگامی که از nolock استفاده می کنیم ممکن است dirty read داشته باشیم به همین دلیل جواب دقیق نمی شود. که به جای آن میتوان از READPAST استفاده کرد.
    پاسخ دادن
  14. مهدی حاجی میرزایی

    سوال ۱)

    فکر می کنم
    چون فیلد RecordData ایندکس ندارد. وقتی که ایندکس را  Rebuild فیلد  RecordData فرگمنت نمی شود
    یا یکی از دلایلش این است که فرگمنت به طول اندازه فایل که دیتابیس انجام می دهد و چون داده ما تغییری نکرده  یا  سایز فایل دیتابیس تغیر نکرده این درصد ثابت می ماند

    سوال ۲)
    چون که از دستور WITH(NOLOCK) استفاده کردید به این معنا وقتی که
    رکوردی درحال پردازش یا خواندن باشد این رکورد را نمی بیند که این عمل
    باعث میشه Query از رکوردهایی که lock هستند عبور کنه پس شاید همه رکوردها رو نبینین
    و برای راه کار می تو به جای nolock از دستور WITH(READPAST) استفاده کرد

    پاسخ دادن
  15. آرمان فلاح

      پاسخ سوال ۱ : به خاطر کوچک بودن حجم ایندکس ، در واقع REBUILD کردن روی ایندکس های که Page_count کوچکتر از ۱۰۰۰ است کار اضافی است و تاثیری روی عملکرد دیتابیس ندارد 

    پاسخ سوال ۲ : به خاطر وقوع Page Split است که در query از with no lock استفاده شده است و به این حالت dirty read اصطلاحا گفته می  شود و به جای استفاده از no lock می توان از Isolation Levelهای  READ COMMITTED , SNAPSHOT استفاده کرد (در SNAPSHOT lock هم اتفاق نمی افتد)
    پاسخ دادن
    1. مسعود طاهری

      مسعود طاهری

      آرمان عزیز
      راه حل دوم شما اوکی بود. پاسخ اول شما هم درست است. نکته ای هم که باعث بوجود آمدن این مشکل در سوال یک شده است mixed Extent است. اما در هر حال پاسخ شما هم پذیرفته شد.
      موفق باشید
      پاسخ دادن
  16. ابوذر عسگری

     پاسخ سوال ۱:

    اصولا کلید اصلی جدول نحوه چیدمان فیزیکی درج رکورد ها در پیج ها مشخص می کند لذا معمولا به صورت Identity در نظر می گیرند که سیستم خودش تولید نماید و به صورت مرتب و پشت سرهم می باشد حالا با توجه به همین تئوری می توان گفت به دلیل اینکه کلید اصلی مرتب نمی باشد فرگمنتیشن از یک سطح کمتر نخواهد شد.
    پاسخ سوال ۲:
    به دلیل مسائل مربوط به Transaction می باشد چون در دستور sum از with(nolock)  استفاده شده و همزمان در یک session دیگه عملیات درج رکورد در حال اتفاق می باشد جدول در سطح رکورد قفل می باشد که اصطلاحا رکورد کثیف گفته می شود به همین دلیل در زمان هایی یک به دلیل قفل بودن خوانده  نمی شود و خروجی عدد ۹۰ را نشان می دهد.
    پاسخ دادن
  17. حمیدقلیپور

    حمیدقلیپور

     با سلام و احترام

    استاد گرامی باید بگم که آموزش شما بسیار عالی بود و خیلی واضح، اما حیف که فعلا سطح دانشم به اندازه سوالات مطرح شده نیست. سعی میکنم با گذراندن دوره های شما به سطح علمی بسیار بالایی در حوزه بانک اطلاعاتی برسم.
    پاسخ دادن
    1. مسعود طاهری

      مسعود طاهری

      سلام حمید جان

      با پشتکاری که شما دارید إن شاء الله به زودی به هدف خود خواهید رسید
      موفق باشید

      پاسخ دادن
  18. علی رحیمیان

    علی رحیمیان

     سلام.

    جواب ۱: عملیات Rebuild ایندکس ها را مرتب می کند تا فضایی page ها مرتب شود و فضای خالی کمتری اشغال کنند.
    پس با یک بار Rebuild کردن ایندکس ها Fragmentation کاهش پیدا می کند و page ها  ایندکس مرتب می شوند. حال با تکرار این دستور اثری روی Fragmentation نخواهد گذاشت چون پیج ها مرتب هستند.

    جواب ۲: دقت داشته باشد ما از دستور WITH(NOLOCK) استفاده کرده ایم.
    در این مساله عملیات درج پیوسته در حال انجام است. به طور همزمان چند عملیات select با WITH(NOLOCK) در یک حلقه در حال اجراست.

    من این مسئله رو با این تغییر نیز تست کردم:
    INSERT INTO Employees (EmployeeID,Salary) VALUES ( CAST(RAND() * 1000000 AS INT), 5)
    بازهم جواب ۹۰ ویا ۱۱۰ می شود. یعنی مقادر ۱۰ یکی از رکورد های قدیمی ۱ کم یا یکی بیشتر خوانده می شود.

    اگر قرار بود که یکی از رکورد ها جدید رو اشتباها می شد مقدار باید ۹۵ یا ۱۰۵ باشد.

    در حالتی که مقدار ۹۰ می شود: احتمالا یکی از لیست های پیوندی پیج ها قدیمی که در حال بروز رسانی است گم شود.

    ودر حالتی که مقدار ۱۱۰ می شود: به نظر میرسد که در زمان درج یک رکود حالتی وجود دارد که آدرس پیج رکورد جدید با یکی از پیج های رکوردی که قبلا ذخیره شده است برابری میکند و احتمالا سیستم اشتباها مقدار رکورد قدیمی رو دوباره میخواند.

    پاسخ دادن
    1. مسعود طاهری

      مسعود طاهری

      جناب رحیمیان عزیز 

      تست شما برای سوال دوم هم درست بود. در برخی مواقع عدد ۱۱۰ به عنوان نتیجه بر می گردد. قفل شن صفحه را درست تشخصیص داده اید. 
      باید این رو هم اضافه کنیم که Page Split باعث بوجود آمدن این مشکل شده است. و در این حالت With Nolcok باعث خواندن دوباره شدن یک رکورد شده است که شما عدد ۱۱۰ را در نتیجه گرفته اید. 
      پس باید این رو بدانیم که With NoLock در برخی مواقع باعث بوجود آمدن Duplicate Record می شود.
      موفق باشید
      پاسخ دادن
  19. عباس لایقی

    سلام و تشکر از سایت بسیار خوب شما
    This is by-design.

    For small tables, usually performance impact
    on fragmentation is undectable. The first 8 page allocation would be
    from mixed extents and mixed extents could be anywhere in database
    files. Rebuilding indexes would not change this nature.

    If you
    have a small table, those mixed pages weight a lot during fragmentation
    calculation; therefore, rebuilding index may not reduce fragmentation.
    (As matter of fact, I could easily construct a case that fragmentation
    increases after rebuild.) Those fragmentation would not be a pain for
    your query performance; so basically you can ingore them.

    When
    page counts of an index reaches to certain big size (for example, 1000
    pages), then fragmentation may start to impact performance. Rebuilding
    index should reduce fragmentation.

    Another thing to consider is
    that how high the fragmentation is. If it is < 10%, it is hard for
    rebuilding to reduce more (we never could 100% guarantee that you can
    reach 0% fragmentation; with mixed page allocation, it is a hard goal to
    achieve).

    If you don’t care about space utilization, you can
    use undocumented trace flag 1118 to disable mixed page allocation, but I
    am not recommend it (this trace flag usually is used in tempdb for
    reducing SGAM contention).

    پاسخ دادن
  20. هادی جباری دارستانی

     پاسخ سوال اول :

    با توجه به اینکه شما فیلد RecordData رو nvarchar(8000) در نظر گرفتید
    و با استفاده از دستور
    Replicate یک کلمه ی ۴ حرفی رو تکرار کردی حجم هر
    رکورد میشه حدود ۷۲۰۰ بایت

    و از اون طرف هر Page در SQL 8 کیلوبایت
    هستش و هر رکورد بالا در یک
    Page قرار میگیرد این در صورتی است که هر رکورد
    ۹۰ درصد فضای یک پیج رو اشغال میکند به همین دلیل در زمان
    Rebuild کردن ایندکس
    هیچ وقت نمیتواند فضای خالی را با رکورد دیگری پر کند و همیشه ایندکس پراکنده می
    ماند.

     

    پاسخ سوال دوم :

    با توجه به اینکه یکی از کارهای اصلی ایندکس مرتب سازی
    رکوردها میباشد در زمان درج رکورد جدید مرتب سازی رکورد ها در ایندکس همچنان پابرجاست
    یعنی وقتی رکورد جدیدی درج میکنیم
    SQL این رکورد را در جای مناسب خود بین رکورد
    های موجود در ایندکس قرار میدهد و در این زمان باعث میشود
    Page هایی که این
    رکورد ها در آن قرار دارند لاک شوند

    در مثال برای فیلد PK جدول نوع GUID در نظر گرفته
    شده است و بنابر توضیحات بالا مرتب سازی ایندکس روی این فیلد انجام میگیرد

    زمانی که ۵۰۰ هزار رکورد شروع به درج شدن میکنند با توجه به
    اینکه
    GUID جدید ایجاد میشود ممکن است بین رکورد هایی که EmployeeID آنها برابر با
    -۱ باشد درج شوند و باعث جابجایی رکوردها و
    Lock شدن Page ها شوند که
    مورد باعث اختلال میشود

    برای جلوگیری از این مشکل دو روش پیشنهاد میشود

    ۱-     
    تغییر در طراحی جدول و استفاده از PK با نوع INT  و Auto
    Identity

    در این
    روش هیچگاه مرتب سازی رکورد ها لازم نیست و در نتیجه لاک بودن و جابجایی رکوردها
    را نداریم چون تمامی رکوردها بعد از ۱۰ رکوردی که
    EmployeeID آنها -۱ میباشد
    درج میشوند

    ۲-     
    گذاشتن یک ایندکس روی جدول Employee بر روی فیلد
    های
    EmployeeID , Salary و غیر فعال کردن Page Lock روی این ایندکس

    پاسخ دادن
    1. مسعود طاهری

      مسعود طاهری

      جناب جباری عزیز 

      در مورد پاسخ دوم شما باید اشاره کنم که به نکته Page Split اشاره کرده اید و راه حلی هم که ارائه داده اید درست بود اگر مقدار GUID یا کلید به صورت Sequential باشد مسئاله Page Split نخواهیم داشت.
      در هر حال پاسخ های شما جزء پاسخ صحیص بوده است
      موفق باشید
      پاسخ دادن
  21. tiyara9090@hotmail.com

    tiyara9090@hotmail.com

     سلام
    مرسی از آموزش خوبتون استاد طاهری واقعا عالی بود
    آموزش sql server 2016 کی شروع می کنید

    پاسخ دادن
    1. مسعود طاهری

      مسعود طاهری

      سلام

      إن شاء الله به زودی. در حال آماده سازی مطالبدوره هستیم
      پاسخ دادن
  22. e.ak

     پاسخ سوال ۱ به دلیل اینکه تغییرات dml در بانک اطلاعاتی رخ نداده مقدار fragmantaion تغییر نکرده و پس از هر بار اجرا همانمقدار قبلی را نشان نمیدهد

    پاسخ سوال ۲  در دستوراجراشده از with noclockاستفاده است و باعث می شود که داده صحیحی را نشان نداده و عدد ۹۰ هم به خاطر همین موضوع نشان داده و به دلیل اینکه یکی از آدی ها تغییرکرده ودر مجموع عدد۹۰ را نشان میدهد.
    پاسخ دادن
  23. ساناز احمدی

    ساناز احمدی

     سلام
    عالی بود ولی کاش هرچهزود تر آموزش sql server2016 را شروع می کردید

    پاسخ دادن
  24. زهرا کوچکیان

    سلام باید حوابها  از کجا وارد کنیم

    پاسخ دادن
    1. مسعود طاهری

      مسعود طاهری

      سلام

      جواب ها را باید در همین صفحه وارد کنید. 
      پاسخ دادن
  25. زهرا کوچکیان

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

    WITH (ONLINE = ON)

    بعد از REBUILD نیز کمی تفاوت وجود دارد اما باز هم به تکرار نتیجه میرسیم.

    جواب سوال دوم
    به نظر من علت این است که رکوردها در حال تکثیر زیادی هستند در زمان خیلی کم وبا استفاده از یک INDEX special_ix
    روی employeed idفکر میکنم مشکل برطرف شود البته شاید استفاده از group by نیز موثر باشد

    پاسخ دادن
  26. saeed zarei -سعید زارعی

    saeed zarei -سعید زارعی

     سلام

    پاسخ سوال ۲ : این مورد مربوط به Phantom Reads در مبحث مشکلات همزمانی میباشد و راه کار آن استفاده از بهینه ساز Serializable یا HoldLock در پرس و جو   و یا قراردادن کدها در تراکنش به صورت زیر است :

    set tran isolation levelSerializable

    begin tran

    پاسخ دادن
  27. مهران رحمتی

     پاسخ سئوال اول = به خاطر DataType فیلد ان می باشد که اگر از نوع متناسبتر و کوچکتر استفاده شود مشکل یکپارچه سازی اندیکس حل میشود

    پاسخ دادن
  28. saeed zarei -سعید زارعی

    saeed zarei -سعید زارعی

     سلام

    جواب سوال اول : از آنجایی که حجم هر پیج ۸KB است و حجم هر رکورد طبق سوال حدود ۷۲۰۸ بایت ، بنابراین در هر Page فقط یک رکورد ذخیره میشود و رکورد بعد در صفحه جدید ذخیره میشود .
    با این تفاسیر حدود ۸۰۰ بایت از هر صفحه خالی میباشد که بنده این را پاسخ سوال یک میدانم . و راه حل استفاده از FileGroup  میباشد . چون داده های مربوط به ستون RecordData حجم بالایی را دارند و میتوان آنها را جزو LOB در نظر گرفت .

    جواب سوال دوم رو حدود ۶ یا ۷ ساعت قبل ارسال کردم .  داشتم به سوال اول فکر میکردم . برای همین جواب ها رو باهم ارسال نکردم .

    با تشکر از زحمات شما

    پاسخ دادن
  29. هادی ناصحی

    ابتدا سلام می کنم به اعضای محترم سایت نیک آموز

    و تشکر می کنم از مدرس محترم آقای مسعود طاهری.
    جواب سوال اول:
    با توجه به اینکه تعداد داده ها کم است و حجم ایندکس هم بسیار کوچک است یعنی کمتر از ۸ پیج است SQL ازحالت mixed extents استفاده   lمی کند و اجازه می دهد پیجهای جداول دیگر هم در این extents قرار گیرد البته برای ایندکسهای کوچک فرگمنتیشن قابل اغماض است.اما اگر حجم ایندکس جدول رشد کرده و بیشتر از ۸ پیج شود به Uniform Extent سویچ کرده و فقط داده های یک جدول را در این اکستنت قرار می دهد. 

    به شکل زیر دقت کنید:

    Mixed and uniform extents

    ۲٫ جواب سوال دوم به آیزولیشن لول بر می گردد البته من دلیل دقیق را نتوانستم تشخیص دهم اما چون آیزولشن لول در حالت  Read Uncommited است(بدلیل استفاده از With Nolock)  حالت Dirty Read اتفاق افتاده است.
    پاسخ دادن
    1. مسعود طاهری

      مسعود طاهری

      سلام هادی جان 
      تصویری که گذاشته اید خیلی عالی بود. سوال دوم هم تا حدی درست تشخیص داده اید اما اگر کمی روی آن وقت می گذاشتید جواب کاملی می توانستید ارائه کنید. در هر حال خیلی خوب بود
      موفق باشید
      پاسخ دادن
  30. محمد

    سلام

    قرار بود امروز جواب مسابقه رو اعلام کنید. پس چی شد؟
    پاسخ دادن
    1. فرید طاهری

      فرید طاهری

       سلام
      جواب دوستان را راس ساعت ۲۰ امشب منتشر خواهیم کرد.

      پاسخ دادن
  31. مجتبی شهریور

    مجتبی شهریور

     سلام
    ضمن تشکر مجدد استاد طاهری عزیز
     دوستانی که تمایل دارن بیشتر در زمینه این شاهکار اطاعات کسب کنن یا حداقل یک پیش زمینه داشته باشن این مقاله خوبا ستاد طاهری را اول حتما مطالعه بفرمایند
    مقاله :

    پاسخ دادن
  32. حامد آتشبار

     با سلام. 

    در جواب سوال ۱ به نظر من fragmentation تو جداول کوچیک تاثیری نداره.  و  تو این کوئری ۸ صفحه از ایندکس اجرا میشه. و با هربا اجرای دوباره کوئری همون ۸ صحفه اول ساخته میشن. برای اینکه نتیجه بهتری بگیریم باید اینکس بیشتر از ۱۰۰۰ صفحه داشته باشه.
    سوال دوم : زمانی که داده ای در داخل sql در حال اجرا ششدن یا ویرایش میباشد. sql با حال قفل کردن کنترولی بر رو ی اجرای دستور دارد تا زمانی که یک کوئری اجرا شود دستور دیگری برا روی آن  کوئری اجرا نگردد اما زمانی که ما از دستور NOLOCK استفاده می کنیم عملا کنترول را از sql  می گیریم و زمانی که دستور for  را بر رو داده ها انجام می دهیم و همزمان دستور دیگری را نیز اجرا می کنم باعث نمایش نتایج متفاوتی می شود. 
    اما راهکار آن : استفاده از snapshop Isolation  بجای nolock

    پاسخ دادن
    1. مسعود طاهری

      مسعود طاهری

      حامد جان 

      راه کاری که برای پاسخ دوم ارائه داده اید اوکی است. استفاده از Snapshot می تواند مشکل را حل کند. پاسخ اول شما هم مورد تایید است. عامل این موضوع هم همان بحث Mixed Extent است
      پاسخ دادن
  33. حامد آتش بار

    حامد آتش بار

    سلام. من جواب رو فرستادم پس چرا تو سایت قرار نگرفت.

    پاسخ دادن
  34. هادی ناصحی

    جناب طاهری لطف می کنید خودتون هم جواب رو بفرمایید تا مغایرتها رو بدونیم.

    متشکرم
    پاسخ دادن
  35. معصومه کارور

     سلام. اگه ممکنه پاسخهای صحیح و اسم برنده ها رو اعلام بفرمایید

    پاسخ دادن
  36. مسعود طاهری

    مسعود طاهری

     سلام

    از همه دوستانی که در مسابقه شرکت کرده اند متشکرم
    برای ما مهم این بود که دوستان در مسابقه شرکت کنند. برای شروع استقبال عالی است.
    باز هم از شما دوستان عزیز متشکرم
    موفق باشید
    پاسخ دادن
    1. فریبرز دلیری

         سلام
      حسین آقا ی تماسی بگیر بابا

      پاسخ دادن
  37. حکیمه حاتمی

       باسلام و خسته نباشید ممنون از راهنمایتون.

    پاسخ دادن
  38. جواد

        سلام خسته نباشید

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

      مسعود طاهری

          سلام

      ۱-ایا بکاپ از دیتابیس خود دارید؟
      ۲- Recovery Model مربوط به لاگ فایل خود را بررسی کنید
      ۳- آیا لاگ بکاپ دارید؟
      در صورتیکه Log Backup داشته باشید می توانید با انجام عملیات Point In Time Recovery  به داده های قبل از تغییر دسترسی پیدا کنید. (البته باید لاگ بکاپ و شرایط اون را داشته باشید).
      با این قابلیت می توانید دیتابیس را به یک ساعت خاص (مثلا قبل از انجام دستور Update برگردونید و….)
      در غیر این صورت باید به backupها قدیمی مراجعه کنید و ببینید دیتا قبلی وجود دارد و یا خیر
      پاسخ دادن
  39. جواد

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

    ریکاوری مدل روی simple است بانک پیش خودم نیست روی یک هاست راه دور است 
    نمیشه از رکورد هایی که از تابع fn_dblog بدست میاد برگردوند؟
    پاسخ دادن
    1. مسعود طاهری

      مسعود طاهری

          سلام

      می توانید از برنامه زیر استفاده کنید البته به لاگ فایل نیاز دارید
      ترجیحا بروید سراغ بکاپ
      پاسخ دادن
      1. مجید افتخاری

        مجید افتخاری

           ممنون از پاسختون.

  40. محسن اکبری

    محسن اکبری

    استاد عزیز ، فایل در زمان ٍExtract ، ارور میدهد .

    پاسخ دادن
    1. آرزو محمدزاده

      آرزو محمدزاده

      با سلام و عرض ادب
      فایل بررسی و مشکلی نداشت لطفا نسخه نرم افزار فشرده ساز خود را به آخرین نسخه ارتقا دهید و سپس دوباره تست نمایید.

      پاسخ دادن

ارسال نظر

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

تمامی حقوق مادی و معنوی این وب سایت متعلق به نیک آموز می باشد.
این سایت توسط تیم آموزش برنامه نویسی نیک آموز مدیریت می شود.