این مقاله در مورد هزینه تحمیلی Page split بر Performance کلی دیتابیس است. از آنجایی که SQL Server باید نظم فیزیکی رکورد ها را بر اساس کلید ایندکس حفظ کند در صورتی که در Page مربوطه جایی برای گنجاندن رکورد جدید نباشد SQL Server باید حدود 50% از رکوردهای درون Page را به Page ای جدید انتقال دهد تا جا برای رکورد جدید باز شود البته برای رکوردهای بزرگ ممکن است با یک Page split مشکل حل نشود و رکوردهای بیشتری نیاز به انتقال داشته باشند.
البته یافتن فضای خالی در فایل دیتابیس و تخصیص Page هم هزینه دیگری است که Page split به همراه دارد.
Page split همیشه عملی گران قیمت محسوب می شده است، اما تا چه حد؟ قصد دارم با استفاده از یک DMV به نام sys.dm_tran_database_transactions به شما نشان دهم وقتی یک page در یک ایندکس می بایست split شود تا چه حد log بیشتری در فایل transaction log تولید می شود.
با این اسکریپت یک جدول با ردیف های تقریباً 1000 بایت می سازیم:
|
[sql] CREATE DATABASE PageSplitTest; CREATE TABLE BigRows (c1 INT, c2 CHAR (1000)); INSERT INTO BigRows VALUES (1, ‘a’); |
برای رکورد با مقدار c1 = 5 یک “شکاف” ایجاد کرده ایم. منظور از شکاف این نیست که جایش رزرو شده بلکه صرفاً این مقدار از نظر منطقی جا انداخته شده است.
اجازه دهید با یک تراکنش Explicit یک رکورد دیگر را اضافه کنیم:
|
[sql] BEGIN TRAN SELECT [database_transaction_log_bytes_used] FROM sys.dm_tran_database_transactions database_transaction_log_bytes_used |
مقدار لاگ تولید شده منطقی است و آن چیزی است که انتظارش را داشتیم.
حالا اگر بخواهم رکورد با مقدار c1=5 را اضافه کنم این رکورد برای حفظ نظم فیزیکی رکوردها (البته از طریق slot array انتهای page) باید به همین Page اضافه شود، در اینجا Page split اتفاق می افتد:
|
[sql] — commit previous transaction BEGIN TRAN SELECT [database_transaction_log_bytes_used] FROM sys.dm_tran_database_transactions database_transaction_log_bytes_used |
Wow!
5.5 برابر لاگ بیشتر که ناشی از لاگ تراکنش سیستمی است که عمل Page split را انجام می دهد! این نرخ اگر اندازه ردیف کوچکتر شود می تواند بدتر هم بشود. برای ردیفی با اندازه 100 بایت (از همان کد بالا استفاده کنید فقط به CHAR(100) تغییر دهید) 67 ردیف را درج کنید و البته یک شکاف هم ایجاد کنید (یعنی یک کلید را جا بیندازید مثل c1=5 در بالا) با درج رکورد 68 ام Page split روی میدهد و دو عدد برابر 328 و 5924 خواهند بود (یعنی اندازه لاگ تولید شده قبل و بعد از Page split و البته در تست شما این مقادیر می تواند متفاوت باشد). Page split روی داده در این حالت 18 برابر لاگ بیشتر تولید کرده!
برای ردیفی با اندازه 10 بایت من به دو عدد 240 و 10436 رسیدم ، چون من داده های دارای انحراف در یونیک بودن تولید کردم:
نوع دیتاتایپ را به CHAR(10) تغییر دادم و سپس مقادیر 1 ، 2، 3 ، 4، 6 و 7 را یکبار و مقدار 8 را 256 بار درج کردم و بعد دو بار مقدار 5 را درج کردم که باعث روی دادن Page split از نوع non-middle شد (یعنی نصف رکوردهای انتقالی همگی یک مقدار داشتند (8)). Storage Engine همیشه یک Page split از نوع 50/50 انجام نمی دهد بلکه عمل انتقال رکورد ها را تا آنجایی ادامه می دهد که فضای کافی برای رکورد جدید باز شود (یعنی چندین بار عمل انتقال می تواند صورت بگیرد).
و در این حالت 43 برابر لاگ بیشتر تولید شد!
با توجه به مطالب بالا مطمئن هستم که به دوره آموزشی Performance Tuning علاقه مند هستید
منبع: آموزش برنامه نویسی نیک آموز
9 دیدگاه
مسعود طاهری
عالی بود تورج جان.
Hamid J. Fard
« Storage Engine همیشه یک Page split از نوع ۵۰/۵۰ انجام نمی دهد بلکه عمل انتقال رکورد ها را تا آنجایی ادامه می دهد که فضای کافی برای رکورد جدید باز شود»
در رابطه با جمله بالا. نکته اینجاست که عمل 50/50 یک بار اجرا شده و بعد فضای کافی برای رکورد جدید چک می شود اگر رکورد جدید در datapage دوم جا نشود یک data page جدید ساخته شده و رکورد در آن جای می گیرد.
مقاله خوبی بود.
موفق باشید.
تورج عزیزی
یک مقاله فوق العاده برای مطالعه بیشتر:
تورج عزیزی
http://www.sqlballs.com/2012/08/how-to-find-bad-page-splits.html
حمید ج. فرد
البته این موضوع رابطه خیلی شدید و نزدیکی با fill factor دارد
تورج عزیزی
و البته یک نکته بسیار مهم دیگر هم اینکه در حین انجام عمل Page Split ، پیج حاوی رکورد ها با استفاده از Latch قفل شده و تراکنش هایی که درخواست انجام خواندن یا نوشتن روی این Page دارند Block می شوند.
en.bakhtiari@yahoo.com
راه حل این مشکل هم اگر بیان می شد خوب بود
مسعود طاهری
1- Rebuild یا Reorganize کردن ایندکس ها (با توجه به شرایط)
محسن بندامیر
مقاله جالبی بود.
اما در حالت Char(100 فکر کنم منظورتون 77 و 78 بوده به جای اعداد 67و68 چون هر صفحه 8060 Byte فضا داره و هر رکوردمون شده اینجا 104 Bye در نتیجه: 8060/104=77.5