خانه SQL Server دیگر نگران Fragmentation نباشید!!! SQL Server افزایش سرعت SQL Server نوشته شده توسط: میلاد فیروزی تاریخ انتشار: ۰۳ بهمن ۱۳۹۴ آخرین بروزرسانی: ۱۹ بهمن ۱۴۰۰ زمان مطالعه: 9 دقیقه ۴.۷ (۳) مقدمه خوب خیلی ها حتما اصطلاح Fragmentation را شنیده اید و نگران این مساله هستید که شاید Index های شما هم دچار این مساله شده باشند! فکر می کنم بهتر است ابتدا کمی عقب تر رفته و روی مفهوم Fragmentation تمرکز کنیم تا ببینیم دقیقا مشکل کجاست و از چه چیزی ناشی می شود. فرض کنید Index های شما عملکردی مشابه دفترچه تلفن داشته باشد ، اگر صفحه ای پر شده باشد ناچارید یا فشرده بنویسید و یا اگر این کار ممکن نباشد مجبور می شوید برگه ای سفید در انتهای دفترچه تلفن به نام های جدید اختصاص بدهید که این کار باعث به هم خوردن ترتیب اطلاعاتتان می شود و با دو مشکل بزرگ روبرو خواهید شد، یک صفحه ی جدید اضافه شده که اطلاعات کمی روی آن قرار دارد (Internal Fragmentation) ترتیب صفحات دفترچه تلفن شما به هم می خورد (External Fragmentation) خوب شاید در این حالت دفترچه تلفن شما چیزی شبیه شکل زیر بشود یک راه حل پیش پا افتاده می تواند این باشد که صفحات دفترچه تلفن خود را به نحوی پر کنید که در هر صفحه کمی فضای خالی وجود داشته باشد ، به این ترتیب اگر نام جدیدی اضافه شد می تواند در این فضای خالی جای بگیرد ولی خوب این راه حل خراب شدن دفترچه تلفن را به تعویق می اندازد و نمی تواند کامل جلوی این اتفاق را بگیرد ، SQL Server هم عملی مشابه را با مفهوم Fill Factor انجام می دهد ، با معین کردن درصد Fill Factor به SQL می گوییم که صفحاتمان تا چند درصد پر باشند تا کمی فضای خالی برای درج رکوردهای جدید وجود داشته باشد. آپدیت کردن رکوردها هم می تواند مشکل ساز شود ، فرض کنید خانم Pat Down که تا دیروز مجرد بود و نامش در ردیف D قرار داشت امروز با آقای Phil McCann ازدواج می کند و نام خانوادگی اش به McCann تغییر می کند ، حال باید نام وی از ردیف D پاک شود و در ردیف M جا داده شود ، DELETEها هم به دلیل جا گذاشتن فضای خالی مشکل ساز می شوند.(Internal Fragmentation) Fragmentation چگونه می تواند به عملکرد SQL Server آسیب بزند؟؟؟! Internal Fragmentation بد (داشتن فضاهای خالی زیاد در صفحات) بدان معناست که Index شما از آن اندازه ای که می بایست بزرگتر شده است. به جای اینکه دفترچه تلفن ما ۱۰۰۰ صفحه ای که صد در صد پر هستند ممکن است ۱۱۰۰ صفحه داشته باشیم که ۹۰درصد پر باشند و این بدان معناست که هر زمان نیاز باشد که Index را Scan کنیم ۱۰% بیشتر طول خواهد کشید و چون SQL صفحات خالی را نیز Cache می کند این باز هم بدان معناست که به ۱۰% حافظه RAM بیشتر برای Cache کردن اطلاعات نیازمندیم.پایین ترین سطح Caching در SQL Server یک صفحه می باشد نه یک رکورد. External Fragmentation بد نیز دردسرهای خودش را دارد ، عملکرد ذخیره سازی کندتر خواهد شد ، SQL به جای اینکه صفحات را به ترتیب پیمایش کند مجبور است تا صفحات را به خاطر رکوردهای متفاوت عقب و جلو پیمایش کند. رفع مشکل Fragmentation به صورت موقت مشکل Fragmentation را می توان توسط Rebuild و یا Reorganize کردن ایندکس ها برطرف نمود ، خیلی ها این کار را با Maintenance Plan انجام می دهند ، مشکلی که این برنامه دارد این است که تمامی ایندکس های شما را بدون این که ضرورت یا عدم ضرورت این کار را در نظر بگیرد Rebuild یا Reorganize می کند. ممکن است از آخرین باری که این کار انجام شده روی برخی از جداول شما حتی یک رکورد هم Insert نشده باشد Maintenance Plan این نکته را هم نادیده می گیرد. خوب این مساله مشکلاتی را به همراه دارد ، Rebuild و یا Reorganize کردن ایندکس ها باعث می شود تا SQL Server در Transaction Log بنویسد و حجم Log شما افزایش یابد ، هرچقدر این Log بزرگتر شود Log Backupها بیشتر طول خواهد کشید ، اطلاعات بیشتری را برای بحث Mirroring می بایستی از طریق Network انتقال دهیم و Restoreها بیشتر طول خواهد کشید. اتفاق های ناگوارتری هم ممکن است رخ دهد ، برخی از DBAها تصمیم می گیرند تا Fill Factor را مقدار کمتری در نظر بگیرند مثلا ۵۰% . با این کا رنصف هر صفحه خالی خواهد ماند و Insertها سریع تر خواهد شد ولی اتفاقی که می افتد این است که Readها دوبرابر کند تر خواهد شد.فرض کنید دفترچه تلفنتان بجای ۱۰۰۰ صفحه پر ۲۰۰۰ صفحه نیمه پرداشته باشد. رفع مشکل Fragmentation به طور دایم خوب می توانیم با Cache کردن دیتابیس و یا حداقل اطلاعاتی که بیشتر در دسترس هستند شروع کنیم ، External Fragmentation (ترتیب نادرست صفحات در دیسک) تا زمانی که اطلاعات را از رم می خوانیم اهمیتی ندارند ، اطلاعات رو Cache کرده و خیال خودتان را راحت کنید ، ۳۴۸ گیگ رم چیزی حدود ۱۵ میلیون تومان آب خواهد خورد. Queryهای خود را بررسی کنید و ببینید آیا Query که واقعا تعداد فراخوانی آن زیاد بوده و گیر ایندکس های شما می باشد دارید یا خیر؟ اگر داشتید به فکر اصلاح ایندکس ها باشید ، همیشه Rebuild و یا Reorganize کردن ایندکس ها اولین راه حل نیست. می توانید توسط Query زیر درصد Fragmentation ایندکس های خود را بفهمید و روی آن ها تصمیم بگیرید ، معمولا برای عددی بین ۵ تا ۳۰ Reorganize کردن و برای عددی بالای ۳۰ Rebuild کردن پیشنهاد می شود ، ولی یادتان باشد این فرمول همیشه درست نیست و بهتر است همیشه خودتان ایندکس ها را با توجه به Queryهایتان بررسی کنید و به عنوان یک DBA بهترین تصمیم را بگیرید. SELECT dbschemas.[name] as 'Schema', dbtables.[name] as 'Table', dbindexes.[name] as 'Index', indexstats.avg_fragmentation_in_percent, indexstats.page_count FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL) AS indexstats INNER JOIN sys.tables dbtables on dbtables.[object_id] = indexstats.[object_id] INNER JOIN sys.schemas dbschemas on dbtables.[schema_id] = dbschemas.[schema_id] INNER JOIN sys.indexes AS dbindexes ON dbindexes.[object_id] = indexstats.[object_id] AND indexstats.index_id = dbindexes.index_id WHERE indexstats.database_id = DB_ID() ORDER BY indexstats.avg_fragmentation_in_percent desc چه رتبه ای میدهید؟ میانگین ۴.۷ / ۵. از مجموع ۳ اولین نفر باش معرفی نویسنده مقالات 8 مقاله توسط این نویسنده محصولات 0 دوره توسط این نویسنده میلاد فیروزی معرفی محصول مسعود طاهری آموزش ۳ در ۱ Performance Tuning در SQL Server 6.700.000 تومان 5.700.000 تومان مقالات مرتبط ۰۸ شهریور SQL Server اهمیت مانیتورینگ در SQL Server چیست؟ | تمام آنچه که باید از مانیتورینگ بدانید تیم فنی نیک آموز ۰۳ شهریور SQL Server اعمال گواهینامه SSL روی SQL Server تیم فنی نیک آموز ۳۱ مرداد SQL Server دستور Rank در SQL Server ؛ کلید حل معمای رتبه بندی تیم فنی نیک آموز ۲۵ مرداد SQL Server نرم افزار (Microsoft SQL Server Management Studio (SSMS چیست؟ تیم فنی نیک آموز دیدگاه کاربران لغو پاسخ دیدگاه نام و نام خانوادگی ایمیل ذخیره نام، ایمیل و وبسایت من در مرورگر برای زمانی که دوباره دیدگاهی مینویسم. موبایل برای اطلاع از پاسخ لطفاً مرا با خبر کن ثبت دیدگاه Δ پرهام ۳۰ / ۰۳ / ۰۱ - ۰۳:۳۷ اینجاست که باید پرسید لیلی زن بود یا مرد👌😂😊 ببینید به نظر من باز هم مثل همیشه این یک trade-off هست و باید با سبک و سنگین کردن وضعیتی که شما از پروژه خودتون درک کردین یکسری انتخاب ها رو انجام بدید پاسخ به دیدگاه جواد زبیدی ۱۳ / ۱۱ / ۹۴ - ۰۵:۲۷ رفع مشکل Fragmentation به طور دایم الان راه حل خرید رم بود یا اینکه من به عنوان DBA تصمیم بگیرم که چه موقع Rebuild یا Reorganize کنم؟ پاسخ به دیدگاه مسعود طاهری ۰۴ / ۱۱ / ۹۴ - ۱۰:۳۹ حمید با توجه به اینکه امکان پاسخ تو در تو تا ۸ سطح فعال مجبور شدم ادامه بحث را اینجا … من تست کردم در ۲۰۱۴ هم رفتار این گونه است. (تخصیص فضا) پاسخ به دیدگاه فرشید علی اکبری ۰۴ / ۱۱ / ۹۴ - ۱۰:۱۲ سلام خاطرم هست که حدود سه سال پیش در انجمن سابق نیک آموز، آقای مسعود طاهری مقدار FillFactor برای جداول بزرگ با عملیات CRUD بالا را بین ۸۰-۸۵ توصیه کرده بودند ولی شما بین ۷۰-۸۰. دلیل فنی این تفاوت چی می تونه باشه و در کل برای سیستم های اتوماسیون اداری که با زیاد شدن تعداد مشتریان و استفاده کنندگان از آن، امکان مواجه شدن با اینگونه مشکلات برای برنامه نویس وجود داره، بهتره مقدار Fillfactor ایندکس (های) جداول مورد نظر روی چه عددی تنظیم شود؟ پاسخ به دیدگاه Hamid J. Fard ۰۴ / ۱۱ / ۹۴ - ۱۰:۲۴ برای تمامی ایندکس های نباید یک مقدار تعیین شود. اگر جدول شما تغییرات زیاد دارد این مقدار باید بین ۷۰ تا ۸۰ باشد تا از عملیات Page Split جلوگیری شود. همانطور که گفتم هزینه عملیات Page Split , Forwarded Records بیشتر از این است که یک مقدار حافظه بیشتر تخصیص داده شود. تیم سازنده در مایکروسافت مقدار ۷۰ را پیشنهاد می کنند. پاسخ به دیدگاه مسعود طاهری ۰۴ / ۱۱ / ۹۴ - ۱۰:۵۶ سلام این مقدار مابین است. در نظر داشته باشید توصیه مفید و دقیق این گونه است. به یکبار مقدار را کاهش ندهیم. کم کم شروع به کاهش کنید و مدام مانیتور کنید تا به یک مقدار مناسب برسید. پاسخ به دیدگاه مسعود طاهری ۰۴ / ۱۱ / ۹۴ - ۱۰:۵۵ در نظر داشته باشید که وجود فضای خالی بیش از حد در Pageها باعث بوجود آمدن Internal Fragmentation شده که این موضوع دردسرهای خاص خودش را به همراه دارد پاسخ به دیدگاه مهدی ربانی ذبیحی ۰۴ / ۱۱ / ۹۴ - ۰۷:۵۷ با سلام و تشکر از مقاله خوبتون.من هم با دوست عزیز موافقم در صورت خروجی pdf ماندگاری مقالات بیشتر میشه با تشکر پاسخ به دیدگاه Hamid J. Fard ۰۴ / ۱۱ / ۹۴ - ۰۵:۰۸ متاسفانه مقاله مشکلات تکنیکی داشت که در نکته نظر ها گفتم. به هر حال برای شروع خوب است. نکته اول: ” با معین کردن درصد Fill Factor به SQL می گوییم که صفحاتمان تا چند درصد پر باشند تا کمی فضای خالی برای درج رکوردهای جدید وجود داشته باشد.” نکته اینجا است که فضای خالی برای تغییرات رکوردهای موجود در صفحه است نه درج رکورد جدید. Fillfactor از عملیات Page Split جلوگیری می کند و در نتیجه از External Fragmentation. نکته دوم: هیچ data page نباید ۱۰۰ درصد پر باشد به دلیل به وجود آمد عملیات Page Split و Forwarded Records که هزینه ای بیش از استفاده مازاد حافظه را دارد. اصولا Fillfactor برای جداول با تغییرات بالا باید بین ۷۰ تا ۸۰ باشد. پاسخ به دیدگاه مسعود طاهری ۰۴ / ۱۱ / ۹۴ - ۰۸:۰۲ سلام حمید جان متشکر از نظرات خوبت به نظر من این موضوع برای رکورد جدید هم صدق می کند مثال زیر را در نظر بگیرید تا جایی که یادم می آید در کتاب Pro SQL Server Internals به این موضوع هم اشاره شده است. (البته شک دارم اسم کتاب را) USE tempdb GO IF OBJECT_ID(‘TB1’)>0 DROP TABLE TB1 GO CREATE TABLE TB1 ( C1 CHAR(900), C2 CHAR(1100) ) GO –ایجاد ایندکس CREATE CLUSTERED INDEX IX1 ON TB1 (C1) WITH (FILLFACTOR=70) GO –درج تعدادی رکورد در جدول این ۳ رکورد در یک پیچ ذخیره می شوند INSERT INTO TB1 (C1) VALUES (‘100’) GO INSERT INTO TB1 (C1) VALUES (‘400’) GO INSERT INTO TB1 (C1) VALUES (‘600’) GO –درج تعدادی رکورد در جدول این ۳ رکورد در یک پیچ دیگر ذخیره می شوند INSERT INTO TB1 (C1) VALUES (‘900’) GO INSERT INTO TB1 (C1) VALUES (‘1000’) GO INSERT INTO TB1 (C1) VALUES (‘1100’) GO –مشاهده پیج های تخصیص یافته به جدول DBCC IND(‘tempdb’,’TB1′,-1) WITH NO_INFOMSGS GO –هر کدام از رکوردها در چه پیچی درج می شوند SELECT * FROM TB1 AS T CROSS APPLY sys.fn_PhysLocCracker(%%physloc%%) AS FPLC ORDER BY FPLC.file_id, FPLC.page_id, FPLC.slot_id GO –درج تک رکورد جدید INSERT INTO TB1 (C1) VALUES (‘200’) GO –هر کدام از رکوردها در چه پیچی درج می شوند –اگر دقت کنید برای درج رکورد جدید پیجی تخصیص داده نشد –Using Fillfactor SELECT * FROM TB1 AS T CROSS APPLY sys.fn_PhysLocCracker(%%physloc%%) AS FPLC ORDER BY FPLC.file_id, FPLC.page_id, FPLC.slot_id GO پاسخ به دیدگاه Hamid J. Fard ۰۴ / ۱۱ / ۹۴ - ۰۸:۲۲ و البته اینکه شما فقط دارید در ستون اولی داده وارد می کنید و ستون دوم به صورت Nullable است پاسخ به دیدگاه مسعود طاهری ۰۴ / ۱۱ / ۹۴ - ۰۹:۳۸ سلام تا جایی که به خاطر دارم دیتا تایپ های Fixed Length حتی اگرمقدارشان Null باشد فضای خود را در Data Page اشغال می کنند. پاسخ به دیدگاه Hamid J. Fard ۰۴ / ۱۱ / ۹۴ - ۰۹:۲۶ مسعود جان به نظر میاد مطالب را فراموش کردی! 🙂 بهتر است که یک مروری بکنی در داخل Record Structure ستونهای Null چه Fixed Length و چه var Length اگر خالی باشند فقط ۲ بایت فضا اشغال می کنند. مسعود طاهری ۰۴ / ۱۱ / ۹۴ - ۰۹:۵۹ سلام مجدد حمید جان به این لینک نگاه کنید http://weblogs.sqlteam.com/mladenp/archive/2007/09/06/How_does_SQL_Server_really_store_NULL-s.aspx اگر بخواهیم که این فضا واقعا در Page تخصیص داده نشود باید سراغ Sparse Column برویم که دردسرهای خاص خودش را دارد Hamid J. Fard ۰۴ / ۱۱ / ۹۴ - ۱۰:۰۹ البته در نظر داشته باشید که مقاله این که شما منبع دادید برای SQL Server 2005 است که درست است ولی از SQL Server 2008 به بعد روند اختصاص داده در Storage Engine تغییر کرده است. مسعود طاهری ۰۴ / ۱۱ / ۹۴ - ۰۲:۳۲ سلام حمید جان من این موضوع را تست کردم در SQL Server 2014 هم دیتا تایپ Fixed Length دقیقا فضای کامل را اشغال می کند حتی اگر Null باشد. موفق باشید بابک جهانگیری ۱۳ / ۰۲ / ۹۵ - ۱۲:۴۵ لطفا وضعیت را در SQL Server 2016 نیز تست بفرمایید که آیا Fixed Length بازهم فضای کامل را اشغال می کند؟ مسعود طاهری ۱۵ / ۰۲ / ۹۵ - ۰۶:۲۷ یک نکته دیگر بابک عزیز اگر بخواهید SQL SERVER از این فضا صرف نظر کند می توانید از Sparse Column و در برخی موارد Data Compression را استفاده کنید. البته توجه داشته باشید رفتن به سمت هر کدام چالش و… خود را به همراه دارد مسعود طاهری ۱۳ / ۰۲ / ۹۵ - ۱۰:۳۶ بابک عزیز سلام بلی این قانون در SQL Server 2016 هم وجود دارد این موارد به ریز در دوره Performance Tuning بررسی شده است. موفق باشید مسعود طاهری ۰۴ / ۱۱ / ۹۴ - ۰۹:۰۹ البته بهتر است که دیتا تبدیل به Varchar شود. اما اگر مطمئن هستیم که واقعا دیتا دقیقا طولش ثابت است و همیشه همان فضا را اشغال می کتد و درصد Null Value کم است بهتر است Fixed Length دیتا تایپ استفاده کنیم. Hamid J. Fard ۰۴ / ۱۱ / ۹۴ - ۰۸:۴۳ مسعود جان این مثالی که شما گذاشتید به دلیل وجود CHAR است حالا اگر ما بیایم نوع داده ای را به VarChar تغییر دهیم رکوردهای بیشتری جای می شود ولی اگر یکی از رکورد ها را به روز رسانی کنیم و مقدار fillfactor 100 باشد باعث Page Split می شود. در مثال شما به دلیل اینکه حجم صفحه به ۷۰ درصد رسیده است رکوردهای جدید را به صفحه جدید منتقل می کند. پاسخ به دیدگاه مسعود طاهری ۰۴ / ۱۱ / ۹۴ - ۰۹:۵۵ بلی دقیقا به خاطر اینکه این مورد را نشان دهم از قصد دیتا تایپ Char که از نوع Fixed Length است را ایجاد کردم. در خصوص Varchar هم همین جریان وجود دارد. (استفاده Fillfactor به ازای درج رکورد جدید). در مثال شما به دلیل اینکه حجم صفحه به ۷۰ درصد رسیده است رکوردهای جدید را به صفحه جدید منتقل می کند. اگر دقت کنید رکورد آخر که درج شد به جای تخصیص یک Page جدید در Page مربوط به خودش جا گرفت. بنابراین Page جدیدی به ازای آن ایجاد نشده است و Fragmentation رخ نداده بلکه مسئاله Fill factor به ازای Insert صدق می کند. نکته که شما هم فرمودید درست است Fillfactor صفر و صد یکی هستند پاسخ به دیدگاه کیوان معینی ۰۳ / ۱۱ / ۹۴ - ۰۸:۳۹ سلام خسته نباشید و سپاس خدمت نویسنده مقاله بابت این مقاله مفید و کاربردی .و همچنین تقدیر از مدیران خوش برخورد و متین سایت نیک آموز( یه پیشنهاد : لطفا اگه براتون مقدوره برای صفحات مقاله ،خروجی pdf بزارین . بازم ممنون) پاسخ به دیدگاه حمیدقلیپور ۰۴ / ۱۱ / ۹۴ - ۰۶:۵۹ با سلام بنده با نظر شما کاملا موافقم و چند بار این درخواست از مدیریت محترم انجام دادم اما نمیدونم چرا صورت نگرفت. امیدوارم که این امر محقق بشود. پاسخ به دیدگاه سپهر صفایی ۰۳ / ۱۱ / ۹۴ - ۰۱:۲۹ با سلام در مورد جمله “ Rebuild و یا Reorganize کردن ایندکس ها باعث می شود تا SQL Server در Transaction Log بنویسد ” باید بگم که این جمله کاملا صحیح است ولی برای جلوگیری از این مشکل می توان قبل از Rebuild کردن ایندکس ها RecoveryModel دیتابیس را به حالت Bulk-logged تغییر داد و بعد از اتمام Rebuild به حالت اولیه بازگرداند که با گذاشتن این فرآیند در قالب یک Job شبانه کاملا هم مشکل حجم لاگ هم مشکل ایندکس ها قابل حل می باشد. پیشاپیش از زحمات شما در این سایت سپاسگذارم پاسخ به دیدگاه Hamid J. Fard ۰۴ / ۱۱ / ۹۴ - ۰۶:۵۲ نکته این جا است که اگر شما Recover Model را به Bulked-Logged تغییر دهید تمامی Data Page هایی که تغییر داده شده اند در Log Backup خواهند بود. این عملیات بازهم تاثیر در عملیات Mirroring و Backup گیری فایل تراکنش دارد. پاسخ به دیدگاه مسعود طاهری ۰۴ / ۱۱ / ۹۴ - ۱۲:۲۲ سلام حمید جان باید به این نکته توجه داشته باشیم کهپروسه Mirroring به علت مکانیزم داخلی خود و… اجازه نمی دهد که شما Recovery Model بانک اطلاعاتی را تغییر دهید (نیاز به Recovery Model= Full دارد) نکته ۱ – تغییر Recovery Model باعث کاهش حجم لاگ می شود و نکاتی که حمید گفت هم برای این موضوع صحیح است (بکاپ) ۲- زمانی که شما Always-ON و Mirroring دارید اجازه تغییر Recovery Model را ندارید و نمی توان به صورت عادی Recovery Model را از حالت Full خارج کرد. چون این پروسه ها به شدت از لاگ فایل استفاده می کنند و… موفق باشید پاسخ به دیدگاه قاسم گل میری ۱۴ / ۱۱ / ۹۴ - ۱۱:۲۵ اگر plan bakup به این صورت باشد که در طول روز log bakup بگیرید تغییر Recovery Model توصیه نمیشود چون باعث شکستن chain های log bakup میشود. پاسخ به دیدگاه مسعود طاهری ۱۴ / ۱۱ / ۹۴ - ۰۷:۵۶ سلام در تکمیل حرف حمید مراحل کار را می توانید به صورت زیر انجام دهید Step 1. Take a T-log backup, before switching to Bulk-logged recovery Step 2. Set Database to Bulk-logged recovery Step 3. Perform Bulk-logged operations Step 4. Set Database to FULL Step 5. Again, take a T-log backup سپهر صفایی ۱۴ / ۱۱ / ۹۴ - ۰۹:۱۵ سلام البته تو تست هایی که من کردم این روش فقط برای Rebuild ایندکس مناسب می باشد. تغییر recovery model از افزایش حجم log file هنگام reorganize کردن جلوگیری نمی کند. Hamid J. Fard ۱۵ / ۱۱ / ۹۴ - ۰۴:۵۳ تغییر Recovery Model به هیچ عنوان از حجم Log جلوگیری نمی کند فقط نوع ذخیره سازی برای هر تراکنش را تغییر می دهد سپهر صفایی ۱۵ / ۱۱ / ۹۴ - ۰۳:۵۷ بله در حالت bulk-logged تاثیری در حجم فایل logBackup ندارد ولی هنگام عملیات REINDEXING حجم فایل log زیاد نمی شود مسعود طاهری ۱۵ / ۱۱ / ۹۴ - ۰۷:۰۱ سلام دوستان لینک های زیر مثال های خوبی در خصوص بحث تغییر Recovery Model و انجام Bulk Operation دارد. http://blogs.msdn.com/b/sqlserverfaq/archive/2011/01/07/using-bulk-logged-recovery-model-for-bulk-operations-will-reduce-the-size-of-transaction-log-backups-myths-and-truths.aspx http://blogs.msdn.com/b/suhde/archive/2010/12/29/transaction-log-backup-size-in-bulk-logged-recovery-model.aspx سپهر صفایی ۱۵ / ۱۱ / ۹۴ - ۰۳:۳۳ با تشکر از لینک هایی که معرفی کردید. آیا راه حلی برای جلوگیری از رشد log file هنگام reorganize کردن ایندکس ها دارید؟! مسعود طاهری ۱۵ / ۱۱ / ۹۴ - ۰۸:۱۵ تهیه منظم Log Backup ۱- در دیتابیس های بزرگ اینکار (Reorganize) معمولا به شکل On-Demand روی جداولی خاص انجام می شود. در این حالت با مانیتور کردن لاگ فایل می توانیم در صورت افزایش حجم Log Backup بگیریم تا بیش از حد حجم لاگ زیاد نشود. ۲- اگر با Maintenance Plan کار می کنید متاسفانه در نسخه های قبل از ۲۰۱۶ ایندکس تمامی جداول در پروسه Rebuild , Reorganize شرکت می کنند و این موضوع افزایش حجم لاگ را در پی دارد. اما در نسخه ۲۰۱۶ کمی اوضاع فرق کرده و هنگام انتخاب جداول می توان شرایطی خاص را مشخص کرد. ۳- بهترین حالت برای Rebuild + Recognize کردن ایندکس ها در دیتابیس های بزرگ انجام اینکار به شکل On Demand بوده و نه ازای همه جداول بلکه برای جداولی + ایندکس هایی که مشکل Fragmentation دارند. در این حالت پس از Rebuild + Organize کردن چند جدول و… می توان لاگ را بررسی کرد اگر حجم از حد مشخصی بالا رفت لاگ بکاپ تهیه کرد Hamid J. Fard ۱۵ / ۱۱ / ۹۴ - ۰۹:۵۳ عذر می خواهم . Log Backup Hamid J. Fard ۱۴ / ۱۱ / ۹۴ - ۰۲:۱۵ البته اگر به Bulk-Logged تغییر پیدا کند زنجیره لاگ از بین نخواهد رفت مسعود طاهری ۰۴ / ۱۱ / ۹۴ - ۱۲:۵۸ البته فک کنم منظور شما از این این عملیات بازهم تاثیر در عملیات Mirroring تولید لاگ و تاثیر اونها در پروسه Mirroring است و نه Recovery Model پاسخ به دیدگاه میلاد فیروزی ۰۳ / ۱۱ / ۹۴ - ۰۸:۱۵ متشکر از نظر بسیار کاربردی شما دوست عزیز پاسخ به دیدگاه مسعود طاهری ۱۵ / ۱۱ / ۹۴ - ۰۷:۰۱ سلام دوستان لینک های زیر مثال های خوبی در خصوص بحث تغییر Recovery Model و انجام Bulk Operation دارد. http://blogs.msdn.com/b/sqlserverfaq/archive/2011/01/07/using-bulk-logged-recovery-model-for-bulk-operations-will-reduce-the-size-of-transaction-log-backups-myths-and-truths.aspx http://blogs.msdn.com/b/suhde/archive/2010/12/29/transaction-log-backup-size-in-bulk-logged-recovery-model.aspx پاسخ به دیدگاه مسعود طاهری ۰۴ / ۱۱ / ۹۴ - ۰۹:۵۹ سلام مجدد حمید جان به این لینک نگاه کنید http://weblogs.sqlteam.com/mladenp/archive/2007/09/06/How_does_SQL_Server_really_store_NULL-s.aspx اگر بخواهیم که این فضا واقعا در Page تخصیص داده نشود باید سراغ Sparse Column برویم که دردسرهای خاص خودش را دارد پاسخ به دیدگاه