خانه SQL Server Page split تا چه حد می تواند گران تمام شود SQL Server نوشته شده توسط: تورج عزیزی ۱۴ مهر ۱۳۹۴ زمان مطالعه: 10 دقیقه ۰ (۰) مقدمه این مقاله در مورد هزینه تحمیلی Page split بر Performance کلی دیتابیس است. از آنجایی که SQL Server باید نظم فیزیکی رکورد ها را بر اساس کلید ایندکس حفظ کند در صورتی که در Page مربوطه جایی برای گنجاندن رکورد جدید نباشد SQL Server باید حدود ۵۰% از رکوردهای درون Page را به Page ای جدید انتقال دهد تا جا برای رکورد جدید باز شود البته برای رکوردهای بزرگ ممکن است با یک Page split مشکل حل نشود و رکوردهای بیشتری نیاز به انتقال داشته باشند. البته یافتن فضای خالی در فایل دیتابیس و تخصیص Page هم هزینه دیگری است که Page split به همراه دارد. Page split همیشه عملی گران قیمت محسوب می شده است، اما تا چه حد؟ قصد دارم با استفاده از یک DMV به نام sys.dm_tran_database_transactions به شما نشان دهم وقتی یک page در یک ایندکس می بایست split شود تا چه حد log بیشتری در فایل transaction log تولید می شود. با این اسکریپت یک جدول با ردیف های تقریباً ۱۰۰۰ بایت می سازیم: CREATE DATABASE PageSplitTest; GO USE pagesplittest; GO CREATE TABLE BigRows (c1 INT, c2 CHAR (1000)); CREATE CLUSTERED INDEX BigRows_CL ON BigRows (c1); GO INSERT INTO BigRows VALUES (1, 'a'); INSERT INTO BigRows VALUES (2, 'a'); INSERT INTO BigRows VALUES (3, 'a'); INSERT INTO BigRows VALUES (4, 'a'); INSERT INTO BigRows VALUES (6, 'a'); INSERT INTO BigRows VALUES (7, 'a'); GO برای رکورد با مقدار c1 = 5 یک “شکاف” ایجاد کرده ایم. منظور از شکاف این نیست که جایش رزرو شده بلکه صرفاً این مقدار از نظر منطقی جا انداخته شده است. اجازه دهید با یک تراکنش Explicit یک رکورد دیگر را اضافه کنیم: BEGIN TRAN INSERT INTO BigRows VALUES (8, 'a'); GO SELECT [database_transaction_log_bytes_used] FROM sys.dm_tran_database_transactions WHERE [database_id] = DB_ID ('PageSplitTest'); GO database_transaction_log_bytes_used ———————————– ۱۲۲۸ مقدار لاگ تولید شده منطقی است و آن چیزی است که انتظارش را داشتیم. حالا اگر بخواهم رکورد با مقدار c1=5 را اضافه کنم این رکورد برای حفظ نظم فیزیکی رکوردها (البته از طریق slot array انتهای page) باید به همین Page اضافه شود، در اینجا Page split اتفاق می افتد: — commit previous transaction COMMIT TRAN GO BEGIN TRAN INSERT INTO BigRows VALUES (5, 'a'); GO SELECT [database_transaction_log_bytes_used] FROM sys.dm_tran_database_transactions WHERE [database_id] = DB_ID ('PageSplitTest'); GO database_transaction_log_bytes_used ———————————– ۶۷۲۴ Wow! ۵.۵ برابر لاگ بیشتر که ناشی از لاگ تراکنش سیستمی است که عمل Page split را انجام می دهد! این نرخ اگر اندازه ردیف کوچکتر شود می تواند بدتر هم بشود. برای ردیفی با اندازه ۱۰۰ بایت (از همان کد بالا استفاده کنید فقط به CHAR(100) تغییر دهید) ۶۷ ردیف را درج کنید و البته یک شکاف هم ایجاد کنید (یعنی یک کلید را جا بیندازید مثل c1=5 در بالا) با درج رکورد ۶۸ ام Page split روی میدهد و دو عدد برابر ۳۲۸ و ۵۹۲۴ خواهند بود (یعنی اندازه لاگ تولید شده قبل و بعد از Page split و البته در تست شما این مقادیر می تواند متفاوت باشد). Page split روی داده در این حالت ۱۸ برابر لاگ بیشتر تولید کرده! برای ردیفی با اندازه ۱۰ بایت من به دو عدد ۲۴۰ و ۱۰۴۳۶ رسیدم ، چون من داده های دارای انحراف در یونیک بودن تولید کردم: نوع دیتاتایپ را به CHAR(10) تغییر دادم و سپس مقادیر ۱ ، ۲، ۳ ، ۴، ۶ و ۷ را یکبار و مقدار ۸ را ۲۵۶ بار درج کردم و بعد دو بار مقدار ۵ را درج کردم که باعث روی دادن Page split از نوع non-middle شد (یعنی نصف رکوردهای انتقالی همگی یک مقدار داشتند (۸)). Storage Engine همیشه یک Page split از نوع ۵۰/۵۰ انجام نمی دهد بلکه عمل انتقال رکورد ها را تا آنجایی ادامه می دهد که فضای کافی برای رکورد جدید باز شود (یعنی چندین بار عمل انتقال می تواند صورت بگیرد). و در این حالت ۴۳ برابر لاگ بیشتر تولید شد! چه رتبه ای میدهید؟ میانگین ۰ / ۵. از مجموع ۰ اولین نفر باش برچسب ها # Page# Page split# Performance# SQL Server# آموزش SQL Server معرفی نویسنده مقالات 17 مقاله توسط این نویسنده محصولات 0 دوره توسط این نویسنده تورج عزیزی پروفایل نویسنده معرفی محصول مسعود طاهری دوره آموزشی Performance Tuning در SQL Server 5.700.000 تومان مقالات مرتبط ۰۴ مهر SQL Server دستور Case در SQL Server – قسمت اول محمد سلیم آبادی ۳۰ شهریور SQL Server استور پروسیجر (Stored Procedure) چیست؟ تیم فنی نیک آموز ۰۶ تیر SQL Server معرفی Ledger در SQL Server 2022 مسعود طاهری ۱۰ اردیبهشت SQL Server استفاده از Credential و Proxy در SQL Server Agent حسن سلیمانی دیدگاه کاربران لغو پاسخ دیدگاه نام و نام خانوادگی ایمیل ذخیره نام، ایمیل و وبسایت من در مرورگر برای زمانی که دوباره دیدگاهی مینویسم. موبایل برای اطلاع از پاسخ لطفاً مرا با خبر کن ثبت دیدگاه Δ تورج عزیزی ۱۸ / ۰۷ / ۹۴ - ۰۱:۲۱ یک مقاله فوق العاده برای مطالعه بیشتر: پاسخ به دیدگاه تورج عزیزی ۱۸ / ۰۷ / ۹۴ - ۰۱:۲۱ یک مقاله فوق العاده برای مطالعه بیشتر: پاسخ به دیدگاه Hamid J. Fard ۱۸ / ۰۷ / ۹۴ - ۰۱:۰۲ « Storage Engine همیشه یک Page split از نوع ۵۰/۵۰ انجام نمی دهد بلکه عمل انتقال رکورد ها را تا آنجایی ادامه می دهد که فضای کافی برای رکورد جدید باز شود» در رابطه با جمله بالا. نکته اینجاست که عمل ۵۰/۵۰ یک بار اجرا شده و بعد فضای کافی برای رکورد جدید چک می شود اگر رکورد جدید در datapage دوم جا نشود یک data page جدید ساخته شده و رکورد در آن جای می گیرد. مقاله خوبی بود. موفق باشید. پاسخ به دیدگاه Hamid J. Fard ۱۸ / ۰۷ / ۹۴ - ۰۱:۰۲ « Storage Engine همیشه یک Page split از نوع ۵۰/۵۰ انجام نمی دهد بلکه عمل انتقال رکورد ها را تا آنجایی ادامه می دهد که فضای کافی برای رکورد جدید باز شود» در رابطه با جمله بالا. نکته اینجاست که عمل ۵۰/۵۰ یک بار اجرا شده و بعد فضای کافی برای رکورد جدید چک می شود اگر رکورد جدید در datapage دوم جا نشود یک data page جدید ساخته شده و رکورد در آن جای می گیرد. مقاله خوبی بود. موفق باشید. پاسخ به دیدگاه مسعود طاهری ۱۸ / ۰۷ / ۹۴ - ۰۹:۵۱ عالی بود تورج جان. در ادامه این مبحث اگر وقت کردید DMV زیر را هم برای مانیتور کردن وضعیت Fragmentation ایندکس ها معرفی کنید https://msdn.microsoft.com/en-us/library/ms188917.aspx متشکرم پاسخ به دیدگاه مسعود طاهری ۱۸ / ۰۷ / ۹۴ - ۰۹:۵۱ عالی بود تورج جان. در ادامه این مبحث اگر وقت کردید DMV زیر را هم برای مانیتور کردن وضعیت Fragmentation ایندکس ها معرفی کنید https://msdn.microsoft.com/en-us/library/ms188917.aspx متشکرم پاسخ به دیدگاه 1 2