SQL Server Startup Process از Service Control Manager تا اولین Login

ساعت سه بامداد، تیم زیرساخت یک بانک پس از اعمال Patch امنیتی ماهانه ویندوز، سرورهای پایگاه داده را Reboot می‌کند. همه سرورها به‌جز یکی بدون مشکل بالا می‌آیند روی آن یکی، سرویس SQL Server در Service Control Manager در وضعیت «در حال شروع» می‌ماند و بعد از چند دقیقه با خطا متوقف می‌شود. DBA کشیک باید در کمتر از پانزده دقیقه تصمیم بگیرد مشکل از کجاست: آیا سرویس اصلاً اجرا نشده، یا اجرا شده ولی نتوانسته دیتابیس master را باز کند، یا master باز شده ولی یکی از دیتابیس‌های کاربری یا حتی msdb در حالت Recovery گیر کرده و همین باعث شده SQL Server Agent هم بالا نیاید؟

بدون شناخت دقیق مراحل داخلی Startup Process، پاسخ به این سؤال حدس و آزمایش است. با شناخت این فرآیند، DBA می‌داند دقیقاً کدام فایل لاگ را نگاه کند و کدام مرحله را باید بررسی کند. این مقاله همان مسیر را، از لحظه‌ای که Windows درخواست اجرای سرویس را صادر می‌کند تا لحظه‌ای که SQL Server آماده پذیرش اولین اتصال TDS از یک کاربر واقعی می‌شود، گام‌به‌گام و بدون حذف هیچ مرحله میانی باز می‌کند.

SQL Server از دید سیستم‌عامل یک سرویس ویندوزی مثل بقیه، با یک تفاوت مهم

از نگاه Windows، SQL Server چیزی بیش از یک فایل اجرایی به نام sqlservr.exe نیست که تحت مدیریت Service Control Manager (SCM) اجرا می‌شود همان مدیری که سرویس‌های Print Spooler یا DNS Client را هم مدیریت می‌کند. وقتی سیستم بالا می‌آید یا کسی دستور net start MSSQLSERVER را اجرا می‌کند، SCM بر اساس تنظیمات Registry مربوط به آن سرویس، مسیر اجرایی، حساب سرویس (Service Account) و پارامترهای خط فرمان را می‌خواند و پروسه را اجرا می‌کند.

تفاوت مهم اینجاست: SCM فقط مسئول اجرای پروسه و گزارش «آیا پروسه بالا آمده یا نه» است SCM هیچ اطلاعی از اینکه آیا master بارگذاری شده، msdb ریکاور شده، یا شبکه آماده پذیرش اتصال است ندارد. به همین دلیل، وضعیت «Running» در Services.msc به‌معنای «سرور آماده پاسخگویی است» نیست صرفاً به‌معنای «پروسه sqlservr.exe در حافظه اجرا شده» است. خطای واقعی معمولاً داخل ERRORLOG خود SQL Server ثبت می‌شود، نه در Event Viewer سطح سرویس.

نمای کامل زنجیره Startup از Boot تا پذیرش اتصال

پیش از ورود به جزئیات هر مرحله، دیدن کل مسیر در یک نگاه کمک می‌کند تا هر بخش بعدی در جای درست خودش قرار بگیرد:

همان‌طور که در این نمودار دیده می‌شود، Startup واقعی SQL Server خیلی فراتر از «آنلاین شدن دیتابیس‌ها» است تا زمانی که Listener شبکه آماده Accept Connection نشود، از دید یک کاربر واقعی، سرور هنوز در دسترس نیست، حتی اگر همه دیتابیس‌ها از نظر داخلی ONLINE باشند. بخش‌های بعدی این مقاله، هر خط از این نمودار را با جزئیات فنی و نمونه واقعی باز می‌کنند.

خواندن پارامترهای راه‌اندازی نقطه‌ای که پیش از هر چیز اهمیت دارد

پیش از آنکه sqlservr.exe کوچک‌ترین کاری با داده انجام دهد، باید بداند مسیر فایل‌های اصلی کجاست. این اطلاعات از سه پارامتر Startup خوانده می‌شود: -d مسیر فایل داده master، -l مسیر فایل لاگ master، و -e مسیر فایلی که ERRORLOG در آن نوشته می‌شود.

-dC:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\master.mdf
-eC:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Log\ERRORLOG
-lC:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\DATA\mastlog.ldf

اگر هرکدام از این مسیرها اشتباه باشد، سرویس اصلاً قادر به یافتن master نخواهد بود و بلافاصله متوقف می‌شود این یکی از رایج‌ترین دلایل شکست Startup پس از عملیات‌های نگهداری دستی سرور است، مخصوصاً در محیط‌هایی با چند Instance روی یک سرور فیزیکی.

