پیروی از بهترین شیوه های عملکرد پایگاه داده SQL و نظارت بر سلامت پایگاه داده Connect شما به اطمینان از یک سرور اتصال پاسخگو که تجربه کاربر نهایی عالی را ارائه می دهد کمک می کند.

بهترین کار این است که همیشه فهرست های سیستم عامل، داده ها و گزارش ها را روی درایوهای دیسک جداگانه قرار دهید. این منجر به بهبود عملکرد خواهد شد. اگر باید Connect را روی همان سرور DB قرار دهید (هرگز بهترین روش نیست، اما گاهی اوقات یک ضرورت عملی است)، باید مطمئن شوید که دایرکتوری‌های نصب و محتوای Connect بر روی یک درایو دیسک متفاوت از داده‌های پایگاه داده قرار دارند. Temp DB نیز باید روی یک درایو دیسک جداگانه باشد. قرار دادن داده های SQL بر روی دیسک های راه راه، مزیت تنظیم را نیز فراهم می کند.

مطمئن شوید که به طور جدی آمار را دوباره فهرست و به روز کنید. داده‌های سیستم‌عامل و فایل‌های لاگ را بر اساس یک برنامه منظم جدا کنید. اطمینان حاصل کنید که حداقل تاخیر بین سرور اتصال و سرور SQL وجود دارد. مراقب تعمیر و نگهداری شبکه و پشتیبان‌گیری باشید که می‌تواند باعث تأخیر بین سرور Connect و سرور SQL شود و مطمئن شوید که در طول چنین تعمیراتی از استفاده زیاد Connect اجتناب کنید.

مطمئن شوید که سرور SQL دارای مقدار زیادی رم است. هر چه رم بیشتر باشد بهتر است همه چیز در حافظه بسیار سریعتر کار می کند. هرچه تعداد بیشتری از پایگاه داده را در حافظه نگه دارید، وضعیت بهتری خواهید داشت. سرور DB را فقط در صورت لزوم مجازی سازی کنید. در حالی که Connect روی سرورهای پشتیبانی شده VMWare به خوبی اجرا می شود، سرور پایگاه داده SQL به بهترین وجه بر روی یک پلت فرم اختصاصی اجرا می شود.

با توجه به استفاده از دیسک های جداگانه، در اینجا یک لیست اولویت بندی شده از آنچه باید دیسک خود را داشته باشد آورده شده است:

  1. سیستم عامل
  2. Adobe Connect (در صورت امکان سرور جداگانه)
  3. پایگاه داده SQL
  4. داده ها
  5. ورود به سیستم
  6. TempDB
  7. سیاهههای مربوط به تراکنش

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

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

db3.fw

SQL Server از پایگاه داده tempdb به عنوان یک منطقه کاری برای جداول موقت، مرتب سازی، سوالات فرعی و غیره استفاده می کند. tempdb باید تا حد امکان در درایو خودش و دور از سایر DBها ذخیره شود. مکان پیش فرض روی دیسک نصب SQL است. اندازه پایگاه داده tempdb را بر اساس میزان استفاده مورد انتظار و فضای موجود افزایش دهید. SQL Server به طور خودکار اندازه را در طول زمان تنظیم می کند، اما هر تغییر باعث یک ضربه عملکرد و تکه تکه شدن می شود. با افزایش اندازه، از رشد مداوم جلوگیری می کنید. SQL 2008 از tempdb بیشتر از نسخه های قبلی SQL استفاده می کند. هرگز سعی نکنید از tempdb نسخه پشتیبان تهیه کنید.

بر فضای دیسک فایل های داده و فایل های گزارش نظارت کنید. فضای دیسک در مقایسه با مزایایی که در صورت وجود به وفور فراهم می کند، ارزان است. در صورت نیاز به گسترش فایل‌های داده/log، یا اگر تنظیم شده است که به صورت خودکار رشد کنند، باید حداقل 30 درصد فضای دیسک آزاد را حفظ کنید. افزایش ناگهانی اندازه باید دلیلی برای بررسی باشد.

سطوح پراکندگی را رصد کنید. اگر پایگاه داده و گزارش به صورت خودکار در فواصل زمانی کوچک رشد کنند، احتمال تکه تکه شدن آنها زیاد است. اگر به طور مرتب فایل‌های داده‌های DB یا فایل‌های گزارش را کوچک می‌کنید، ممکن است منجر به تکه تکه شدن شود

