SQL Server: 데이터베이스가 "복원 중" 상태로 고착됨
데이터베이스를 백업했습니다.
BACKUP DATABASE MyDatabase
TO DISK = 'MyDatabase.bak'
WITH INIT --overwrite existing
그리고 복원을 시도했습니다.
RESTORE DATABASE MyDatabase
FROM DISK = 'MyDatabase.bak'
WITH REPLACE --force restore over specified database
이제 데이터베이스가 복원 상태에 있습니다.
일부에서는 백업에 로그 파일이 없었기 때문에 다음과 같은 방법으로 롤포워드가 필요했기 때문이라고 추측하고 있습니다.
RESTORE DATABASE MyDatabase
WITH RECOVERY
물론 실패는 예외입니다.
Msg 4333, Level 16, State 1, Line 1
The database cannot be recovered because the log was not restored.
Msg 3013, Level 16, State 1, Line 1
RESTORE DATABASE is terminating abnormally.
그리고 재해가 발생했을 때 필요한 것은 제대로 작동하지 않는 복원입니다.
백업에는 데이터 파일과 로그 파일이 모두 포함됩니다.
RESTORE FILELISTONLY
FROM DISK = 'MyDatabase.bak'
Logical Name PhysicalName
============= ===============
MyDatabase C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MyDatabase.mdf
MyDatabase_log C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MyDatabase_log.LDF
Symantec Backup Exec 11d를 사용하여 데이터베이스를 SQL Server 2005 Standard Edition 인스턴스로 복원하는 경우가 있었습니다.복원 작업이 완료된 후 데이터베이스는 "복원 중" 상태로 유지되었습니다.디스크 용량 문제는 없었습니다.데이터베이스가 단순히 「복원중」상태에서 벗어나지 않았습니다.
SQL Server 인스턴스에 대해 다음 쿼리를 실행했더니 데이터베이스를 즉시 사용할 수 있게 되었습니다.
RESTORE DATABASE <database name> WITH RECOVERY
하다를 요.WITH RECOVERY의 「」를 사용)RESTORE명령: 복원 프로세스의 일부로 데이터베이스를 온라인으로 전환합니다.
이는 물론 트랜잭션 로그 백업을 복원하지 않을 경우(즉, 데이터베이스 백업만 복원한 후 데이터베이스에 액세스할 수 있는 경우)에만 해당됩니다.
명령어는 다음과 같습니다.
RESTORE DATABASE MyDatabase
FROM DISK = 'MyDatabase.bak'
WITH REPLACE,RECOVERY
SQL Server Management Studio에서 데이터베이스 복원 마법사를 사용하여 더 많은 작업을 수행할 수 있습니다.이렇게 하면 특정 파일 위치, 덮어쓰기 옵션 및 WITH 복구 옵션을 선택할 수 있습니다.
방법은 다음과 같습니다.
- 서비스를 정지합니다(MSSQLSERVER).
- 데이터베이스 및 로그 파일 이름 변경 또는 삭제 (C:\Program Files\Microsoft SQL Server\)MS SQL.1\MSSQL\Data...) 또는 파일이 있는 곳
- 서비스를 시작합니다(MSSQLSERVER).
- 문제가 있는 데이터베이스를 삭제합니다.
- 데이터베이스를 다시 복원합니다.
로그의 secondary 서버의 송신을 정지하는 것과 같은 일이 있었습니다.로그 전달에서 서버를 삭제하는 명령어와 프라이머리 서버로부터의 로그 전달을 정지한 후 세컨더리 서버상의 데이터베이스가 명령어 실행 후에 restore status에 갇혔습니다.
RESTORE DATABASE <database name> WITH RECOVERY
데이터베이스 메시지:
RESTORE DATABASE가 18.530초(0.000MB/초) 동안 0페이지를 성공적으로 처리했습니다.
데이터베이스는 18초 후에 다시 사용할 수 있게 되었습니다.
SQL Management Studio를 사용한 복원에서도 비슷한 문제가 있었습니다.데이터베이스의 백업을 다른 이름의 새 백업으로 복원하려고 했습니다.처음에는 이 작업이 실패하여 새 데이터베이스의 파일 이름을 수정한 후 정상적으로 수행되었습니다.어쨌든 제가 설명한 문제는 처음부터 올바르게 처리되어도 재발했습니다.따라서 복원 후에도 원래 데이터베이스는 이름 옆에 (Restore...)로 남아 있었습니다.위의 (Bhusan's) 포럼의 답변을 고려하여 다음 측면에 있는 쿼리 에디터로 실행해 보았습니다.
RESTORE DATABASE "[NAME_OF_DATABASE_STUCK_IN_RESTORING_STATE]"
문제를 해결했습니다.데이터베이스 이름에 특수 문자가 포함되어 있어 처음에는 문제가 있었습니다.이 문제를 해결하려면 큰따옴표를 붙여야 합니다.작은따옴표를 붙이면 "Incorrect synthics near..." 오류가 발생합니다.
이것은 이 문제를 해결하기 위해 시도했던 최소한의 해결책(데이터베이스가 복원 상태로 고착됨)이며, 더 많은 경우에 적용할 수 있기를 바랍니다.
네, 비슷한 문제가 있습니다.Pauk의 경우와 마찬가지로 복원 중 서버의 디스크 용량이 부족하여 영구 복원 상태가 되었습니다.SQL Server 서비스를 중지하지 않고 이 상태를 종료하려면 어떻게 해야 합니까?
해결책을 찾았습니다:)
Drop database *dbname*
WITH RECOVERY 옵션은 RESTORE DATABASE/RESTORE LOG 명령이 실행될 때 기본적으로 사용됩니다."복원" 프로세스에서 벗어나지 못할 경우 다음을 수행하여 데이터베이스를 온라인 상태로 되돌릴 수 있습니다.
RESTORE DATABASE YourDB WITH RECOVERY
GO
여러 파일을 복원해야 하는 경우 CLI 명령에서는 각각 WITH NORECOVERY와 WITH RECOVERY가 필요합니다.데이터베이스를 온라인으로 되돌리려면 명령의 마지막 파일만 WITH RECOVERY가 필요합니다.
RESTORE DATABASE YourDB FROM DISK = 'Z:\YourDB.bak'
WITH NORECOVERY
GO
RESTORE LOG YourDB FROM DISK = 'Z:\YourDB.trn'
WITH RECOVERY
GO
SQL Server Management Studio 마법사를 사용할 수도 있습니다.
가상 복원 프로세스도 있지만 서드파티 솔루션을 사용해야 합니다.일반적으로 데이터베이스 백업을 라이브 온라인 데이터베이스로 사용할 수 있습니다.ApexSQL과 Idera는 자체 솔루션을 가지고 있습니다.SQL Hammer가 ApexSQL Restore에 대해 검토합니다.가상 복원은 대량의 백업을 처리하는 경우에 적합한 솔루션입니다.복원 프로세스가 훨씬 빠르고 디스크 드라이브의 공간도 크게 절약할 수 있습니다.비교를 위해 인포그래픽을 보실 수 있습니다.
이건 분명하지만, 방금 내 발을 헛디뎠다만,
테일 로그 백업을 수행하는 경우 SSMS 복원 마법사에서 "소스 데이터베이스를 복원 상태로 유지(WITH NORECOVERCovery)" 옵션을 선택한 경우에도 이 문제가 발생할 수 있습니다.
오른쪽 클릭 데이터베이스를 클릭하여 태스크 --> 복원 --> 트랜잭션로그로 이동합니다.트랜잭션파일에 체크 마크가 붙어 있는 경우는 SQL Server가 이 파일에서 복원을 시도하고 있습니다.파일 선택을 취소하고 확인을 클릭합니다.데이터베이스가 복구되었습니다.....
이 문제가 해결됐으니 누군가 도움이 되길 바랍니다.
나는 이유를 알아냈다.
「 」를 발행한 RESTORE DATABASE명령어가 복원 중에 연결이 끊겨 복원이 중단됩니다.
클라이언트의 접속을 통해 데이터베이스를 복원하라는 지시를 받은 서버가 클라이언트가 계속 연결되어 있지 않으면 복원을 완료하지 않는 것은 이상합니다.
이게 먹혔어느꼈어요.
데이터베이스에 복원 상태가 표시되어 쿼리를 실행할 수 없고 소프트웨어에 연결할 수 없는 상황이 발생했습니다.
이 상황에서 벗어나기 위해 제가 한 일은 다음과 같습니다.
윈도우즈 서비스에서 모든 SQL 관련 서비스를 중지합니다.
SQL 디렉토리에 Ldf 및 Mdf 파일이 있는 DATA 폴더를 열었습니다.보통은 "C:\Program Files*********\MSSQL\DATA"와 같습니다.
다음으로 데이터베이스의 Ldf 파일과 Mdf 파일을 모두 복사했습니다.[ db name . mdf ] [ [ db name ]_log . ldf
나는 이 두 파일을 다른 폴더에 복사했다.
그런 다음 모든 SQL 관련 서비스를 Windows 서비스에서 다시 시작했습니다(1단계).
MS SQL Management Studio를 일반 로그인으로 시작했습니다.
crinter 데이터베이스를 마우스 오른쪽 버튼으로 클릭하고 DELETE(데이터베이스 삭제)를 누릅니다.
이 데이터베이스와 관련된 모든 LDF 및 MDF 파일이 DATA 폴더에서 삭제되었습니다(2단계 참조).
동일한 이름으로 새 데이터베이스를 작성했습니다(6단계에서 삭제한 데이터베이스와 동일한 이름 - 범죄 데이터베이스).
그런 다음 [데이터베이스 이름]-> 오른쪽 클릭 -> 태스크 -> 오프라인으로 전환합니다.
그런 다음 (3단계부터) 두 파일을 모두 DATA 폴더에 다시 복사했습니다(2단계).
[데이터베이스명] -> 오른쪽 클릭 -> 태스크 -> 온라인 상태로 전환합니다.
데이터베이스 이름에 .가 있는데, 그 때문에 쿼리가 작동하지 않았습니다(' 근처에 잘못된 구문이 표시됨). 그 후 이름에 괄호가 필요하다는 것을 깨달았습니다.
RESTORE DATABASE [My.DB.Name] WITH RECOVERY
제 경우, "복구 중" 상태로 걸려 있던 데이터베이스를 폐기하는 것으로 충분했습니다."를 SQL 명령어로 설정합니다.
drop database <dbname>
쿼리 창에 표시됩니다.
그런 다음 Databases를 오른쪽 클릭하여 Refresh를 선택하면 SQL Server Management Studio(SSMS)의 엔트리가 삭제됩니다.그 후 새로운 restore를 실시하면 정상적으로 동작합니다.
(오프라인으로 전환하지 않고 SQL 서비스를 재시작하지 않으며 서버 재부팅도 작동하지 않습니다).
이 문제를 해결하려면 다음 명령을 사용합니다.
RESTORE DATABASE [DatabaseName] WITH RECOVERY
이벤트 로그에 TCP 에러가 발생했을 때도, 이 문제가 있었습니다.
sql이 있는 DB를 삭제하거나 관리자 "delete"에서 마우스 오른쪽 단추를 누른 후 다시 복원합니다.
저는 사실 이것을 디폴트로 시작했습니다.DB 드롭을 스크립팅하고 다시 작성한 후 복원합니다.
모든 「」는RESTORE DATABASE 부속되어 있다RECOVERY세우다.'NORECOVERY' 옵션은 기본적으로 데이터베이스가 더 많은 복원 파일을 기다리고 있음을 SQL Server에 알립니다(DIF 파일 및 LOG 파일일 수 있으며 가능하면 테일 로그 백업 파일을 포함할 수도 있습니다).'복구' 옵션을 선택하면 모든 트랜잭션이 완료되고 데이터베이스가 트랜잭션을 수행할 준비가 됩니다.
그래서:
- 데이터베이스에 SIMPLE 복구 모델이 설정되어 있는 경우 전체 복원만 수행할 수 있습니다.
NORECOVERY옵션(DIF 백업이 있는 경우)을 클릭합니다.SIMPLE 복구 모델 데이터베이스에는 LOG 백업이 허용되지 않습니다. - 그렇지 않으면 데이터베이스가 FULL 또는 BULLK-LOGGED 복구 모델로 설정된 경우 FULL 복원 후
NORECOVERY옵션을 선택한 후 DIFF를 실행하고 나서NORECOVERY마지막으로 를 사용하여 LOG 복원을 수행합니다.RECOVERY★★★★★★ 。
마지막 복원 쿼리에는 옵션이 있어야 합니다.그것은 명백한 방법일 수도 있고 아닐 수도 있다.T-SQL의 경우 상황은 다음과 같습니다.
1.
USE [master]
GO
RESTORE DATABASE Database_name
FROM DISK = N'\\path_of_backup_file.bak WITH FILE = 1, [REPLACE],NOUNLOAD,
RECOVERY -- This option could be omitted.
GO
WITH REPLACE 옵션은 데이터 손실로 이어질 수 있으므로 주의하여 사용해야 합니다.
또는 FULL 백업과 DIFF 백업을 수행하는 경우 이 옵션을 사용할 수 있습니다.
USE [master]
GO
RESTORE DATABASE Database_name
FROM DISK = N'\\path_of_backup_file.bak' WITH FILE = 1,
NOUNLOAD,NORECOVERY
GO
RESTORE DATABASE Database_name
FROM DISK =N'\\path_of_**diff**backup_file.bak' WITH FILE = 1,
NOUNLOAD, RECOVERY
GO
2. USE [master]
GO
-- Perform a Tail-Log backup, if possible.
BACKUP LOG Database_name
GO
-- Restoring a FULL backup
RESTORE DATABASE Database_name
FROM DISK = N'\\path_of_backup_file.bak' WITH FILE = 1,
NOUNLOAD,NORECOVERY
GO
-- Restore the last DIFF backup
RESTORE DATABASE Database_name
FROM DISK = N'\\path_of_DIFF_backup_file.bak' WITH FILE = 1,
NORECOVERY,NOUNLOAD
GO
-- Restore a Log backup
RESTORE LOG Database_name
FROM DISK = N'path_of_LOG_backup_file.trn' WITH FILE = 2,
RECOVERY, NOUNLOAD
GO
물론 SQL Server에 10%가 완료될 때마다 보고하도록 지시하는 STATS = 10 옵션을 사용하여 복원을 수행할 수 있습니다.
원하는 경우 실시간 기반 조회에서 프로세스를 관찰하거나 복원할 수 있습니다.다음과 같습니다.
USE[master]
GO
SELECT session_id AS SPID, command, a.text AS Query, start_time, percent_complete, dateadd(second,estimated_completion_time/1000, getdate()) as estimated_completion_time
FROM sys.dm_exec_requests r CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) a
WHERE r.command in ('BACKUP DATABASE','RESTORE DATABASE')
GO
이게 도움이 됐으면 좋겠다.
스냅숏이 유효하게 되어 있는 경우, 스택 된 데이터베이스를 삭제할 수도 있습니다.저는 이 방법이 효과가 있었습니다.
- 처음에 Tipu Delacablu 스텝을 따랐습니다(투고를 몇 개 읽어주세요).
- run 명령: 데이터베이스 [데이터베이스]를 드롭합니다.이것에 의해, 스냅샷 데이터베이스의 이름을 나타내는 에러가 표시됩니다.
- run command: drop database [drop database]를 선택하고 스텝2에서 명령어를 다시 실행합니다.
VERIFY ONLY를 실행해 본 적이 있습니까?제대로 된 백업인지 확인하려고요
http://msdn.microsoft.com/en-us/library/ms188902.aspx
SQL Express 라이센스 제한 때문에 MyDbName(복원 중...) 케이스를 받았습니다.
로그 파일에서 다음을 찾았습니다.
결과 누적 데이터베이스 크기가 데이터베이스당 라이센스 제한인 10240MB를 초과하므로 데이터베이스 생성 또는 ALTER DATABASE에 실패했습니다.
따라서 더 큰 데이터베이스를 복원하려면 SQL Express 서버를 Developer 에디션으로 전환해야 합니다.
제가 그걸 고친 건
- 중지, 인스턴스 정지
- 데이터 폴더에 .mdf 및 .ldf 파일의 백업 생성
- 인스턴스를 재시작합니다.
- 데이터베이스 삭제 - 고정된 복원
- .mdf 및 .ldf 파일을 데이터 폴더에 되돌립니다.
- 인스턴스를 .mdf 및 .ldf 파일에 첨부합니다.
SQL Server Management Studio를 사용하여 데이터베이스를 복원하는 동안 동일한 문제가 발생하여 복원 모드가 되었습니다.몇 시간 동안 문제를 추적한 결과, 다음과 같은 문의가 성공했습니다.다음 쿼리는 데이터베이스를 기존 백업에서 이전 상태로 복원합니다..mdf와 .log 파일을 같은 디렉토리에 두는 것이 포인트라고 생각합니다.
RESTORE DATABASE aqua_lc_availability
FROM DISK = 'path to .bak file'
WITH RECOVERY
를 오른쪽 .Task-->Restore-->Database-->Ok모든 게 잘 풀렸어요
- 먼저 SQL Agent Service를 확인하고 실행합니다.
다음 T-SQL 사용:
from master.sys.sysaltfiles 여기서 dbid = DB_ID('db_name')를 선택합니다.
T-SQL을 계속 사용하는 경우:
DISK = 'DB_path'에서 데이터베이스를 복원하고 다시 시작하고 교체합니다.
도움이 되었으면 좋겠다!
모든 WITH RECOVERY 기반 옵션이 제대로 작동하지 않았습니다.
Management Studio에서 완전한 복원을 수행했습니다.
USE [master]
RESTORE DATABASE Sales_SSD
FROM DISK = N'D:\databaseBackups02\Daily_Sales_20150309_0941.bak'
WITH FILE = 1,
MOVE N'Sales_Data' TO N'C:\Data\SSD\Sales.mdf',
MOVE N'Sales_Log' TO N'C:\Data\SSD\Sales_1.ldf',
NOUNLOAD, REPLACE, STATS = 5
저도 같은 문제가 있었는데...드라이브가 가득 차지 않아 데이터베이스에 이 문제가 발생한 이유는 알 수 없지만...마치 타락한 것 같아위의 모든 것을 시도해 보았습니다만, 특히 서비스를 중지하고 mdf와 ldf 파일을 삭제하는 것이 좋다고 생각했습니다.복구하는 동안 계속 멈춰있었어요?
이 문제를 해결하려면 앞서 설명한 파일을 삭제해야 합니다.그러나 다시 DB를 복원하는 대신 Front End Attachment 마법사를 사용하여 새로운 .mdf 및 .ldf 파일을 복사하고 첨부했습니다.다행이다, 됐다!!
가상 머신을 사용하고 있기 때문에 새 파일을 복사하는 데 FOREVER가 걸렸습니다.클립보드를 사용한 복사 및 붙여넣기 작업은 1시간 정도 소요되므로 마지막 시도만 권장합니다.
RESTORE DATABASE {DatabaseName}
FROM DISK = '{databasename}.bak'
WITH REPLACE, RECOVERY
백업 파일에서 SQL 서버 데이터베이스를 복원하려는 경우 다음 스크립트를 사용할 수 있습니다.
RESTORE DATABASE [MyDatabase] -- which database to restore
FROM DISK = N'X:\MyDatabase.bak' -- location of the database backup
WITH
FILE = 1, -- restore from a backup file
-- declare where the file groups should be located (can be more than two)
MOVE N'MyDatabase_Data' TO N'D:\SSDPATH\MyDatabase.mdf',
MOVE N'MyDatabase_Log' TO N'E:\HDDPATH\MyDatabase.ldf',
-- Tape option; only relevant if you backup from magnetic tape
NOUNLOAD,
-- brings the database online after the database got restored
-- use this option when you don't want to restore incremental backups
-- use NORECOVERY when you want to restore differential and incremental backup files
RECOVERY,
-- replace existing database with the backup
-- deletes the existing database
REPLACE,
-- print log message for every 1 percent of restore
STATS = 1;
이것은 SQL Server에서 항상 나오는 오래된 문제이며, 최신 2019 버전도 마찬가지입니다.Microsoft가 이 문제를 오랫동안 방치하고 MSSQL 엔진이 계속 이렇게 작동하도록 방치한 이유를 알 수 없습니다.그럼에도 불구하고 Restore Database With RECOVERY 옵션을 시도했지만 여전히 작동하지 않았던 사용자에게는 다른 가능한 솔루션을 제안합니다.
서버 자체에 로그인하여 실제 데이터베이스 서버에서 기본 SSMS 프로그램을 실행합니다.다음으로 "복구" 데이터베이스로 이동하여 삭제합니다.됐다. 문제가 없어졌어.보관해야 할 경우 MDF 파일을 복사하고 이름을 변경하여 새 데이터베이스로 첨부합니다.SQL Server 2008 R2에서 근무했습니다.
이 문제는 오늘 VM SQL 서버에서 발생했습니다.1.8의 복원을 시도했습니다.GB 데이터베이스에서는 0%로 고정되어 있습니다.ASYNC_IO_COMPLETION.
여러 번 시도했지만.bak400MB 미만의 다른 관련되지 않은 데이터베이스를 복원하려고 해도 같은 드라이브에 파일을 저장할 수 있습니다.
이 실타래로 모든 걸 다 해봤지만, 아무 소용이 없었어요.
그 후 DBA의 ASynC_IO_COMPLETION에 Restore가 스택되어 있는 것을 알게 되었습니다.그 답변은 효과가 있었습니다.
Instant File Initialization을 실행하고 SQL Server를 재시작한 다음 복원을 다시 시도하십시오.SSMS GUI에서는 다음과 같이 거의 즉시 진행률이 표시되었습니다.
Select percent_complete,* From sys.dm_exec_requests
VM의 배후에 있는 스토리지가 매우 느리거나 장애가 있는 것 같습니다.
언급URL : https://stackoverflow.com/questions/520967/sql-server-database-stuck-in-restoring-state
'programing' 카테고리의 다른 글
| SQL을 Stored Procs와 Code로 유지하는 장단점은 무엇입니까? (0) | 2023.04.07 |
|---|---|
| SQL Server 소수점 두 자리 숫자 쓰기 (0) | 2023.04.07 |
| SNIReadSyncOverAsync 및 WaitForSingleObject가 EF 성능을 차단합니까? (0) | 2023.04.07 |
| SSMS에서 ntext 또는 nvarchar(최대)의 모든 텍스트를 어떻게 표시합니까? (0) | 2023.04.07 |
| SQL Server에서 여러 열을 동시에 변경하는 방법 (0) | 2023.04.07 |