در همین مرحله، ERRORLOG جدید ایجاد و چرخش لاگ (Log Cycling) انجام می‌شود، به‌طوری‌که ERRORLOG.1، ERRORLOG.2 و به همین ترتیب نگهداری می‌شوند. اولین خطی که نوشته می‌شود، نسخه دقیق SQL Server، Edition و پارامترهای فعال Startup است همیشه اولین جایی که DBA باید در عیب‌یابی Startup نگاه کند، همین فایل است.

مقداردهی اولیه SQLOS پیش از آنکه حتی یک صفحه داده خوانده شود

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

در این مرحله، SQL Server توپولوژی NUMA سرور را شناسایی می‌کند و برای هر NUMA Node، یک یا چند Scheduler به نام SOS_Scheduler می‌سازد که بعداً Workerهای اجرای Query روی آن‌ها زمان‌بندی می‌شوند. محدوده حافظه اولیه بر اساس max server memory و min server memory تخمین زده می‌شود، هرچند تخصیص واقعی حافظه به‌مرور رخ می‌دهد.

SELECT cpu_count, hyperthread_ratio, physical_memory_kb,
       sqlserver_start_time, scheduler_count
FROM sys.dm_os_sys_info;

اگر همین مرحله با خطا مواجه شود، معمولاً ریشه آن در تنظیمات نادرست حافظه یا محدودیت‌های سطح سیستم‌عامل مانند Lock Pages in Memory بدون مجوز کافی است.

بارگذاری و ریکاوری master نقطه بدون بازگشت

اکنون نوبت به مهم‌ترین گام می‌رسد: باز کردن دیتابیس master. اگر master باز نشود، عملاً هیچ‌چیز دیگری در Instance اتفاق نمی‌افتد، چون تمام Metadata مربوط به سایر دیتابیس‌ها، Loginها و پیکربندی سرور در همین دیتابیس نگهداری می‌شود. به همین دلیل، master تنها دیتابیسی است که مسیر فایل آن مستقیماً از پارامترهای Startup خوانده می‌شود.

فرآیند ریکاوری هر دیتابیس، از جمله master، از یک الگوی سه‌مرحله‌ای پیروی می‌کند که ریشه در تئوری ARIES دارد: مرحله Analysis که فایل لاگ تراکنش را می‌خواند تا مشخص کند کدام تراکنش‌ها هنگام خاموش‌شدن ناگهانی سرور، ناتمام مانده‌اند مرحله Redo که تمام تغییرات ثبت‌شده در لاگ را دوباره روی صفحات داده اعمال می‌کند و مرحله Undo که تغییرات تراکنش‌های ناتمام را برمی‌گرداند.

می‌توان این سه مرحله را به‌صورت یک نمودار زمانی ساده تصور کرد:

Analysis   ██████
Redo       ██████████████
Undo       █████
ONLINE     ▶ آماده پاسخگویی

طول هر بخش متناسب با حجم واقعی تراکنش‌های ناتمام است در یک دیتابیس با Shutdown تمیز، بخش Redo و Undo تقریباً خالی است، اما پس از یک قطعی برق ناگهانی با تراکنش‌های حجیم باز، همین بخش می‌تواند دقیقه‌ها طول بکشد. اگر فایل master.mdf آسیب دیده باشد، باید با روش‌های اضطراری مانند اجرای sqlservr.exe -T3608 یا Rebuild از نسخه پشتیبان اقدام کرد.

Resource Database دیتابیس پنهانی که همه چیز را ممکن می‌کند

بین بارگذاری master و ریکاوری model، یک دیتابیس کمتر شناخته‌شده اما حیاتی بارگذاری می‌شود: Resource Database. این دیتابیس، برخلاف سایر دیتابیس‌های سیستمی، در حالت عادی در فهرست sys.databases یا در SSMS نمایش داده نمی‌شود و به همین دلیل بسیاری از DBAها حتی از وجود آن بی‌خبرند، با اینکه بدون آن، SQL Server اصلاً نمی‌تواند اجرا شود.

Resource Database شامل تمام Object‌های سیستمی SQL Server است: Stored Procedureهای سیستمی (مانند sp_who یا sp_helpdb)، Viewهای Catalog (مانند sys.tables یا sys.columns)، و توابع سیستمی. نکته مهم این است که این Objectها فیزیکاً فقط یک‌بار، در همین دیتابیس، ذخیره شده‌اند، اما به‌صورت منطقی در هر دیتابیس دیگری روی همان Instance، از طریق اسکیمای sys، قابل مشاهده و استفاده‌اند یعنی وقتی در دیتابیس خودتان SELECT * FROM sys.tables می‌نویسید، در واقع دارید به Resource Database ارجاع می‌دهید، بدون آنکه نامش را ذکر کرده باشید.

