خانه / مقالات / بانک های اطلاعاتی / علت پراکندگی در SQL Server

علت پراکندگی در SQL Server

خلاصه
هربار که داده ها در جدول های SQL Server مایکروسافت تغییر می کنند، شاخص های آن ها نیز تغییر می کنند. با گذشت زمان شاخص ها پراکنده می شوند. این پراکندگی تاثیر نامطلوبی بر اجرا دارد. این مقاله اطلاعاتی را ارائه می دهد که به شما در فهم مکانیزم نهفته در پشت این پراکندگی کمک می کند. همچنین شما را با روش ها و راه های اجرای یکپارچه سازی (Defragmentation) آشنا می سازد، بنابراین میتوانید عملکرد SQL Server خود را بهبود ببخشید.
در این مقاله تکنیکی شما را با موضوع  پراکندگی SQL Server آشنا می کنیم و همچنین مزیت های اجرایی که میتوانید با نظارت و مدیریت مداوم پراکندگی شاخص ها بدست بیاورید.

خلاصه موضوعات مطرح شده در این مقاله:
– تفاوت پراکندگی داخلی و خارجی بین دیسک و SQL Server
– تاثیرات پراکندگی بر روی اجرا
– مکانیزم هایی که در حمایت از اجرا فضای خالی داده ها را می رباید
– موافقان و مخالفان روش های محتلف مدیریت پراکندگی
– چگونه SQL Defrag Manager یک روش کارآمدتر و خودکار برای شناسایی و حل پراکندگی شاخص در SQL Server ارائه می دهد
– نحوه قضاوت در مورد بهبودهایی که از یکپارچه سازی سرور حاصل می شوند
هشدار: این مقاله کمی فنی است و برای آن دسته از مدیران پایگاه اطلاعاتی نوشته شده که حقیقتاً میخواهند از جزئیات و اجزای اصلی پراکندگی در SQL Server آگاه شوند.

