ساعت ۱۰:۴۵ صبح کاربران میگویند سامانه کند شده است. CPU سرور هنوز در محدوده قابلقبول است، شبکه مشکلی ندارد و سرویس وب هم Down نیست؛ با این حال هر درخواست ساده چند ثانیه بیشتر طول میکشد. تیم زیرساخت به SQL Server نگاه میکند و با چند سؤال همزمان روبهرو میشود: آیا Session خاصی بقیه را Block کرده؟ Deadlock رخ داده؟ Log File در حال پر شدن است؟ Always On از Sync خارج شده؟ یا یک Query سنگین تمام ظرفیت را مصرف میکند؟
این سناریو تفاوت میان «زنده بودن SQL Server» و مانیتورینگ واقعی SQL Server را نشان میدهد. برای یک دیتابیس Production صرفاً Ping، Service Status یا CPU کافی نیست. باید بتوان رابطه میان Query، Session، Lock، Memory، I/O، Backup، Job و High Availability را دید و قبل از آنکه اختلال به Incident جدی تبدیل شود، نشانههای آن را پیدا کرد.
ManageEngine Applications Manager برای SQL Server یک Monitor تخصصی ارائه میکند که بر اساس مستندات رسمی ManageEngine، Agentless است و مجموعهای از شاخصهای Availability، Performance، Database، Sessions، Jobs، Backup/Restore، Replication، Configuration و Always On Availability Groups را جمعآوری میکند. در این مقاله یک الگوی عملی برای استفاده از این دادهها در NOC، DBA و تیم Application ارائه میشود.
چرا مانیتورینگ SQL Server فقط CPU و RAM نیست؟
بالا بودن CPU میتواند نشانه مشکل باشد، اما پایین بودن CPU لزوماً به معنی سلامت دیتابیس نیست. SQL Server ممکن است درگیر Blocking، Lock Wait، کندی Storage، Query Plan نامناسب، Connection Storm یا Lag در Replication باشد؛ درحالیکه CPU هنوز عادی است.
| علامت ظاهری | ریشه احتمالی در SQL Server | متریک مفید |
|---|---|---|
| کندی ناگهانی اپلیکیشن | Blocking Session | Blocked Sessions، Blocking Session ID، Wait Time |
| Timeout تراکنشها | Lock Wait یا Deadlock | Lock Waits/Min، Deadlocks/Min |
| افت تدریجی Performance | کمبود Buffer Cache یا Query Plan ضعیف | Buffer Cache Hit Ratio، Plan Cache Hit Ratio |
| کندی در ساعات خاص | Job یا Backup سنگین | Job History، Backup Duration |
| ریسک Failover | Always On Replica مشکل دارد | Synchronization State، Queue و Replica Health |
| رشد غیرعادی دیتابیس | Data/Log Growth | Database Size، Log Usage، Growth Trend |
در عمل، ارزش ابزار مانیتورینگ زمانی مشخص میشود که این متریکها کنار هم دیده شوند و فقط Alarm مجزا تولید نکنند.
Applications Manager برای SQL Server چه چیزهایی را میبیند؟
طبق راهنمای رسمی MS SQL Monitor در Applications Manager، دادهها در چند View اصلی سازماندهی میشوند:
- Overview و Availability؛
- Performance؛
- Database؛
- Sessions؛
- Jobs؛
- Backup/Restore؛
- Replication؛
- Users؛
- Configuration؛
- Always On Availability Groups؛
- Cluster Details.
این ساختار مهم است، چون DBA برای Incident فقط یک نمودار CPU نمیخواهد؛ باید بتواند از «سلامت Instance» به «Session»، از آنجا به «Query» و سپس به «Wait/Lock» برسد.
Agentless Monitoring چه مزیتی برای SQL Server دارد؟
Applications Manager برای مانیتورینگ SQL Server بهصورت Agentless طراحی شده است. یعنی برای جمعآوری متریکهای اصلی لازم نیست یک Agent اضافی داخل خود SQL Server نصب شود. این موضوع در محیطهای حساس Production مزیت دارد، زیرا Rollout سادهتر میشود و نگهداری Agent روی تعداد زیادی Instance کاهش پیدا میکند.
البته Agentless بودن به معنی «بدون طراحی امنیت» نیست. Credential، Network Access، Port، TLS و سطح دسترسی Account مانیتورینگ باید بهصورت کنترلشده تعریف شوند.
Blocking؛ یکی از مهمترین علل کندی که CPU آن را لو نمیدهد
Blocking زمانی رخ میدهد که یک Session منبعی را Lock کرده و Session دیگری منتظر آزاد شدن آن است. اگر Blocking Chain طولانی شود، کاربران ممکن است کندی شدید یا Timeout تجربه کنند.
در Applications Manager میتوان تعداد Blocked Sessions را دید و برای Sessionهای درگیر اطلاعاتی مانند Session ID، وضعیت، Database، Login، Host، CPU، I/O، زمان Block شدن و Blocking Session را بررسی کرد.
Runbook پیشنهادی برای Blocking
- تعداد Blocked Sessions را بررسی کنید.
- Blocking Session اصلی را پیدا کنید.
- Wait Time و Last Wait Type را ببینید.
- Query طرف Blocking و Query طرف Waiting را مقایسه کنید.
- بررسی کنید آیا Transaction غیرعادی باز مانده است.
- Application Owner را با Host/Program Name شناسایی کنید.
- قبل از Kill Session، اثر کسبوکاری را بسنجید.
نکته مهم این است که Kill Session نباید به یک واکنش خودکار بدون Context تبدیل شود. گاهی Session در حال اجرای تراکنش مالی یا عملیات Batch حساس است و Kill کردن آن هزینه بیشتری از چند دقیقه انتظار ایجاد میکند.
Deadlock با Blocking چه تفاوتی دارد؟
Blocking میتواند موقت و طبیعی باشد، اما Deadlock زمانی رخ میدهد که دو یا چند Session به شکل حلقهای منتظر Resource یکدیگر بمانند و SQL Server مجبور شود یکی را بهعنوان Victim انتخاب کند.
در Applications Manager علاوه بر Counterهای Deadlocks/Min، جزئیات Deadlock میتواند شامل Database، Victim Process، Lock Mode، Lock Resource، Victim Query، Query طرف دیگر و زمان رخداد باشد.
| موضوع | Blocking | Deadlock |
|---|---|---|
| ماهیت | یک Session منتظر دیگری است | انتظار حلقهای بین Sessionها |
| ممکن است خودبهخود رفع شود؟ | بله | SQL Server باید Victim انتخاب کند |
| اثر روی کاربر | کندی/Timeout | Error و Rollback تراکنش |
| اقدام اصلی | کشف Blocking Chain و Transaction طولانی | بررسی Query، Lock Order و Transaction Design |
Lock Wait و Latch Wait را جدا ببینید
Lock Wait معمولاً به همزمانی منطقی Transactionها مربوط است. Latch Wait بیشتر به همزمانی داخلی Engine و ساختارهای حافظه/صفحه مرتبط میشود. اگر این دو در Dashboard یکسان دیده شوند، تحلیل اشتباه میشود.
Applications Manager متریکهایی مانند Lock Requests، Lock Waits، Lock Timeouts، Average Lock Wait Time، Latch Waits و Average Latch Wait Time را مانیتور میکند. افزایش این شاخصها باید در کنار Query Load و I/O تحلیل شود.
Buffer Cache Hit Ratio چه چیزی میگوید؟
SQL Server تلاش میکند Data Pageها را در Memory نگه دارد تا مجبور نباشد برای هر Read به Disk مراجعه کند. Buffer Cache Hit Ratio تصویری از میزان پاسخگویی Cache به Readها میدهد.
مستندات ManageEngine اشاره میکند که مقدار بالا معمولاً نشانه استفاده مؤثر از Cache است. با این حال نباید یک Threshold ثابت را برای همه Workloadها قانون قطعی دانست. Trend، Working Set، Storage Latency و نوع Queryها اهمیت دارند.
اگر Buffer Cache افت کند، همزمان این موارد را ببینید:
- SQL Server Memory Usage؛
- Page Reads؛
- Disk I/O؛
- Working Set اپلیکیشنهای دیگر؛
- افزایش Data Volume؛
- Queryهای Scan-heavy.
Plan Cache Hit Ratio چرا مهم است؟
SQL Server برای اجرای Queryها Execution Plan میسازد. اگر Plan Cache به شکل مؤثر استفاده نشود، Compilation و Recompilation بیشتر میشود و CPU و Latency افزایش پیدا میکند.
Applications Manager متریکهایی مانند Plan Cache Hit Ratio، SQL Compilations/Min و SQL Recompilations/Min را ارائه میکند. ترکیب این سه شاخص برای تشخیص فشار ناشی از Compile مفید است.
Sessionها؛ از «چند Connection داریم؟» تا «چه کسی منابع را مصرف میکند؟»
Connection Count بهتنهایی کافی نیست. باید بدانید Connectionها از کجا آمدهاند و چه مقدار CPU، Memory و I/O مصرف میکنند.
در Session View میتوان اطلاعاتی مانند Host، Login، Database، Program، CPU Time، I/O، Memory Usage و وضعیت Session را بررسی کرد. این دادهها در Incidentهایی که یک Application Pool یا Batch Server Connectionهای غیرعادی باز میکند بسیار مفید است.
Connection Storm را چگونه تشخیص دهیم؟
گاهی مشکل از Query نیست؛ از تعداد Login/Logout زیاد است. Application بهجای Connection Pooling صحیح، مرتب Connection جدید باز و بسته میکند.
برای این سناریو:
- Active Connections را Trend کنید.
- Logins/Min و Logouts/Min را مقایسه کنید.
- Host یا Program Name غالب را پیدا کنید.
- Connection Pool Configuration را بررسی کنید.
- همزمان CPU و Memory را ببینید.
Slow Query؛ وقتی دیتابیس سالم است اما کاربر کندی حس میکند
در بسیاری از Incidentها Availability کاملاً سبز است، اما یک یا چند Query زمان پاسخ را خراب کردهاند. Applications Manager در لایه Database و APM امکان Drill-down به SQL Callهای کند را فراهم میکند و در APM Insight نیز Slow Database Callها میتوانند در Trace تراکنش دیده شوند.
این موضوع زمانی ارزش بیشتری دارد که Application و SQL Server هر دو زیر مانیتورینگ باشند. در این حالت میتوان زنجیره زیر را دید:
User Transaction → Application Method → Database Call → Slow SQL → SQL Server Wait/Lock
برای معماریهای Microservice که Trace اهمیت بیشتری دارد، مقاله OpenTelemetry در Applications Manager مکمل این موضوع است.
چرا فقط «Top Query by Duration» کافی نیست؟
یک Query ممکن است هر بار سریع باشد اما در دقیقه هزاران بار اجرا شود. Query دیگری شاید فقط چند بار اجرا شود اما هر اجرا ۲۰ ثانیه طول بکشد. هر دو میتوانند مشکلساز باشند.
تحلیل Query باید حداقل این ابعاد را در نظر بگیرد:
- Duration؛
- Execution Count؛
- CPU Cost؛
- Reads/Writes؛
- Wait Type؛
- Blocking Impact؛
- Business Transaction مرتبط.
Database Growth و Log Usage را قبل از بحران ببینید
یکی از Incidentهای کلاسیک، پر شدن Disk یا Transaction Log است. اگر فقط Availability مانیتور شود، هشدار زمانی میرسد که سرویس آسیب دیده است.
Database-level Monitoring باید شامل Size، Data File Growth، Log File Usage و Trend مصرف باشد. هدف این نیست که صرفاً در ۹۵٪ هشدار بدهیم؛ باید بتوانیم بر اساس Rate Growth ظرفیت آینده را تخمین بزنیم.
Backup Monitoring؛ موفق بودن Job کافی نیست
ممکن است Backup Job اجرا شود اما آخرین Full Backup بیش از حد قدیمی باشد، مدت اجرای Backup رشد کرده باشد یا Restore Readiness وجود نداشته باشد.
Applications Manager Viewهای Backup/Restore را برای SQL Server فراهم میکند. در طراحی Dashboard بهتر است این KPIها دیده شوند:
- Age آخرین Full Backup؛
- Age آخرین Differential Backup؛
- Age آخرین Log Backup؛
- Backup Duration؛
- Backup Failure؛
- Backup Size Trend.
وجود Backup بهتنهایی تضمین Recovery نیست؛ Restore Test باید بخشی از DR Runbook باشد.
SQL Agent Jobها را وارد Performance Analysis کنید
بسیاری از کندیهای دورهای دقیقاً همزمان با Index Maintenance، ETL، Report Generation یا Backup Job رخ میدهند. اگر Job History جدا از Performance Dashboard باشد، Correlation سخت میشود.
Applications Manager وضعیت Current Execution، Last Run Status، Run Time، Duration و Retry را برای Jobها نمایش میدهد. وقتی Latency اپلیکیشن در ساعت خاص بالا میرود، Job Timeline یکی از اولین چیزهایی است که باید بررسی شود.
Always On Availability Groups؛ فقط «Replica Up» کافی نیست
در SQL Server Always On ممکن است Replica روشن باشد اما Synchronization مطلوب نباشد یا Queue رشد کند. در این شرایط Failover ممکن است ریسکدار شود.
Applications Manager برای Availability Groupها View تخصصی دارد. برای محیطهای HA این موارد را در Dashboard قرار دهید:
- Replica Health؛
- Synchronization State؛
- Send/Redo Queue؛
- Failover Readiness؛
- Database-level Replica Status.
Alert Design؛ برای هر Spike تیکت نسازید
اگر هر افزایش کوتاه CPU، Lock یا Connection یک Incident بسازد، تیم خیلی زود Alert Fatigue میگیرد. Threshold باید بر اساس Severity و Persistence طراحی شود.
| متریک | نمونه منطق هشدار | شدت |
|---|---|---|
| SQL Server Down | عدم دسترسی در چند Poll متوالی | Critical |
| Blocked Sessions | بیش از حد مجاز برای مدت مشخص | High |
| Deadlock | تکرار بالاتر از Baseline | High |
| Log Usage | عبور از Threshold + Growth Trend | High |
| Backup Age | خارج شدن از RPO تعریفشده | Critical |
| Job Failure | فقط Jobهای Business-critical | High |
| Buffer Cache | افت پایدار نسبت به Baseline | Medium |
Static Threshold یا Dynamic Threshold؟
برای ظرفیتهای قطعی مانند Log Usage، Disk Space یا Backup Age، Static Threshold مفید است. برای متریکهای رفتاری مانند Connections، CPU یا Latency، Baseline و Dynamic Threshold میتواند False Positive را کاهش دهد.
Applications Manager علاوه بر Thresholdهای ثابت، قابلیت Alerting و تحلیل Trend را در پلتفرم Observability خود ارائه میکند. معیار انتخاب باید رفتار واقعی Workload باشد.
از Alert دیتابیس تا Incident در ServiceDesk Plus
مانیتورینگ وقتی ارزش عملی پیدا میکند که Alert مهم به Workflow پاسخگویی متصل شود. برای Incidentهای SQL Server میتوان مسیر زیر را طراحی کرد:
- Applications Manager مشکل را تشخیص میدهد.
- Severity و Business Service مشخص میشود.
- Incident یا Notification برای تیم مسئول ایجاد میشود.
- DBA و Application Owner بر اساس Runbook اقدام میکنند.
- در صورت Change لازم، Change Record ثبت میشود.
- پس از Recovery، KPI و Root Cause ثبت میشود.
برای طراحی Integration امن بین Monitoring و ITSM، مقاله Webhook در ServiceDesk Plus؛ اتصال امن ITSM به ERP، CRM و Monitoring مسیر مکمل مناسبی است.
Dashboard مناسب برای DBA چه شکلی است؟
DBA معمولاً به Dashboardی نیاز دارد که بهجای تعداد زیاد Widget، چند سؤال کلیدی را سریع جواب دهد:
- کدام Instance Down یا Degraded است؟
- کدام Database سریعتر از معمول رشد میکند؟
- کدام Instance Blocking دارد؟
- کدام Deadlockها تکرار شدهاند؟
- کدام Job Fail شده است؟
- کدام Backup از RPO خارج شده است؟
- کدام Availability Group Sync مشکل دارد؟
Dashboard مناسب NOC با Dashboard DBA فرق دارد
NOC به جزئیات Query Plan نیاز ندارد؛ DBA دارد. بنابراین یک Dashboard واحد برای همه تیمها معمولاً نتیجه خوبی نمیدهد.
| تیم | تمرکز اصلی |
|---|---|
| NOC | Availability، Health، Critical Alarm، Service Impact |
| DBA | Sessions، Locks، Deadlocks، Backup، Jobs، Replication |
| Application Team | Slow Transaction، SQL Call، Response Time، Error |
| Management | SLA، Incident Trend، Capacity، Risk |
Applications Manager و APM Insight را چه زمانی کنار هم استفاده کنیم؟
Database Monitor میگوید داخل SQL Server چه میگذرد. APM Insight میتواند نشان دهد کدام Transaction اپلیکیشن به همان Query یا Database Call وابسته است.
این ترکیب برای Java، .NET، PHP، Node.js، Python و سایر Stackهای پشتیبانیشده ارزش بالایی دارد، چون Root Cause از لایه Business Transaction تا Database قابل دنبال کردن میشود.
سناریو: کاربر میگوید «ثبت سفارش کند است»
یک مسیر عملی میتواند چنین باشد:
- در APM، Transaction «ثبت سفارش» کند شده است.
- Trace نشان میدهد بخش عمده زمان در Database Call مصرف میشود.
- SQL Monitor نشان میدهد Query مربوطه Block شده است.
- Blocking Session از یک Batch Job آمده است.
- Job History نشان میدهد ETL زودتر از Window معمول اجرا شده است.
- Incident حل میشود، اما Root Cause در Scheduler/Job Governance اصلاح میشود.
این نوع Correlation از مانیتورینگ جزیرهای بسیار ارزشمندتر است.
آیا Applications Manager فقط برای SQL Server است؟
خیر. صفحه رسمی Applications Manager از مانیتورینگ طیف گستردهای از دیتابیسهای Relational، NoSQL، In-memory و Big Data پشتیبانی میکند. برای سازمانی که هم SQL Server دارد، هم PostgreSQL، Oracle، MongoDB یا Redis، مزیت اصلی یک View یکپارچه است.
صفحه ManageEngine Applications Manager در مدانت مرجع اصلی برای بررسی قابلیتها، استعلام لایسنس، استقرار و پشتیبانی این راهکار است.
Professional یا Enterprise؛ انتخاب Edition به Scale بستگی دارد
ManageEngine در صفحه رسمی محصول، Professional Edition را برای محیطهای کوچکتر و متوسط معرفی میکند و Enterprise Edition را برای محیطهای بزرگتر با Distributed Monitoring و Failover در نظر میگیرد. انتخاب Edition نباید فقط بر اساس تعداد SQL Server باشد؛ تعداد کل Monitorها، Siteها، Applicationها، HA نیازمندی و معماری سازمان مهم است.
در مرحله Sizing بهتر است این موارد مشخص شوند:
- تعداد SQL Instanceها؛
- تعداد Databaseها؛
- تعداد Application Monitorها؛
- تعداد Site یا Data Center؛
- Retention موردنیاز؛
- نیاز به HA؛
- نیاز به Distributed Monitoring؛
- تعداد کاربرهای NOC/DBA.
Runbook عملی برای کندی SQL Server
- Availability و Alarmهای Instance را بررسی کنید.
- CPU، Memory و I/O را ببینید.
- Blocked Sessions و Blocking Session را بررسی کنید.
- Deadlockهای جدید را مرور کنید.
- Wait و Lock Metrics را بررسی کنید.
- Connection Count و Login Rate را ببینید.
- Jobهای همان بازه زمانی را بررسی کنید.
- Backup یا Maintenance Activity را چک کنید.
- Database Growth و Log Usage را ببینید.
- اگر HA دارید، Always On Health را بررسی کنید.
- اگر APM فعال است، Transaction و Slow SQL را Correlate کنید.
- پس از Recovery، Root Cause و Preventive Action را ثبت کنید.
KPIهای پیشنهادی برای مانیتورینگ SQL Server
- Database Availability؛
- Average Query/Transaction Response Time؛
- Blocked Session Count؛
- Deadlock Rate؛
- Average Lock Wait Time؛
- Buffer Cache Hit Ratio Trend؛
- SQL Compilation/Recompilation Rate؛
- Database Growth Rate؛
- Transaction Log Usage؛
- Backup Compliance نسبت به RPO؛
- Job Success Rate؛
- Always On Replica Health؛
- Mean Time to Detect Database Incident؛
- Mean Time to Resolve Database Incident.
۱۰ خطای رایج در مانیتورینگ SQL Server
- فقط CPU و RAM را مانیتور کردن.
- نادیده گرفتن Blocking و Deadlock.
- ساخت Alert برای هر Spike کوتاه.
- نداشتن Baseline برای ساعات پیک.
- ندیدن Jobها کنار Performance.
- مانیتور نکردن Backup Age.
- مانیتور نکردن Log Usage و Growth.
- جدا کردن APM از Database Monitoring.
- نداشتن Runbook برای Blocking.
- فرستادن همه Alertها مستقیم به Incident Queue بدون Severity.
نکات کلیدی
- SQL Server میتواند Up باشد ولی از دید کاربر کاملاً کند باشد.
- Blocking و Deadlock باید از CPU و Memory جدا تحلیل شوند.
- Session-level Visibility برای یافتن Host، User و Query مشکلساز ضروری است.
- Backup، Job و Always On بخشی از Performance Monitoring واقعی هستند.
- ترکیب Database Monitor با APM Insight فاصله میان Query و Business Transaction را کم میکند.
- Threshold باید بر اساس Business Impact و رفتار واقعی Workload طراحی شود.
- Integration با ITSM باید فقط Alarmهای Actionable را به Incident تبدیل کند.
منابع
- ManageEngine Applications Manager — MS SQL DB Server Monitoring
- ManageEngine — SQL Server Performance Monitoring Guide
- ManageEngine Applications Manager — Product Overview
- ManageEngine — APM Insight Overview
سخن پایانی
مانیتورینگ SQL Server زمانی ارزش واقعی ایجاد میکند که تیم بتواند از یک Alarm کلی به علت فنی مشخص برسد: کدام Session، کدام Query، کدام Lock، کدام Job یا کدام Replica باعث اختلال شده است. صرفاً دانستن اینکه SQL Server روشن است، برای سرویسهای حیاتی کافی نیست.
Applications Manager با ترکیب Database Monitoring، Session Visibility، Lock/Deadlock Analysis، Job و Backup Monitoring، Always On Monitoring و ارتباط با APM، امکان میدهد DBA و تیم Application روی یک تصویر مشترک از سلامت سرویس کار کنند.
مدانت برای استعلام و خرید لایسنس Applications Manager، طراحی Scope، نصب و استقرار، مانیتورینگ SQL Server و سایر دیتابیسها، طراحی Dashboard و Alert، Integration با ServiceDesk Plus، آموزش و پشتیبانی خدمات تخصصی ارائه میکند. برای بررسی محصول به صفحه Applications Manager مدانت، برای استعلام تجاری به فروشگاه و استعلام ManageEngine و برای طراحی معماری مانیتورینگ به تماس با مدانت مراجعه کنید.