فایل‌های فیزیکی این دیتابیس، mssqlsystemresource.mdf و mssqlsystemresource.ldf، در پوشه Binn نصب SQL Server قرار دارند، نه در پوشه Data معمول، و این دیتابیس همیشه Read-only است هیچ کاربری، حتی sysadmin، نمی‌تواند مستقیماً در آن تغییری اعمال کند. این طراحی یک مزیت عملیاتی بزرگ دارد: وقتی مایکروسافت یک Service Pack یا Cumulative Update منتشر می‌کند، بخش زیادی از تغییرات صرفاً جایگزینی همین دو فایل است، نه اجرای اسکریپت‌های Upgrade روی تک‌تک دیتابیس‌های کاربری این یعنی زمان Downtime هنگام Patch کردن SQL Server، به‌مراتب کوتاه‌تر از مدلی است که هر Object سیستمی در هر دیتابیس جداگانه کپی می‌شد.

از منظر عیب‌یابی، اگر فایل Resource Database آسیب ببیند یا در دسترس نباشد، Instance اصلاً بالا نمی‌آید، حتی اگر master کاملاً سالم باشد پیام خطای مربوط به این حالت معمولاً به‌صراحت در ERRORLOG به mssqlsystemresource اشاره می‌کند و راه‌حل معمول، بازیابی این دو فایل از یک نصب سالم با همان نسخه دقیق Build است.

model و msdb الگو و حافظه عملیاتی سرور

پس از Resource Database، نوبت به model می‌رسد. این دیتابیس دو نقش دارد: الگوی ساخت هر دیتابیس جدید کاربری، و مهم‌تر از آن، الگوی بازسازی tempdb در هر بار راه‌اندازی سرور. جزئیات این نقش دوم در بخش بعدی بررسی می‌شود.

بلافاصله پس از model، دیتابیس msdb ریکاور می‌شود دیتابیسی که در توضیحات سطحی Startup اغلب نادیده گرفته می‌شود، در حالی که نقش عملیاتی بسیار حساسی دارد. msdb محل نگهداری تعریف Jobهای SQL Server Agent، زمان‌بندی (Schedule) آن‌ها، تاریخچه کامل Backup و Restore (جداول backupset و backupfile)، پیکربندی Database Mail، تعریف Maintenance Planها، و در بسیاری از نسخه‌ها، فضای ذخیره‌سازی Package‌های SSIS است.

وابستگی مهمی که کمتر گفته می‌شود این است: SQL Server Agent، که مسئول اجرای همه Jobهای زمان‌بندی‌شده سازمان (از Backup شبانه گرفته تا Job‌های ETL) است، برای شروع کار خودش نیاز دارد msdb کاملاً ریکاور و در دسترس باشد. اگر msdb به هر دلیلی (آسیب فایل، فضای دیسک پر، یا قفل شدن توسط یک Process دیگر) نتواند ریکاور شود، SQL Server Agent اصلاً بالا نمی‌آید، حتی اگر تمام دیتابیس‌های کاربری کاملاً سالم و ONLINE باشند. این یکی از رایج‌ترین سناریوهایی است که در آن، DBA گزارش می‌دهد «همه‌چیز خوب است ولی Backupهای شبانه اجرا نشده‌اند» ریشه آن معمولاً یک msdb ناسالم است، نه یک مشکل در تعریف خود Jobها.

tempdb چرا هر بار از نو ساخته می‌شود

تفاوت بنیادین tempdb با سایر دیتابیس‌های سیستمی این است که tempdb هرگز از دیسک بازیابی نمی‌شود در هر بار Startup، بر اساس ساختار model، از نو ساخته می‌شود. این طراحی عمدی است، چون tempdb ماهیتاً فضای موقتی است (Sort، Hash Join، جداول موقت، Row Versioning) و نیازی به حفظ داده بین راه‌اندازی‌ها ندارد بازسازی کامل آن هم سریع‌تر از اجرای فرآیند کامل ریکاوری روی آن است.

اثر عملی این طراحی این است که هرگونه تغییر اندازه دستی که مستقیماً روی فایل‌های tempdb انجام شده، پس از هر Restart از بین می‌رود مگر آنکه از طریق ALTER DATABASE به‌درستی ثبت شده باشد. در سرورهای پرترافیک بانکی یا تجارت الکترونیک، اندازه‌گذاری نادرست اولیه tempdb یکی از رایج‌ترین دلایل کندی سراسری بلافاصله پس از هر Restart برنامه‌ریزی‌شده است.

