رفع خطای 4064 در SQL Server

رفع خطای 4064 در SQL Server: راهنمای جامع اتصال به پایگاه داده

خطای 4064 در SQL Server یکی از پیام‌های خطایی است که مدیران پایگاه داده و توسعه‌دهندگان ممکن است با آن مواجه شوند، به خصوص زمانی که یک برنامه کاربردی یا کاربر سعی در اتصال به یک پایگاه داده خاص را دارد. این خطا به طور خاص با عبارت “Database specified in the connection string cannot be opened in current state” شناخته می‌شود و نشان می‌دهد که پایگاه داده‌ای که در رشته اتصال مشخص شده یا به عنوان پایگاه داده پیش‌فرض برای یک ورود (Login) تعیین شده است، در وضعیت فعلی خود قابل دسترسی نیست. درک صحیح این خطا و دلایل اصلی آن، کلید حل سریع و کارآمد آن است و از قطع شدن سرویس‌های وابسته به پایگاه داده جلوگیری می‌کند. این مشکل می‌تواند ناشی از چندین سناریوی متفاوت باشد که هر یک نیازمند بررسی و راهکار خاص خود هستند. تمرکز این مقاله بر روی ارائه یک راهنمای جامع برای شناسایی علت و ارائه راهکارهای عملی برای رفع خطای 4064 در SQL Server خواهد بود.

توضیحات کلی درباره خطای 4064 در SQL Server

خطای 4064 در SQL Server به وضوح اعلام می‌کند که دیتابیس مشخص شده در رشته اتصال یا دیتابیس پیش‌فرض کاربر، در حال حاضر قابل باز شدن نیست. این پیام خطا نشان‌دهنده یک مشکل اساسی در دسترسی به پایگاه داده است و نه یک خطای نحوی (syntax error) در کوئری SQL. این وضعیت می‌تواند زمانی رخ دهد که SQL Server نتواند به دلیل وضعیت خاصی که پایگاه داده در آن قرار دارد، به درخواست اتصال پاسخ دهد. این وضعیت‌های خاص می‌توانند شامل آفلاین بودن دیتابیس، در حال ریکاوری بودن آن پس از یک اتفاق غیرمنتظره، مشکوک بودن به خرابی (suspect state) یا حتی محدود شدن دسترسی به آن به دلیل عملیات نگهداری باشند. این خطا عموماً در زمان برقراری اتصال اولیه توسط یک کاربر یا برنامه رخ می‌دهد و از دسترسی به هرگونه اطلاعات در آن پایگاه داده جلوگیری می‌کند.

برای مثال، اگر یک برنامه کاربردی با یک رشته اتصال به دیتابیسی به نام “MyApplicationDB” وصل شود و این دیتابیس به هر دلیلی آفلاین باشد، خطای 4064 رخ خواهد داد. به همین ترتیب، اگر یک کاربر SQL Server (Login) دارای یک دیتابیس پیش‌فرض به نام “UserDefaultDB” باشد و این دیتابیس آسیب دیده و در وضعیت “RECOVERY PENDING” قرار گیرد، هر بار که آن کاربر تلاش کند به SQL Server متصل شود، این خطا را دریافت خواهد کرد. این خطا بر خلاف خطاهای مجوز (مانند خطای 18456 که به دلیل عدم دسترسی به دیتابیس رخ می‌دهد)، بیشتر به وضعیت داخلی دیتابیس مربوط می‌شود تا سطح دسترسی کاربر، هرچند که وضعیت‌هایی مانند `RESTRICTED_USER` می‌توانند این دو جنبه را به هم مرتبط کنند. درک این تفاوت‌ها برای عیب‌یابی صحیح خطای 4064 SQL Server حیاتی است.

علت‌های اصلی بروز خطای 4064 و سناریوهای رایج

خطای 4064 در SQL Server معمولاً به دلیل چندین علت اصلی مرتبط با وضعیت و قابلیت دسترسی پایگاه داده رخ می‌دهد. درک این علت‌ها برای رفع موثر مشکل حیاتی است:

1. پایگاه داده پیش‌فرض ناموجود یا غیرقابل دسترس

یکی از رایج‌ترین سناریوها زمانی است که دیتابیس پیش‌فرض تعیین شده برای یک ورود (SQL Login) به SQL Server، حذف شده باشد، آفلاین باشد، در وضعیت “RECOVERY PENDING” (در انتظار ریکاوری) یا “SUSPECT” (مشکوک به خرابی) قرار گرفته باشد. در این حالت، هر زمان که کاربر با آن Login سعی در اتصال کند، SQL Server نمی‌تواند دیتابیس پیش‌فرض او را بارگذاری کند و خطای 4064 را برمی‌گرداند. این وضعیت ممکن است پس از حذف تصادفی یک دیتابیس، یا زمانی که یک دیتابیس به طور موقت برای نگهداری آفلاین شده است، رخ دهد.

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