نظارت بر پرس و جوهای کند؛ می توانید پرس و جوهای کند را در گزارش اشکال زدایی Connect مشاهده کنید. فقط Slow Query را جستجو کنید. زمان پرس و جو بر حسب msec برگردانده می شود. همچنین به دنبال وقفه های زمانی قفل در گزارش اشکال زدایی باشید. به طور کلی این نشانه مشکلات پایگاه داده است. بازه زمانی قفل یک پرس و جو است که سعی می کند یک منبع پایگاه داده را قفل کند. زمان آن تمام می شود زیرا چیز دیگری قبلاً قفل را نگه داشته است. قفل معمولاً تا زمانی که تراکنش کامل نشده است نگه داشته می شود، بنابراین اگر یک پرس و جو طولانی مدت وجود داشته باشد می تواند باعث وقفه زمانی قفل شود. شما همچنین می توانید ردیابی ها را در پایگاه داده اجرا کنید تا اطلاعات مربوط به پرس و جوهای طولانی را جمع آوری کنید. در SQL 2008 می توانید نماهای مدیریت پویا را برای دریافت این اطلاعات جستجو کنید.

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

مانیتور عملکرد ویندوز یا perfmon مفید است. شما می توانید از perfmon برای نظارت بر شمارنده های SQL استفاده کنید. در اینجا 3 شمارنده رایج وجود دارد که اگر چیزی را فاش کنند، مستلزم بررسی بیشتر است.

هنگام نظارت با perfmon از بار و فعالیت آگاه باشید زیرا پشتیبان‌گیری از پایگاه داده و سایر فعالیت‌های تعمیر و نگهداری می‌تواند باعث افزایش در این اعداد شود. اگر قصد دارید آن را با perfmon نظارت کنید، بهتر است از یک رایانه شخصی دیگر به سرور متصل شوید.

یک برنامه تعمیر و نگهداری خوب شامل فهرست بندی مجدد برنامه ریزی شده در ساعات تعطیل است. شاخص های تکه تکه می توانند باعث کندی Connect شوند و حتی ممکن است باعث شکست سریع در یک خوشه Connect شوند. اگر شروع به مشاهده تعداد زیادی پرس‌و‌جوی کند در گزارش اشکال‌زدایی کردید، باید مطمئن شوید که Connect DB مرتباً مجدداً فهرست می‌شود: نگهداری فهرست یکی از ساده‌ترین راه‌ها برای سالم نگه داشتن DB است و SQL Server جادوگرانی را ارائه می‌دهد که به ساخت آن کمک می‌کنند. نگهداری شاخص آسان است.

SQL Server Management Studio را باز کنید و پوشه مدیریت را باز کنید.

به طرح تعمیر و نگهداری یک نام بدهید:

db4.fw

وظایف تعمیر و نگهداری مورد نظر را انتخاب کنید: فهرست مجدد و به روز رسانی آمار

db5. fw

پایگاه داده ای را که می خواهید دوباره فهرست کنید انتخاب کنید:

db6.fw

سازماندهی مجدد با مقدار پیش فرض فضای آزاد؛ مقدار پیش فرض همان چیزی است که در ابتدا با آن ایجاد شده است.

db7.fw

پس از فهرست بندی مجدد، همان پایگاه داده را برای به روز رسانی آمار انتخاب کنید.

db8.fw

برای اجرای طرح تعمیر و نگهداری، کاری را برنامه ریزی کنید. یک نام ارائه دهید و یک برنامه زمانی انتخاب کنید که مناسب زیرساخت شما باشد:

db6.fw

عملکرد پایگاه داده و بهترین شیوه های نظارت، سرور اتصال پاسخگو را تضمین می کند که تجربه کاربر نهایی عالی را ارائه می دهد.

برنامه کاربردی ، 

خوشه بندی ، 

پایگاه داده ، 

عمومی ، 

نصب


Adobe Connect Support Blog

Adobe Connect Database Performance and Monitoring

Following SQL database performance best practices and monitoring the health of you Connect database will help to insure a responsive Connect server providing excellent end user experience.

It is best to always place the operating system, data and log directories on separate disk drives; this will result in improved performance. If you must put Connect on the same server as the DB (never a best practice but sometimes a practical necessity), you should ensure that the Connect installation and content directories are on a different disk drive than is the database data. The Temp DB should also be on a separate disk drive. Putting the SQL data on striped disks,  provides a tuning benefit as well.

Be sure to aggressively re-index and update statistics. De-fragment the operating system data and log files on a regular schedule. Ensure that there is minimal latency between the Connect server and the SQL Server. Be wary of  network maintenance and backups that can produce latency between the Connect server and the SQL server and be sure to avoid heavy Connect use during any such maintenance.