آوردن دیتابیس‌های کاربری آنلاین فرآیندی موازی، نه ترتیبی

پس از آماده شدن دیتابیس‌های سیستمی، SQL Server شروع به بارگذاری دیتابیس‌های کاربری می‌کند. این فرآیند، برخلاف تصور رایج، لزوماً ترتیبی نیست SQL Server از مجموعه‌ای از Threadهای موازی برای ریکاوری چند دیتابیس هم‌زمان استفاده می‌کند.

هر دیتابیس کاربری، مستقل از بقیه، همان سه مرحله Analysis، Redo و Undo را طی می‌کند. یعنی اگر یک دیتابیس حجیم با تراکنش‌های ناتمام زیاد داشته باشد، ممکن است در حالت RECOVERING بماند، در حالی که سایر دیتابیس‌های کوچک‌تر از قبل ONLINE شده‌اند. این یعنی گزارش «SQL Server بالا آمده» می‌تواند گمراه‌کننده باشد.

SELECT name, state_desc, recovery_model_desc
FROM sys.databases;

مقادیر رایج state_desc شامل ONLINE، RECOVERING، RECOVERY_PENDING (نیازمند دخالت دستی)، SUSPECT (لاگ تراکنش آسیب‌دیده) و RESTORING است. برای یک اپراتور مخابراتی با ده‌ها دیتابیس روی یک Instance، پایش این وضعیت بلافاصله پس از هر Restart، بخشی جدایی‌ناپذیر از فرآیند استاندارد نگهداری است.

Startup Stored Procedures کدی که پیش از اولین اتصال کاربر اجرا می‌شود

برخی سازمان‌ها نیاز دارند منطقی مشخص، دقیقاً بلافاصله پس از راه‌اندازی سرور اجرا شود. SQL Server این قابلیت را از طریق Startup Stored Procedures فراهم می‌کند: هر Stored Procedure که با sp_procoption علامت‌گذاری شده باشد، در همین فاز از فرآیند Startup به‌صورت خودکار اجرا می‌شود.

EXEC sys.sp_procoption
    @ProcName = 'usp_LogServerRestart',
    @OptionName = 'startup',
    @OptionValue = 'on';

این Stored Procedureها باید در master تعریف شوند و بسیار سبک باشند اگر یکی از آن‌ها با خطا متوقف شود یا زمان زیادی طول بکشد، می‌تواند کل فرآیند Startup را کند کند. توصیه عملی این است که هرگونه پردازش سنگین به یک Job جداگانه که بعد از Startup کامل اجرا می‌شود، منتقل شود.

Trace Flagها در Startup تغییر رفتار پیش‌فرض موتور

برخی رفتارهای پیش‌فرض SQL Server را می‌توان از طریق Trace Flagهایی که در پارامترهای Startup قرار می‌گیرند تغییر داد. این Flagها یا از طریق SQL Server Configuration Manager به‌صورت دائمی (مثلاً -T1118) اضافه می‌شوند، یا به‌صورت موقت با DBCC TRACEON در یک نشست فعال می‌شوند که با Restart از بین می‌رود.

برخی از پرکاربردترین‌ها: -T3226 که پیام‌های موفقیت‌آمیز Backup را از ERRORLOG حذف می‌کند -T1118 که تخصیص صفحات Uniform Extent را برای کاهش رقابت در tempdb تغییر می‌دهد و -T2371 که آستانه به‌روزرسانی خودکار آمار را برای جداول بزرگ هوشمندتر می‌کند.

توصیه عملی این است که هر Trace Flag اضافه‌شده باید در سند پیکربندی داخلی سازمان مستند شود رایج‌ترین منبع سردرگمی در تیم‌های بزرگ DBA، ناآگاهی از دلیل رفتار متفاوت یک سرور خاص نسبت به بقیه است، دقیقاً به این دلیل که یک Trace Flag سال‌ها پیش بدون مستندسازی اضافه شده.

مقداردهی پروتکل‌های شبکه از موتور آماده تا قابل‌دسترس

پس از آنکه لایه داخلی موتور (SQLOS و همه دیتابیس‌های سیستمی و کاربری) آماده شد، SQL Server وارد فازی می‌شود که کمتر در توضیحات رایج Startup دیده می‌شود اما بدون آن، هیچ کاربری قادر به اتصال نخواهد بود: مقداردهی پروتکل‌های شبکه. این پروتکل‌ها، که در SQL Server Configuration Manager قابل فعال یا غیرفعال کردن‌اند، شامل Shared Memory (برای اتصال محلی روی همان سرور)، TCP/IP (رایج‌ترین پروتکل برای اتصال از راه دور)، و Named Pipes (بیشتر برای سازگاری با محیط‌های قدیمی) هستند.