سوال: پراکندگی SQL Server چیست؟ آیا با پراکندگی دیسک فیزیکی متفاوت است؟
پاسخ: پراکندگی SQL  همان پراکندگی دیسک فیزیکی نیست. اصلا پراکندگی ها با هم یکسان نیستند.
وقتی بحث از پراکندگی به میان می آید اولین چیزی که به ذهن می رسد، پراکندگی دیسک فیزیکی است. پراکندکی فیزیکی در واقع تاثیر جانبی نحوه عملکرد درایوهای سخت و ویندوز است و همه می دانند که برای رسیدن به یک عملکرد بهینه در کامپیوتر، یکپارچه سازی دیسک باید بطور منظم انجام بگیرد. ویندوز دارای یک یوتیلیتی اولیه یکپارچه سازی نیز هست.
پراکندگی فیزیکی، کامپیوتر شما را کند می کند چون خواندن داده ها به دلیل تاخیر در جستجوی عنوان، دچار وقفه می شود. ویندوز فایل ها را در فضای خالی جای می دهد. اغلب فایل ها به چند سگمنت تقسیم می شوند که هر کدام به طور جدا از دیگری ذخیره می گردند. هد درایو سخت جابجا می شود تا هرکدام از این سگمنت ها را بخواند. هد با رفتن به هر سگمنت شروع به جستجو می کند -که اغلب سه چهار برابر زمانی که فقط یک سگمنت را می خواند، طول می کشد. پراکندگی فیزیکی اصولاً کامپیوترهای دسکتاپ و لپ تاپ هایی را تحت تاثیر قرار می دهد که دارای یک درایو سخت هستند. این درایو باید دائماً داده ها را جمع آوری کند- بنابراین در یک دیسک پراکنده شده، درایو جستجو می کند، میخواند، جستجو می کند، میخواند – این ۴ عمل یکی پس از دیگری انجام می شوند. در صورت یکپارچه سازی، این عمل به جستجو، خواندن و خواندن ختم می شود. در نمونه آزمایشی ما، این کاهش زمان بین ۲۴ هزارم ثانیه تا ۱۵ هزارم ثانیه بود.
محصولات یکپارچه سازی فیزیکی مثل Windows Defrag، Power Defrag، Page Defrag(ابزار دیگر مایکروسافت) یا قدیمی ترین آن ها Diskeeper 2011 هنگام تعمیر فایل های سگمنت شده به خوبی کار می کنند. تکنولوژی Diskeeper در مایکروسافت موفق به کسب گواهینامه به عنوان یک ابزار یکپارچه سازی در ویندوز شده است. در حقیقت، جدیدترین ابتکارات Diskeeper قابلیت های یکپارچه سازی فیزیکی را به یک سطح کاملا جدید می آورد. تمام این محصولات، داده ها را در دیسک شما مجدداً مرتب نموده و فایل ها را در سگمنت های کمتری یکی می کنند تا جستجوهای هد به حداقل برسد، در نتیجه زمان بوت شدن و خواندن های فایل سریع تر شده و در کل سرعت عمل سیستم بالا می رود.
یک درایو SATA یا IDE متداول ترین راهکار ذخیره سازی ایستگاه کاری است.استفاده از مجموعه مشخصات mfgr برای این درایو معمولی موجب می شود اجرای خواندن ها حدود ۲۴ هزارم ثانیه طول بکشد. پس از یکپارچه سازی همین خواندن ها تقریباً ۱۵ هزارم ثانیه طول می کشند ( یا تقریباً ۳۰ درصد سریعتر) تا اجرا شوند.
همانطور که در تصویر بالا می بینید، پراکندگی فیزیکی درایو را مجبور می کند تا فایل را به صورت دو سگمنت بخواند. جستجو ۱۸ هزارم ثانیه و خواندن ۶ هزارم ثانیه زمان می برد. با توجه به این که یک فایل متوسط از صدها سگمنت ساخته شده، تاخیر جستجو چندین برابر می گردد و با گذشت زمان خود را به صورت کند شدن سیستم نشان می دهد.
بهرحال، پراکندگی دیسک فیزیکی شبیه پراکندگی SQL Server نیست. SQL Serverها از سیستم های ذخیره سازی پیشرفته با چندین درایو همزمان استفاده می کنند و روش خواندن فایل ها را تغییر می دهند. پراکندگی فیزیکی چیزی است که با سخت افزار حل می شود، نه با ابزارها یا اسکریپت های یکپارچه سازی.
بهترین تکنیک ها عموماً زیر سیستم های ذخیره سازی چند درایوی را برای SQL Serverهای تولید تجویز می کنند. اکثر SQL Serverها از ذخیره سازی چند درایوی مثل آرایه های RAID، SANها و دستگاه های NAS استفاده می کنند. همیشه چندین درایو وجود دارند که همزمان کار می کنند. کنترل کننده های دیسک سخت که از آرایه های درایو پشتیبانی می کنند، از ارتباط های جستجو/خواندن نوبتی با آرایه برای حداکثر I/O آگاهند.
در نتیجه، فایل ها در میان درایوهای زیادی که فی نفسه سگمنت بندی شده اند، توزیع می شوند. بهرحال، کارکردن همزمان، به یک داریو اجازه می دهد تا وقتی درایوهای دیگر مشغول خواندن هستند، جستجو را انجام دهد. با وجود پیکربندی متداول ۵ درایوی، تاخیر جستجو ۹هزارم ثانیه در هر درایو به ۲ درایو اجازه می دهد تا بدون آنکه تاخیر جستجو اثری بر آن ها داشته باشد، به مدت ۳هزارم ثانیه بخوانند. درایوهای ذخیره سازی داده ها معمولاً سریع تر از درایوهای ایستگاه کاری(WorkStation) هستند، بنابراین زمان های جستجوی ۴هزارم ثانیه و زمان های خواندن ۵/۱ هزارم ثانیه غیرمعمول نیستند.
مدیران زیادی وجود دارند که یک برنامه یکپارچه سازی فیزیکی قدیمی را همزمان با کنترل کننده درایو هوشمند اجرا می کنند که در نتیجه بهبودهای محدودی حاصل می شود. هدف داشتن بیشترین عملکرد ضمن داشتن کمترین سربار است، پس اگر یکپارچه سازی های فیزیکی موجب می شوند ذخیره سازی در ضمن اجرا تا ۵۰ درصد کند گردد و در نهایت سرعت خواندن فقط ۱ تا ۲ درصد بهبود پیدا کند، آنها را اجرا نکنید.
مهم فهمیدن این موضوع است که کنترل کننده، برنامه های یکپارچه سازی فیزیکی و آرایه های چند درایوی ذاتاً از آنچه که SQL Server با داده های فایل انجام می دهد، مطلع نیستند. با تمرکز روی موضوعاتی همچون نحوه ارائه داده ها از سوی SQL Server، نحوه طرح بندی پایگاه اطلاعاتی توسط خود SQL Server ، اینکه هرصفحه چقدر پر است و اینکه ما تا چه حد از منابع موجود SQL Server به شکل موثری استفاده می کنیم، میتوانیم بهینه سازی را در “سطح بعدی” عملکرد SQL Server  انجام دهیم. خلاصه، عملکرد SQL Server را میتوان با تمرکز بر اعضای داخلی آن بهبود بخشید، چه با یکپارچه سازی دستی چه با یکپارچه سازی خودکار که توسط SQL defrag manager  انجام  میگردد، ممکن است به این نتیجه برسید که یکپارچه سازی فیزیکی دیگر نیاز نیست.