اگر برنامه یا کاربر، نام دیتابیس را مستقیماً در رشته اتصال (Connection String) خود مشخص کرده باشد و آن دیتابیس به دلایلی مانند موارد زیر، در وضعیت مناسبی نباشد، این خطا رخ می‌دهد:

• OFFLINE:

  پایگاه داده به صورت دستی یا به دلیل یک مشکل سیستم آفلاین شده است.

• RECOVERY PENDING:

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

• SUSPECT:

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

• EMERGENCY:

  پایگاه داده به صورت دستی توسط مدیر به حالت اضطراری (read-only, single-user) برای عیب‌یابی یا ترمیم برده شده است.

• RESTRICTED_USER:

  پایگاه داده برای انجام عملیات نگهداری به حالت Restricted User تغییر کرده و فقط اعضای نقش‌های sysadmin، dbcreator یا db_owner می‌توانند به آن متصل شوند. اگر کاربر متصل شونده عضو این نقش‌ها نباشد، خطای 4064 دریافت می‌کند.

• SINGLE_USER:

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

3. مشکلات فایل‌های پایگاه داده

آسیب‌دیدگی یا گم شدن فایل‌های MDF (فایل داده) یا LDF (فایل لاگ) دیتابیس می‌تواند باعث شود که SQL Server نتواند دیتابیس را به درستی بارگذاری کند و آن را در وضعیت‌هایی مانند `SUSPECT` یا `RECOVERY PENDING` قرار دهد که منجر به خطای 4064 می‌شود. این آسیب‌دیدگی می‌تواند ناشی از مشکلات سخت‌افزاری، قطعی برق، یا نقص نرم‌افزاری باشد.

4. نام صحیح نبودن پایگاه داده در رشته اتصال

گاهی اوقات، دلیل به سادگی یک اشتباه تایپی در نام دیتابیس در رشته اتصال است. در این صورت، SQL Server نمی‌تواند دیتابیس مورد نظر را پیدا کند و ممکن است خطای 4064 را برگرداند، هرچند که گاهی اوقات خطاهای دیگری مانند “Cannot open database requested by the login” نیز ممکن است رخ دهد.

شناسایی دقیق وضعیت پایگاه داده با استفاده از ابزارهای SQL Server Management Studio (SSMS) و کوئری‌های سیستم، گام اول در رفع این خطا است.

راهکارهای عملی برای رفع خطای 4064 در SQL Server

برای رفع خطای 4064 در SQL Server، باید به صورت مرحله‌ای پیش رفت و وضعیت‌های مختلف پایگاه داده را بررسی و در صورت لزوم اصلاح کرد. در ادامه، راهکارهای عملی و گام به گام ارائه می‌شود:

گام 1: بررسی و تغییر پایگاه داده پیش‌فرض برای Login

اگر خطا مربوط به ورود یک کاربر (Login) خاص است، ابتدا باید دیتابیس پیش‌فرض آن Login را بررسی کنید. اگر دیتابیس پیش‌فرض در دسترس نباشد، می‌توانید آن را به یک دیتابیس همیشه در دسترس مانند `master` تغییر دهید. این کار به کاربر اجازه می‌دهد حداقل به SQL Server متصل شود و سپس بتواند دیتابیس‌های دیگر را بررسی کند.

برای مشاهده دیتابیس پیش‌فرض یک Login:

می‌توانید از SQL Server Management Studio (SSMS) استفاده کرده و به مسیر Security > Logins بروید، روی Login مورد نظر کلیک راست کرده و Properties را انتخاب کنید. در بخش General، Default database را مشاهده خواهید کرد. همچنین می‌توانید از کوئری SQL زیر استفاده کنید:

SELECT name, default_database_name
FROM sys.server_principals
WHERE type = 'S' AND name = 'YourLoginName';

برای تغییر دیتابیس پیش‌فرض به `master` (به عنوان یک راه حل موقت):

ALTER LOGIN [YourLoginName] WITH DEFAULT_DATABASE = [master];
GO

به جای `YourLoginName`، نام Login مربوطه را وارد کنید.

گام 2: بررسی وضعیت پایگاه داده مورد نظر

مهم‌ترین گام، شناسایی وضعیت فعلی پایگاه داده‌ای است که مشکل دارد. می‌توانید از کوئری زیر برای مشاهده وضعیت دیتابیس‌ها استفاده کنید:

SELECT name, state_desc, user_access_desc
FROM sys.databases
WHERE name = 'YourDatabaseName';
GO

به جای `YourDatabaseName`، نام دیتابیس مورد نظر را وارد کنید. `state_desc` وضعیت فعلی دیتابیس (مانند ONLINE, OFFLINE, RECOVERY PENDING, SUSPECT, EMERGENCY) و `user_access_desc` سطح دسترسی کاربران (MULTI_USER, SINGLE_USER, RESTRICTED_USER) را نشان می‌دهد.

گام 3: آنلاین کردن پایگاه داده یا رفع مشکل آن