در همین مرحله، Dedicated Admin Connection (DAC) نیز فعال می‌شود یک کانال اتصال کاملاً جدا که حتی وقتی SQL Server به‌دلیل اشباع منابع (مثلاً تمام شدن Workerهای موجود) قادر به پذیرش اتصال عادی نیست، همچنان برای یک اتصال مدیریتی واحد در دسترس می‌ماند. برای فعال کردن دسترسی از راه دور به DAC:

EXEC sp_configure 'remote admin connections', 1;
RECONFIGURE;

این طراحی دقیقاً برای سناریوهایی وجود دارد که سرور «Running» است اما به‌شدت کند یا قفل‌شده به‌نظر می‌رسد DAC مسیر ورود اضطراری DBA برای تشخیص علت، بدون رقابت با اتصالات عادی کاربران، است.

ثبت Endpointها و آماده‌سازی نهایی برای پذیرش اتصال

پس از مقداردهی پروتکل‌ها، SQL Server باید Endpointهای مربوط به هر نوع ارتباط را ثبت (Register) کند این یعنی برای هر پروتکل فعال، یک Listener روی پورت مشخص باز می‌شود و آماده دریافت بسته‌های ورودی می‌گردد. Endpoint اصلی، TDS Endpoint است که ارتباطات معمول کاربران (از طریق SSMS، اپلیکیشن، یا ابزارهای BI) از آن عبور می‌کنند به‌طور پیش‌فرض روی پورت 1433 برای TCP.

در کنار آن، Endpointهای تخصصی دیگری هم ممکن است ثبت شوند: Endpoint مربوط به DAC (روی یک پورت جداگانه، معمولاً پویا)، و در صورت پیکربندی Database Mirroring یا Always On Availability Groups، یک Endpoint اختصاصی دیگر برای ارتباط بین Replicaها که از پروتکل جداگانه‌ای (نه TDS معمولی) استفاده می‌کند. اگر این Endpoint به‌درستی ثبت نشود یا توسط Firewall مسدود باشد، Replicaهای یک Availability Group قادر به همگام‌سازی با یکدیگر نخواهند بود، حتی اگر خود SQL Server engine کاملاً سالم باشد.

فقط پس از تکمیل موفق این مرحله، سرور رسماً وارد وضعیتی می‌شود که در ERRORLOG با عبارتی مشابه «Server is listening on» گزارش می‌شود این خط، مرز واقعی میان «موتور آماده است» و «سرور برای کاربران در دسترس است» را مشخص می‌کند.

فاز Login از اولین بسته TDS تا ایجاد Session

وقتی یک اپلیکیشن یا SSMS تلاش می‌کند به سروری که تازه بالا آمده متصل شود، فرآیندی چندمرحله‌ای، مستقل از آنچه تا اینجا توضیح داده شد، آغاز می‌شود. ابتدا یک TDS Handshake (بر پایه پروتکل Tabular Data Stream) رخ می‌دهد که در آن، کلاینت و سرور نسخه پروتکل و قابلیت‌های مشترک را مذاکره می‌کنند. سپس یک بسته Pre-Login رد و بدل می‌شود که در آن، نیاز به رمزنگاری (Encryption) ارتباط، بر اساس تنظیمات Force Encryption سرور و درخواست کلاینت، مشخص می‌شود.

پس از این توافق اولیه، بسته Login ارسال می‌شود که شامل اطلاعات هویتی است بسته به نوع احراز هویت پیکربندی‌شده، این می‌تواند یک توکن Windows Authentication (از طریق SSPI) یا یک نام کاربری/رمز عبور SQL Authentication باشد. SQL Server این اطلاعات را در برابر Loginهای تعریف‌شده در master بررسی می‌کند اگر معتبر باشد، یک Session جدید ساخته می‌شود که شامل Context امنیتی، تنظیمات پیش‌فرض دیتابیس (بر اساس Default Database تعریف‌شده برای آن Login)، و تخصیص یک Worker Thread از میان Schedulerهای SQLOS برای پردازش دستورات آن نشست است.

این فاز، اگرچه به‌ظاهر جدا از Startup اصلی سرور به‌نظر می‌رسد، در واقع اولین آزمایش واقعی این است که آیا تمام مراحل قبلی (شبکه، Endpoint، ریکاوری master و msdb) به‌درستی کامل شده‌اند یا نه شکست در هرکدام از این مراحل قبلی، معمولاً خودش را دقیقاً همین‌جا، در قالب Timeout یا خطای اتصال برای اولین کاربر، نشان می‌دهد.