سوال: تاثیر یکپارچه سازی SQL Server بر سرور من چیست؟
پاسخ: پراکندگی شاخص های SQL Server اساساً فضای تلف شده به وجود می آورد که می تواند بر عملکرد سرور شما تاثیر بگذارد.
پراکندگی تخصیص های داخلی SQL Server و ساختارهای صفحه منجر به ایجاد شکاف ها و فواصل ناخواسته می گردد که در واقع وزن مرده ای (dead Weight) است که با داده های معتبر حمل می شوند. پشتیبان گیریها ، ذخیره سازی، کانال های I/O، حافظه بافر، داده های کش شده، لوگ ها، tempdb، CPUها و طرح های پرس و جو تحت تاثیر این فضاهای ناخواسته و غیر ضروری هستند.
پراکندگی SQL با هربار انتخاب، بروزرسانی، حذف، درج و تغییر شاخص/جدول، این منابع را بتدریج نابود می کنند. اگر پراکندگی ها نادیده گرفته شوند، میتوانند به اصطلاح، ضربات مهلکی به مقیاس پذیری و عملکرد سرور بزنند.

سوال : چه چیزهایی باعث بوجود آمدن فضاهای خالی نابه جا و تاثیرات مضر می شوند و من چگونه میتوانم آن ها را کنترل کنم؟
پاسخ: فعالیت های روزمره و متداول به مرور موجب پراکندگی در SQL Serverها میشوند. تغییرات صورت گرفته بر داده ها، درج ها، بروزرسانی ها، حذف ها و حتی تغییرات Varchar به این پراکندگی کمک می کنند. لیست کامل عمل هایی که منجر به پراکندگی می شوند طولانی است و نرخ پراکندگی در شاخص ها و جدول های مختلف متفاوت است. گاهی اوقات الگویی از پیک های سالیانه یا فصلی وجود دارد، اما اکثر اوقات پیدا کردن، پیش بینی کردن و مدیریت پراکندگی به صورت دستی دشوار است.
SQL Server تمام داده ها، آبجکت ها و ساختارهای داخلی را در صفحه های داده ای ۸۱۹۲ بایتی (تصویر ۱) ذخیره می کند. این صفحه ها فقط برای SQL Server شناخته شده هستند و ممکن است در یک یا چند فایل فیزیکی در دیسک ذخیره شوند. داده ها در هر صفحه حداکثر به ۸۰۹۶ بایت می رسند ، بقیه صفحه شامل هدر صفحه و محل سطرهاست. هنگام ساخت یک جدول یا شاخص، صفحه های SQL Server طبق فاکتور پرشدن (یا Fill Factor) که شما تعیین می کنید (یا تقریبا نزدیک به آن) پر می شوند.
گذشت زمان، درج ها، حذف ها و یا اصلاحات (مثل گسترده کردن مقدار در فیلدهای varchar) صفحه را پر می کنند و در نهایت صفحه سرریز می شود و موجب تقسیم صفحه یا Page Split می گردد. در این صورت کل صفحه بطور مساوی تقسیم می شود و نیمی از داده های آن صفحه در یک صفحه اختصاصی جدید قرار می گیرد و ممکن است تمام فاکتورهای پرشدن (یا Fill Factor) که شما تعیین کرده اید، خنثی گردد. مثلاً اگر شما Fill Factor هشتاد درصد را تعیین کرده باشید در اثر عمل تقسیم شدن صفحه، صفحات شما ممکن است به Fill Factor پنجاه درصد یا کمتر برسند.
هرچه تغییرات صورت گرفته در جدول مداوم تر و سنگین تر باشند، شاخص های آن سریع و بیشتر سرگردان می شوند.
نتیجه این سرگردانی ها اتلاف است و بیشتر از همه اتلاف دیسک، کانال های I/O ، کش ها و بافرهای سرور و مصرف CPU می باشد. این اتلاف ممکن است مسیر طرح های پرس و جوی شما را به ناگهان تغییر دهد.
فضای اتلاف شده یا خالی تحت عنوان”پراکندگی داخلی” شناخته می شود. پراکندگی داخلی چگالی صفحه را پائین می آورد و در نتیجه منابع سرور به مقدار زیادی توسط این فضای خالی مصرف می شوند. SQL سعی می کند تا فضاهای خالی را در صفحه های تقسیم شده پر کند. روش متداول استفاده از ستون identity به عنوان شاخص کلاستر شده، درج کردن های اجباری در صفحات جدید در پائین جدول، مانع بازیابی فضاهای خالی  می گردد. فضای مصرف شده توسط داده های واقعی در معیاری به نام چگالی صفحه، انعکاس می یابد. هرچه یک صفحه متراکم تر و چگال تر باشد، داده های بیشتری در صفحه جای می گیرند. چگالی صفحه ۱۰۰درصد به این معنی است که صفحه داده ها کاملاً پر است.
حتی اگر صفحه ها فضای خالی نداشته باشند، شکل ۲ نشان می دهد که چگونه تقسیم صفحه باعث ناکارآمدی دیگری در دسترسی های پی در پی به صفحه می گردد. جالب است که این امر موجب موازی شدن پراکندگی فیزیکی می شود( گرچه این  یک نوع کاملاً مجزا در مدیریت داده های SQL Server در برابر روشی است که فایل ها در دیسک سگمنت بندی می شوند). این نوع پراکندگی “پراکندگی خارجی” نام دارد.
اکثر اوقات، این فضای خالی به جای آن که به درستی پر شود، افزایش می یابد. وقتی فضای خالی خیلی زیاد می شود (چگالی صفحه شما بسیار کم می شود)، SQL Server شاخص را به دلیل سربار بیش از حد  دور می اندازد. در این لحظه، پراکندگی بسیار مشخص است چرا که سیستم های بسیار کمی می توانند تحمل کنند که شاخص ها، به نفع اسکن های جدول دور انداخته شوند.
شاید این موضوع در مقیاس کوچک ساده بنظر برسد اما وقتی متوسط چگالی صفحه شما پائین است، در واقع فضای دیسک خود را به هدر می دهید، تحمل I/O فیزیکی بیشتر و خواندن های منطقی افزایش یافته، حافظه با ارزش سرور را به دلیل محاسبه و مقایسه غیرضروری داده ها به هدر می دهند.
بعلاوه، اگر آنقدر خوش شانس باشید که یک کنترل کننده I/O هوشمند داشته باشید، مزیت استراتژی های بهینه سازی این کنترل کننده را نیز به هدر می دهید. مشخص است که فرآیند تقسیم  صفحه، فضاهای خالی، روند پیشرفت کار و نرخ هدر رفتن ها، مستلزم یک توجه بی وقفه است تا سرور تا حد امکان بتواند با منابع آزاد بیشتری به اجرا دربیاید.
پراکنده شده، ۳۲۳۸۴ بایت به ۱۳۸۰۴بایت داده اختصاص داده شده (۵۷ درصد فضای خالی بی مصرف)
یکپارچه سازی شده،۱۶۱۹۲  بایت به ۱۳۸۰۴ بایت داده اختصاص داده شده (۱۵ درصد فضای خالی بی مصرف)
تصویر۲: چهار صفحه نیاز به چهار خواندن منطقی دارد.یکپارچه سازی با سازماندهی مجدد داده ها در دو صفحه  و دو خواندن، داده ها را متراکم می کند. کاهش ۴۲ درصدی در فضای خالی با یکپارچه سازی داده ها حاصل می شود. این یکپارچه سازی تاثیر بسزایی در بهبود عملکرد و افزایش مقیاس پذیری دارد. در این مثال، دو برابر این مقدار داده می تواند در فضای یکپارچه سازی شده در مقایسه با فضای پراکنده شده، جای شود. با بازپس گرفتن این فضاهای خالی در واقع ظرفیت را به سرور خود باز می گردانیم.
سوال: ما از مزیت های حفظ و نگهداری آگاه هستیم و میخواهیم آن ها را داشته باشیم، حال چه باید بکنیم؟
پاسخ: غیر از SQL  Defrag Manager دو راه دیگر برای حل مشکل پراکندگی وجود دارند که هر دو شامل ایرادات جدی هستند.
به غیر از SQL  Defrag Manager ، ۲ روش دیگر برای مدیریت پراکندگی SQL server وجود دارند که البته هیچ کدام ایده آل نیستند یا اینکه زمانی شما را مطلع می کنند که چالش پراکندگی به نهایت خود رسیده است. هر دو این روش ها شما را به نوعی گیج و گنگ می کنند، شما نمی دانید که این اطلاعات به جدول شما کمک می کنند، به آن آسیب می رسانند یا آن را بلوکه می کنند.

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