Make sure that the SQL server has plenty of RAM; the more RAM the better.  Everything works much faster in memory.  The more of the database that you can keep in memory the better off you will be. Only virtualize the DB server if absolutely required.While Connect runs fine on supported VMWare servers, the SQL database server is best run on a dedicated platform

With reference to the use of separate disks, here is a prioritized list of what should have its own disk:

  1. Operating System
  2. Adobe Connect (Separate Server if possible)
  3. SQL database
  4. Data
  5. Log
  6. TempDB
  7. Transaction logs

For best performance, set the initial size of the transaction log file based on estimated use.  This avoids unnecessary fragmentation. The transaction log should be on a different drive than is your data file, temp database and operating system. Manually shrink the transaction log files based on monitoring.  If you try to do this as a nightly or weekly job, you will end up with unnecessary fragmentation. De-fragment the transaction log file as necessary and consider putting transaction logs on striped disks. Ensure regular backups as transaction log backups empty the space inside the log file and prevent it from continuing to grow.

Manage the memory by setting the minimum server memory for SQL server.  Remember to leave enough for the operating system and any other applications running on the server:

db3.fw

SQL Server uses the tempdb database as a working area for temporary tables, sorting, sub-queries etc.; the tempdb should be stored on its own drive away from other DBs whenever possible.  The default location is on the SQL install disk. Increase the size of the tempdb database based on expected usage and available space. SQL Server automatically adjusts the size over time, but each change causes a performance hit and causes fragmentation. By increasing the size, you avoid constant growth. SQL 2008 uses the tempdb more than prior versions of SQL. Never try to backup the tempdb.

Monitor the disk space of the data files and log files. Disk space is inexpensive when compared with the benefits it provides when available in abundance.  You should aim to keep at least 30% free disk space in case you need to expand the data/log files, or if they are set to autogrow.  Sudden increases in size should  be cause for investigation.

Monitor the fragmentation levels. If the database and log were set to autogrow at small intervals, there is a high likelihood that they are fragmented. If you regularly shrink the DB data files or log files, that could also lead to fragmentation

Monitor for slow queries; you can see slow queries in the Connect debug log.  Just search for Slow Query. Query times are returned in msec. Also look for lock timeouts in the debug log.  Generally this is a sign of database problems. A lock timeout is a query that attempts to get a lock on a database resource.  It times out because something else is already holding a lock. A lock is usually held until the transaction has completed, so if there is a long running query it could cause lock timeouts. You can also run traces against the database to gather information on long running queries.  In SQL 2008 you can query dynamic management views to get this information.

Monitor indexes liberally keeping in mind that re-indexing regularly should decrease the need to monitor indexes. Sometimes re-indexing may start taking too long to complete and you will want to be more selective about what to target. Knowing which tables or indices are most fragmented allows you to only re-index them. You can query dynamic management views in SQL Server to get this information (see SQL Server books online). Many 3rd party products offer monitoring of SQL server and you might consider these products if you want a more automated GUI interface to monitoring indexes. Some of the products offer monitoring for other areas of SQL Server as well.

Windows performance monitor or perfmon is useful; you can use perfmon to monitor SQL counters.  Here are 3 common counters which, if they reveal something will warrant further scrutiny.

Be aware of  load and activity when monitoring with perfmon as database backups and other maintenance activities can cause spikes in these numbers. It is best to connect to the server from a different PC if you intend to monitor it with perfmon.

A good maintenance plan will include scheduled re indexing during off hours. Fragmented indices can cause Connect to become sluggish and might even cause fast-fails in a Connect cluster. If you start to see a lot of slow queries in the debug log, you should ensure that the Connect DB is being re-indexed regularly: Index maintenance is one of the easiest ways to keep your DB healthy and SQL Server provides wizards that help make index maintenance easy.

Open SQL Server Management Studio and open the management folder.

Give the Maintenance plan a name:

db4.fw

Choose the desired maintenance tasks: Rebuild Index & Update Statistics

db5.fw

Choose the Database you want to re-index:

db6.fw

Reorganize with the default amount of free space; the default amount is what it was initially created with.

db7.fw

Choose the same database to update statistics after you re-index.

db8.fw

Schedule a job to run the maintenance plan; provide a name and choose a schedule that suits your infrastructure:

db6.fw

Database performance and monitoring best practices will insure a responsive Connect server providing excellent end user experience.

ApplicationClusterin

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

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