Startup در Failover Cluster و Always On Availability Groups یک لایه اضافه

در محیط‌هایی که SQL Server روی یک Windows Server Failover Cluster (WSFC) یا با Always On Availability Groups پیکربندی شده، فرآیند Startup یک لایه اضافه دارد. در این معماری، SQL Server به‌عنوان یک Cluster Resource تعریف شده که توسط Cluster Service مدیریت می‌شود، نه مستقیماً توسط SCM بر پایه تنظیمات Startup Type معمول.

پیش از آنکه sqlservr.exe اصلاً اجرا شود، باید منابع پیش‌نیاز (مانند دیسک‌های مشترک در FCI) در دسترس باشند و Quorum کافی برای این Node تأمین شده باشد. اگر Cluster نتواند Quorum لازم را تشکیل دهد، منبع SQL Server اصلاً تلاش برای اجرا نمی‌کند، حتی اگر خود سرویس ویندوزی کاملاً سالم باشد.

Get-ClusterResource | Where-Object {$_.ResourceType -eq "SQL Server"}
Get-ClusterGroup | Format-Table Name, OwnerNode, State

پس از تأمین این پیش‌نیازها، همان زنجیره داخلی Startup (master، Resource DB، model، msdb، tempdb، دیتابیس‌های کاربری، شبکه) دقیقاً همان مسیر Standalone را طی می‌کند تفاوت فقط در لایه بیرونی مدیریت منابع Cluster است.

سناریوی سازمانی زمان‌بندی Failover واقعی در یک بانک

یک بانک را در نظر بگیرید که یک Availability Group با دو Replica همگام (Synchronous) در دو Data Center مختلف دارد. در طول یک Patch امنیتی برنامه‌ریزی‌شده روی Node اصلی، Failover کنترل‌شده به Replica ثانویه انجام می‌شود. آنچه از دید کاربر نهایی چند ثانیه قطعی دیده می‌شود، شامل تأیید اعمال کامل تراکنش‌های Commit شده روی Secondary، تغییر نقش Replica به Primary، و اجرای Redo/Undo روی هر دیتابیس عضو AG است، پیش از پذیرش تراکنش‌های نوشتنی جدید.

تیم DBA این بانک، بر اساس تجربه واقعی، آموخته که مدت این Failover مستقیماً به حجم تراکنش‌های ناتمام لحظه Failover بستگی دارد به همین دلیل، پنجره Patch همیشه در ساعت کمترین بار تراکنشی برنامه‌ریزی می‌شود، نه صرفاً بر اساس ساعات اداری. این تصمیم مستقیماً از شناخت دقیق مراحل Redo و Undo نشئت می‌گیرد.

مقایسه زمان‌بندی Cold Start در برابر Failover در برابر Crash Recovery

سه سناریوی رایج Startup، از نظر مدت‌زمان و ریسک، تفاوت‌های عملی مهمی دارند:

سناریو	آغازکننده فرآیند	آیا tempdb از نو ساخته می‌شود	ریسک اصلی
Cold Start (پس از Shutdown تمیز)	SCM یا اپراتور	بله، همیشه	حداقل لاگ تراکنش تمیز است
Crash Recovery (پس از قطع برق)	SCM پس از Restart خودکار	بله، همیشه	Redo/Undo کامل، زمان‌بر برای تراکنش‌های حجیم ناتمام
Failover در Always On AG	Cluster Service / AG Listener	خیر (Replica از قبل بالا و همگام است)	وابسته به تأخیر Synchronization، نه به Startup کامل

نکته کلیدی این جدول این است که Failover در Always On معمولاً بسیار سریع‌تر از Cold Start است، چون Replica ثانویه از قبل بالا آمده و در وضعیت Recovering پیوسته است آنچه در Failover رخ می‌دهد صرفاً تغییر نقش است، نه اجرای کامل Startup از صفر.

ابزارهای DMV برای بازرسی وضعیت Startup و شبکه

پس از بالا آمدن سرور، چند Dynamic Management View کمک می‌کنند وضعیت واقعی سرویس، پروتکل‌های بارگذاری‌شده، و تنظیمات Startup Registry را بدون نیاز به باز کردن Configuration Manager بررسی کرد. برای دیدن وضعیت سرویس‌های مرتبط با این Instance، دقیقاً از دید SCM:

SELECT servicename, startup_type_desc, status_desc, last_startup_time
FROM sys.dm_server_services;

برای بررسی این‌که کدام ماژول‌ها (از جمله DLLهای پروتکل شبکه یا Driverهای مرتبط) در حافظه پروسه sqlservr.exe بارگذاری شده‌اند:

SELECT name, description
FROM sys.dm_os_loaded_modules;

و برای مشاهده همان پارامترهای Startup که از Registry خوانده شده‌اند، بدون نیاز به باز کردن Registry Editor:

SELECT registry_key, value_name, value_data
FROM sys.dm_server_registry;

این سه DMV، به‌ویژه در محیط‌هایی که چند نفر روی یک سرور دسترسی مدیریتی دارند و ممکن است تغییرات مستند نشده اعمال کرده باشند، ابزار سریعی برای بازسازی واقعیت پیکربندی فعلی سرور، مستقیماً از درون یک Query T-SQL، فراهم می‌کنند.

خواندن ERRORLOG خط به خط از تئوری تا نمونه واقعی

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

Starting up database 'master'.
Recovery is writing a checkpoint in database 'master'.
Starting up database 'mssqlsystemresource'.
Starting up database 'model'.
Starting up database 'msdb'.
Recovery is writing a checkpoint in database 'msdb'.
CHECKDB for database 'tempdb' finished without errors.
Starting up database 'tempdb'.
Recovery of database 'AdventureWorks' is 37% complete.
Recovery completed for database 'AdventureWorks'.
Server local connection provider is ready to accept connection on [ \\.\pipe\SQLLocal\MSSQLSERVER ].
Server is listening on [ 'any' <ipv4> 1433].
SQL Server is now ready for client connections.

خط اول و دوم نشان می‌دهند master در حال ریکاوری است و یک Checkpoint نوشته می‌شود (بخشی از فاز Redo). خط سوم تأیید می‌کند Resource Database بدون مشکل بارگذاری شده. خطوط بعدی، ترتیب دقیق model و msdb را نشان می‌دهند اگر مشکلی در msdb وجود داشته باشد، دقیقاً همین‌جا، پیش از خط مربوط به tempdb، خطا ثبت می‌شود. خط مربوط به «Recovery of database… X% complete» برای دیتابیس‌های کاربری بزرگ، پیشرفت واقعی Redo را نشان می‌دهد و می‌تواند چندین بار با درصدهای مختلف تکرار شود.

دو خط پایانی، دقیقاً لحظه‌ای را نشان می‌دهند که Endpointهای شبکه ثبت شده‌اند و سرور رسماً آماده Client Connection است تا پیش از دیدن این دو خط، هیچ تلاش اتصالی از سمت کاربر واقعی موفق نخواهد بود، حتی اگر تمام دیتابیس‌ها ONLINE باشند.

ترتیب واقعی Startup در SQL Server

جمع‌بندی همه مراحل توضیح‌داده‌شده، در قالب یک جدول مرجع سریع:

مرحله	توضیح
SCM	اجرای پروسه sqlservr.exe
Read Startup Parameters	خواندن -d -l -e از Registry
SQLOS	مقداردهی Scheduler و Memory Manager
master	بارگذاری و ریکاوری Metadata اصلی سرور
Resource Database	بارگذاری Objectهای سیستمی (Read-only)
model	آماده‌سازی الگوی ساخت دیتابیس و tempdb
msdb	ریکاوری Jobها، Backup History، Database Mail
tempdb	ساخت مجدد کامل بر پایه model
User Databases	ریکاوری موازی (Analysis/Redo/Undo)
Network Initialization	فعال‌سازی Shared Memory، TCP/IP، Named Pipes، DAC
Endpoints	ثبت TDS، DAC و Endpoint اختصاصی AG/Mirroring
Ready	پذیرش TDS Handshake و اولین Login

این جدول، همراه با نمودار کامل ابتدای مقاله، مرجعی است که می‌توان آن را کنار ERRORLOG یک سرور واقعی گذاشت و مرحله‌به‌مرحله تطبیق داد.

چک‌لیست عیب‌یابی سریع هنگام شکست Startup

وقتی سرویس بالا نمی‌آید یا دیتابیسی در RECOVERY_PENDING گیر می‌کند، مسیر مؤثر معمولاً این ترتیب را دنبال می‌کند: ابتدا بررسی اجرای واقعی پروسه sqlservr.exe سپس باز کردن آخرین ERRORLOG و جست‌وجوی خط مربوط به master، سپس Resource Database، سپس msdb.

اگر msdb با خطا مواجه شده، این دقیقاً همان دلیلی است که SQL Server Agent بالا نمی‌آید، حتی اگر همه دیتابیس‌های کاربری سالم باشند. اگر مشکل بعد از msdb است، مرحله بعد بررسی وضعیت هر دیتابیس کاربری از طریق sys.databases است. برای دیتابیس SUSPECT، بررسی سلامت فایل لاگ تراکنش اولویت اول است. در محیط‌های Cluster یا Always On، پیش از هرگونه بررسی داخل SQL Server، باید ابتدا وضعیت Cluster Resource و Quorum بررسی شود.