روش دوم: اجرای یک اسکریپت حفظ و نگهداری بی هدف
این اسکریپت ها اغلب بسیار پیچیده با نتایج غیر قابل پیش بینی هستند. این اسکریپت ها معمولاً کار می کنند، اما اغلب موجب اثرات دیگری همچون بلاک کردن یا لاک کردن می شوند و میتوانند سربار قابل توجه ای را ایجاد کنند. شما نمی دانید چقدر طول می کشد که این اسکریپت یک یک شاخص را بیابد و هربار آنها را پرس و جو کند. این اسکریپت مزایای اجرایی را پیگیری نمی کند، هربار علت تغییر یکپارچه سازی را پیگیری نمی کند و در مورد مشکلات بالقوه هیچ نوتیفیکیشنی ارائه نمی دهد.

اسکریپت های یکپارچه سازی همه منظوره SQL Server:
– اطلاعاتی را درخواست می کنند که میتوانند منجر به رقابت یا بن بست شوند
– بندرت دارای منطق درونی برای درک زمان یکپارچه سازی هستند و در عوض هر روز کار سرورهای شما را روی غلتک می اندازند چه لازم به این کار باشد و چه نباشد.
– ممکن است نیاز به تغییراتی داشته باشند که در این صورت باید اسکریپت جدید را در تمام سرورهای سازمان خود مجدداً مستقر نمایید.
– اسکریپت ها باید با توجه به هر پایگاه اطلاعاتی متحمل تغییراتی شوند، اما برای انجام این کار نیاز به تنظیمات دستی مداوم است. یک فرآیند زمان بر و عملاً غیر ممکن.
– پس از اجرای اسکریپت ، قادر به ارائه گزارش نیستند مثل این که چه پیشرفت های اجرایی حاصل شده است یا اینکه وقتی آن ها را اجرا می کنید، چه تعداد منابع را از سرور شما مطالبه می کنند.