بسته به `state_desc` که در گام 2 پیدا کردید، راهکار متفاوتی را باید اتخاذ کنید:

الف) اگر وضعیت `OFFLINE` بود:

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

ALTER DATABASE YourDatabaseName SET ONLINE;
GO

پس از اجرای این دستور، وضعیت دیتابیس را مجدداً با کوئری `sys.databases` بررسی کنید.

ب) اگر وضعیت `RECOVERY PENDING` یا `SUSPECT` بود:

این وضعیت‌ها نشان‌دهنده آسیب‌دیدگی یا عدم تکمیل فرآیند ریکاوری پایگاه داده هستند. ابتدا سعی کنید دیتابیس را به حالت اضطراری (EMERGENCY) ببرید تا بتوانید آن را بررسی کنید:

ALTER DATABASE YourDatabaseName SET EMERGENCY;
GO

پس از آن، دیتابیس در حالت فقط خواندنی (read-only) و تک کاربره قرار می‌گیرد و می‌توانید `DBCC CHECKDB` را برای بررسی یکپارچگی آن اجرا کنید. این فرمان، اطلاعاتی در مورد خطاهای موجود در دیتابیس ارائه می‌دهد:

DBCC CHECKDB (YourDatabaseName) WITH NO_INFOMSGS;
GO

اگر `DBCC CHECKDB` خطا گزارش داد و فایل لاگ ترانزکشن آسیب دیده باشد، ممکن است نیاز به بازسازی فایل لاگ داشته باشید. در این حالت، دیتابیس را به حالت `SINGLE_USER` ببرید و سپس `DBCC CHECKDB` را با گزینه `REPAIR_ALLOW_DATA_LOSS` اجرا کنید. **این گزینه ممکن است منجر به از دست رفتن داده‌ها شود و باید فقط در صورت عدم وجود بک‌آپ معتبر و به عنوان آخرین راه حل استفاده شود.**

ALTER DATABASE YourDatabaseName SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
GO
DBCC CHECKDB (YourDatabaseName, REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS;
GO
ALTER DATABASE YourDatabaseName SET MULTI_USER;
GO

بهترین و امن‌ترین راه حل برای دیتابیس‌های در حالت `SUSPECT` یا `RECOVERY PENDING`، بازگرداندن (Restore) از آخرین بک‌آپ معتبر است. اگر بک‌آپ دارید، می‌توانید از دستور زیر استفاده کنید:

RESTORE DATABASE YourDatabaseName
FROM DISK = 'C:\Backup\YourDatabaseName.bak'
WITH REPLACE, RECOVERY;
GO

مسیر فایل بک‌آپ (`C:\Backup\YourDatabaseName.bak`) را با مسیر صحیح جایگزین کنید.

ج) اگر وضعیت `EMERGENCY` بود:

اگر دیتابیس قبلاً به حالت `EMERGENCY` منتقل شده بود و اکنون نیاز به بازگرداندن آن به حالت عادی دارید، پس از انجام `DBCC CHECKDB` و رفع مشکلات احتمالی، می‌توانید آن را به حالت چندکاربره (MULTI_USER) ببرید:

ALTER DATABASE YourDatabaseName SET MULTI_USER;
GO

د) اگر `user_access_desc` به صورت `RESTRICTED_USER` یا `SINGLE_USER` بود:

این حالت‌ها معمولاً برای نگهداری دیتابیس استفاده می‌شوند. برای برگرداندن دیتابیس به حالت عادی که چندین کاربر بتوانند به آن دسترسی داشته باشند، از دستور زیر استفاده کنید:

ALTER DATABASE YourDatabaseName SET MULTI_USER;
GO

گام 4: بررسی رشته اتصال (Connection String)

مطمئن شوید که نام دیتابیس در رشته اتصال برنامه یا اسکریپت شما کاملاً صحیح و بدون غلط املایی است. یک اشتباه کوچک در نام دیتابیس می‌تواند منجر به خطای 4064 شود، زیرا SQL Server نمی‌تواند دیتابیس مورد نظر را پیدا کند.

گام 5: بررسی مجوزهای کاربر (در صورت لزوم)

اگرچه خطای 4064 بیشتر به وضعیت دیتابیس مربوط است تا مجوزها، اما در برخی سناریوها مانند `RESTRICTED_USER` یا اگر کاربر دسترسی `CONNECT` به SQL Server یا دیتابیس را نداشته باشد، می‌تواند غیرمستقیم مرتبط باشد. اطمینان حاصل کنید که Login مورد نظر مجوزهای لازم برای اتصال به SQL Server و دسترسی به دیتابیس را دارد.

با پیگیری دقیق این مراحل و بررسی وضعیت‌های مختلف دیتابیس، می‌توانید به طور موثر خطای 4064 در SQL Server را شناسایی و رفع کنید و اطمینان حاصل کنید که برنامه‌ها و کاربران شما می‌توانند بدون مشکل به پایگاه داده متصل شوند.

“`