مستندسازی دقیق هر Trace Flag، هر Startup Stored Procedure، و هر تغییر دستی در مسیر فایل‌های سیستمی، پیش‌نیاز اجرای سریع همین چک‌لیست است.

پرسش‌های متداول FAQ

چرا Resource Database در SSMS دیده نمی‌شود؟
چون به‌طور پیش‌فرض مخفی است Objectهای آن از طریق اسکیمای sys در هر دیتابیس دیگر قابل مشاهده‌اند، بدون آنکه نام خود دیتابیس مستقیماً نمایش داده شود.

چرا Backupهای شبانه اجرا نشده‌اند در حالی که همه دیتابیس‌ها ONLINE هستند؟
رایج‌ترین دلیل، ناسالم بودن msdb است بدون ریکاوری کامل msdb، SQL Server Agent بالا نمی‌آید و هیچ Jobی اجرا نمی‌شود.

چرا تغییر اندازه دستی فایل‌های tempdb بعد از Restart از بین می‌رود؟
چون tempdb در هر Startup بر اساس model از نو ساخته می‌شود برای تغییر دائمی باید از ALTER DATABASE tempdb MODIFY FILE استفاده کرد.

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

آیا Failover در Always On همان فرآیند کامل Startup را تکرار می‌کند؟
خیر Replica ثانویه از قبل در حالت Recovering پیوسته قرار دارد و Failover صرفاً تغییر نقش است.

جمع‌بندی معماری چرا شناخت این فرآیند برای DBA حیاتی است

Startup Process در SQL Server یک زنجیره دقیق و قابل‌پیش‌بینی از رویدادهاست: از تصمیم Service Control Manager برای اجرای پروسه، تا مقداردهی SQLOS، بارگذاری master و Resource Database، ریکاوری model و msdb، بازسازی tempdb، آنلاین‌شدن موازی دیتابیس‌های کاربری، مقداردهی شبکه، ثبت Endpointها، و در نهایت فاز Login که اولین اتصال واقعی کاربر را ممکن می‌کند. هر مرحله از این زنجیره، نقطه شکست خاص خودش را دارد و علائم قابل‌تشخیص خودش را در ERRORLOG یا در DMVهایی مانند sys.databases، sys.dm_server_services و sys.dm_server_registry بر جای می‌گذارد.

هر خطی که هنگام Startup در ERRORLOG مشاهده می‌کنید، دقیقاً نشان می‌دهد موتور SQL Server در کدام مرحله قرار دارد. وقتی این مراحل را بشناسید، دیگر Startup برای شما یک جعبه سیاه نیست، بلکه زنجیره‌ای از رویدادهای قابل پیش‌بینی است که هر کدام نشانه‌ها و روش عیب‌یابی مشخص خود را دارند همین دقیق‌بودن در تشخیص، تفاوت میان یک قطعی چند دقیقه‌ای و یک بحران چند ساعته در محیط تولید است.

معماری SQL Server شما هنگام بحران واقعاً چه می‌کند؟

اگر هنگام Restart یا Crash فقط منتظر می‌مانید سرویس SQL Server دوباره Running شود، احتمال زیادی وجود دارد که مهم‌ترین بخش‌های فرآیند Startup را نبینید. بسیاری از مشکلاتی که باعث طولانی شدن Recovery، بالا نیامدن SQL Server Agent یا در دسترس نبودن دیتابیس‌ها می‌شوند، در همان دقایق ابتدایی Startup رخ می‌دهند، جایی که شناخت دقیق معماری داخلی موتور، تفاوت میان یک عیب‌یابی چند دقیقه‌ای و چند ساعت Downtime را رقم می‌زند.

تیم توسعه فناوری اطلاعات لاندا با تجربه در طراحی، عیب‌یابی و بهینه‌سازی زیرساخت‌های SQL Server، به سازمان‌ها کمک می‌کند مشکلات پیچیده Startup، Recovery، Always On، Failover Clustering، Performance و معماری پایگاه داده را به‌صورت ریشه‌ای تحلیل و برطرف کنند.

اگر با خطاهای Startup، زمان طولانی Recovery، مشکلات Availability Group یا چالش‌های عملکردی SQL Server مواجه هستید،

با کارشناسان لاندا در تماس ✆ باشید تا متناسب با زیرساخت سازمان شما، بهترین راهکار فنی ارائه شود.