روش سوم: SQL  Defrag Manager
SQL Defrag Manager یک روش کاملاً جدید برای شناسایی، بهینه سازی، مدیریت و اتومات سازی یکپارچه سازی SQL Server است. Defrag Manager به گونه ای طراحی شده تا انتظارات مدیران پایگاه اطلاعاتی را در خصوص وظیفه مهم حفظ و نگهداری پراکندگی شاخص، برآورده سازد.
توجه کنید: اگر بتوانید فضاهای خالی را حذف کنید، باز پس گرفتن فضای خالی هر صفحه در واقع پولی است که به جیب سازمان شما باز می گردد. این منابع بازپس گرفته شده ظرفیت سرور را که بی دلیل از دست رفته بود، مجدداً  به آن باز می گرداند. SQL Defrag Manager این منابع را بازپس می گیرد و همه بهبودهای روزانه و یا سالیانه را پیگیری می نماید.حتی میتوانید یک گزارش سالانه تهیه کنید که نشان دهد در اثر یکپارچه سازی چه میزان پول صرفه جویی شده است.
بعلاوه Defrag Manager SQL هوشمندی خاصی را وارد برنامه یکپارچه سازی زمانبندی شده می کند. بخصوص اینکه این امکان را به مدیر پایگاه اطلاعاتی می دهد تا وضعیت معیارهای منابع سیستم را قبل از اجرای سیاست یکپارچه سازی تعیین کند. مدیر پایگاه اطلاعاتی میتواند آستانه هایی برای  TLOG)،Memory،SQL Server CPU ، (Server CPU تنظیم نماید. Proactive Resource Cheak این امکان را برای مدیر پایگاه فراهم می سازد تا گلوگاه های سیستم را پیش بینی کند. اگر بازدید منابع بیشتر از حد آستانه تعریف شده توسط کاربر باشد، یک نوتیفیکیشن به مدیر پایگاه اطلاعاتی فرستاده می شود.
Defrag Manager SQL نه تنها بهبودهای حاصله در هر شی را پیگیری می کند، بلکه تعداد زیادی از آمارها را در هر جدول و شاخص حفظ می نماید.
این اطلاعات Defrag Manager SQL را راهنمایی می کند تا تصمیم بگیرد که هرچند وقت یکبار پراکندگی را چک کند  در صورتی که مایل باشید، این روش برای رفع پراکندگی مورد استفاده قرار می گیرد. Defrag Manager SQL سربار یکپارچه سازی و احتمال خطر در سرورهای شما را حذف می کند.
در هیچ یک از سرورهای مدیریت شده نیاز به عامل یا agent نیست. هیچ برنامه زمانبندی شده یا اسکریپت مستقر شده ای وجود ندارد. Defrag Manager SQL به راحتی بصورت یک سرویس در پس زمینه اجرا می شود بدون اینکه تاثیری در سرورهای تولید شما داشته باشد.
برخلاف اسکریپت ها، روتین های شناسایی پراکندگی Defrag Manager SQL مسدود نشدنی هستند. یکپارچه سازی نیز مسدود نشدنی است و کاری می کند که مدیر پایگاه اطلاعاتی نخواهد شی پراکنده شده را مجدداً بازسازی کند. یکپارچه سازی SQL براساس بازخورد مدیران پایگاه اطلاعاتی با تجربه صورت می گیرد. Defrag Manager SQL سطوح پراکندگی را در کل محیط SQL Server شما در نظر می گیرد و موجب می شود به راحتی بتوانید پراکندگی ها را شناسایی و مدیریت کنید. همچنین این اطمینان را به شما می دهد که یکپارچه سازی دقیقاً به روشی انجام شود که خاص آن پایگاه اطلاعاتی است، پس نیاز به حدس های اضافی نیست.
صفحه اتوماتسازی: این صفحه به SQL defrag manager دستور می دهد تا مرتباً نگاهی به این شیء داشته باشد. در صورت تمایل می توانید رنج خاصی را برای پراکندگی و چگالی اسکن، تعیین نمایید. این ویژگی معمولاً در سرور تنظیم شده و آبجکت های فرزند آن را به ارث می برند- اما می توانید بر آن کنترل داشته باشید.این ویژگی را در هر شیء در محیط خود لغو نمایید.

Defrag Manager SQL
در لحظه نصب صفحه ای شبیه به تصویر زیر را می بینید. تشخیص سطح پراکندگی در هر SQL Defrag مسدود نشدنی است. برخلاف اسکریپت ها یا پرس و جوهای دستی، خطرات غیرقابل پیش بینی حذف می شوند. شما نظارت کامل و سریع بر شرکت خود دارید و اینکه پراکندگی چه تاثیری بر روی عملکرد آن دارد.
نمایش تمام سرورهای موجود در شرکت تان که همگی کالر کد شده هستند، میزان تاثیر پراکندگی بر روی آنها، پایگاه اطلاعاتی، جدول ها و شاخص هایشان را انعکاس می دهد. شما به راحتی میتوانید آیتم هایی که نیاز به توجه بیشتری دارند را در قسمت مهم ترین ها قرار دهید.
سریعاً به داخل سرور، پایگاه اطلاعاتی حفاری (drill down) می کنید و با کلیک کردن چارت کلوچه ای، شاخص/ جدول مشگل ساز را جستجو می نمایید. اگر میخواهید رفع مشگل کنید، با یک کلیک (با استفاده از تکنیک های مسدود نشدنی) این کار انجام می شود و بهبودهای حاصله سریعاً بازتاب می یابد.
وقتی نقاط شامل پراکندگی را یافتید با SQL Defrag Manager می توانید از عدم بروز مجدد این مشگل اطمینان پیدا کنید. می توانید بگونه ای آن را تنظیم کنید تا خلاصه ای از کار را برای شما بفرستد و شما را از وجود مشکل آگاه نماید و در صورت نیاز آن را به صورت خودکار یکپارچه سازی کند.

زمانبندی هوشمندانه
به راحتی میتوانید یک زمانبندی برای بررسی آبجکت ها تنظیم کنید. برای اطمینان خاطر از اینکه تمام فعالیت ها براساس دستورالعمل شما انجام می شوند. رنج های آغاز و پایان را میتوان مشخص کرد، میتوانید در وقت های مناسب مثل آخر هفته یک برنامه یک زمانه را اجرا نمائید.
آیا یکپارچه سازی ایمن است؟
مدیر پایگاه اطلاعاتی میتواند قبل از اجرای سیاست یکپارچه سازی، آستانه هایی را برای ۹ معیار منبع سیستم تعیین کند.
یکپارچه سازی مکرر شاخص؟ مدیریت فاکتور پرشدن  (fill factor)شاخص
اگر شاخص های شما بسیار پراکنده هستند، میتوانید این پراکندگی را با تغییر فاکتور پرشدن شاخص کاهش دهید.

به روش خودتان یکپارچه سازی کنید
– بگذارید شما را از نزدیک شدن به آستانه ها مطلع کند، پس میتوانید هر وقت که بخواهید یکپارچه سازی دستی را انجام دهید.
– بگذارید راهکارهای مسدود نشدنی را امتحان کند و اگر به حد قابل قبولی نرسید، شما را مطلع سازد
– بگذارید راهکارهای مسدود نشدنی را امتحان کند و اگر به حد قابل قبولی نرسید، راهکارهای مسدود شدنی را امتحان نماید
– اگر فقط سطح سرور را تنظیم می کنید، تمام پایگاه های اطلاعاتی، جدول ها و شاخص ها به ارث خواهند رسید.
– هر جدولی را که فکر می کنید باید به شکل متفاوتی مدیریت شود را لغو کنید- شاید با یک رِنج یا زمان خاص
– در برخی روزهای خاص فعالیت را به پنجره های خارجی محدود کنید.
– آیا یکپارچه سازی را مکرراً انجام می دهید؟  شاخص ‘fill factor” را تغییر دهید و مزایای آن را با گذشت زمان ببینید.

بگذارید SQL Defrag Manager کار یکپارچه سازی را برای شما انجام دهد
– این ابزار میتواند خودکار یا به صورت تعاملی باشد.
– لازم نیست بر تمام مشکلات بالقوه شرکت خود نظارت داشته باشید، SQL Defrag شما را مطلع می کند.
– SQL Defrag Manager هوش کنش گرایانه بررسی منابع را به فرآیند یکپارچه سازی شما می آورد.
– Management Console defrag manager SQL یک پنجره زمان -واقعی در سطوح پراکندگی ارائه می دهد.
– پشت میز خود بنشینید، کار یکپارچه سازی را در تمام سرورها مشاهده و مدیریت کنید.
– مکانیزم کلکسیون بدون عامل. در هیچکدام از سرورهای نظارت شده شما اسکریپت های مستقر وجود ندارند.

کلکسیون سبک
– جزئیات پراکندگی به شکل هوشمندانه ای براساس یک زمانبندی اختصاصی جمع آوری می شود، سربار را در سرورهای نظارت شده شما کنترل و پائین نگه می دارد.
– اگر Defrag Manager SQL مشکلی را پیش بینی کند که احتمال می رود قبل از زمانبندی بعدی رخ دهد، شما را از آن مطلع می سازد.

دیدگاهتان را ثبت کنید

آدرس ایمیل شما منتشر نخواهد شدعلامتدارها لازمند *

*

x

شاید بپسندید

تنظیم پرس و جوی SQL Server یک برنامه ۱۲ مرحله‌ای

تنظیم پرس و جوی SQL Server یک برنامه ۱۲ مرحله‌ای مقدمه: تنظیم ...