대략 증상은 디스크는 멀쩡한듯 하나 OS에서 위와 같은 오류 메시지가 나타남.

Data MDF 파일을 찾지 못한다는 이야기와 함께. 

해결 방법은 일단 서비스 내리고 Reboot 

뭐 Reboot으로 해결한게 이번이 2번째인데 이 녀석이 만약 서비스에 중요한 영향을 미치는 녀석이었다면 큰 일이 생겼을듯...

Storage 부분 버그로 2번 유사 장애 + 2008로 업글 못하고 2005로 눌러 앉았음.. 

아래는 MSDN 에서 찾은 유사 에러 이런 유사 에러가 많이 발생하는 관계로 MS에서 Driver Update 를 권장하는 듯... 

------------------------------------------ 예 1 ------------------------------------------------------------------------------------------

출처 : http://social.msdn.microsoft.com/Forums/en-US/sqldatabaseengine/thread/b690c6be-795e-43e6-9716-1ab40a780c4a

Q :

We are using sql server 2005 Enterprise Edition with service pack1

 

I got the following error messages in the SQL log

 

1. The operating system returned error 21(The device is not ready.) to SQL Server during a read at offset 0x00000000090000 in file '....mdf'. Additional messages in the SQL Server error log and system event log may provide more detail. This is a severe system-level error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.
2. fcb::close-flush: Operating system error 21(The device is not ready.) encountered.

I got these errors for about 2 hrs and after that I see these messages in the sql log

 

• Starting up database ' '
• 1 transactions rolled forward in database ''  (). This is an informational message only. No user action is required.
• 0 transactions rolled back in database ' ' (). This is an informational message only. No user action is required.
• Recovery is writing a checkpoint in database  ' ' ( ). This is an informational message only. No user action is required.
• CHECKDB for database  '' finished without errors on   (local time). This is an informational message only; no user action is required.
  
  

Can anyone please help me in troubleshooting this issue. Why this migh have happened.

A : 

This sounds like an IO subsystem issue, i.e. SQL Server is having difficulty talking to one of your drives. Are you using direct attached storage or a SAN?

Q : 

 We have Netapp SCSI disk storage. Could you please tell me how do I troubleshoot this so that I wont get such errors in future.

Netapp 스토리지를 사용중임. 대략 스토리지 부분에서 오류일 가능성 있슴.

------------------------------------------ 예 2 ------------------------------------------------------------------------------------------

출처 : http://social.msdn.microsoft.com/Forums/en-US/sqldatabaseengine/thread/27ef2342-d8d0-42f0-807a-41a15dd1856f

Q :

Dear DBAs,

A database backup job has failed for the last couple of days with below error. I see that there is no P drive for PP1DATA. When I tried to bring drives online to find P drive and bring it up I couldn't bring them online. Is the absence of P drive related to this error?

Thank you,

 

." failed with the following error: "The operating system returned error 21(The device is not ready.) to SQL Server during a write at offset 0x0000005ec32000 in file 'P:\PP1DATA1\PP1DATA1.mdf'. Additional messages in the SQL Server error log and system event log may provide more detail. This is a severe system-level error condition that threatens database integrity and must be corrected immediately. Complete a full database consistency check (DBCC CHECKDB). This error can be caused by many factors; for more information, see SQL Server Books Online.  BACKUP DATABASE is terminating abnormally."

A :

Sort of.  I misunderstood what the P drive was, sorry about that.

It seems that the backup failed because it could not find the MDF for the database it was trying to back up.  I am actually surprised that your instance was running at all.  Are your system databases on a different drive?

I think that we're having a problem with some definitions here.  A 'shared drive' is not really the appropriate terminology.  In order for a SQL cluster to use a drive, that drive must be known to the cluster as a cluster resource.  Indeed, if the P drive failed over to the other node, then it would HAVE to be a cluster resource.  The easiest way to determine which drives are cluster resources is to look into the Cluster Administrator.  It will tell you which resources are active on which nodes. You can get to it via the administrative tools menu.  If you do not know the cluster name, you can simply use a period '.' if you are on the cluster when you run the Cluster Administrator.

It is important to understand that a SQL failover cluster is designed to recover from a failure at the server level.  This specifically excludes storage.  If your storage medium fails, no amount of clustering will save you.

As I mentioned earlier, you need to make sure that the SQL virtual server and all related drive resources are on the same node in order for your server to work as expected.  Correctly set dependencies will help with that

------------------------------------------------ 이건 참고 자료... -------------------------------------------------------------

출처 : http://support.microsoft.com/kb/304261

대략 내용은 드라이버 잘 골라써라 지원 잘되는 녀석으로 골라써라 이런 내용이네요 흠

SQL Server의 네트워크 데이터베이스 파일 지원에 대한 설명

이 문서가 적용되는 제품 보기.

이 문서는 이전에 다음 ID로 출판되었음: KR304261

이 페이지에서

• 요약
  • WHQL(Windows Hardware Quality Lab) 인증 장치
  • 기타 장치
• 추가 정보
  • 성능 문제
  • 백업 및 복원 고려 사항
  • 추가 정보
  • 참조

모두 확대 | 모두 축소

요약

SQL Server의 성능과 안정성을 최적화할 수 있도록 Microsoft SQL Server 데이터베이스 파일의 저장소로 SAN(저장 영역 네트워크)이나 로컬로 연결된 디스크를 사용하도록 구성하는 것이 좋습니다. 기본적으로 네트워크 기반 서버나 NAS(네트워크 연결 저장소)에 저장된 네트워크 데이터베이스 파일은 SQL Server에서 사용할 수 없습니다.

그러나 네트워크 기반 서버나 NAS 저장소 서버에 데이터베이스를 저장하도록 SQL Server를 구성할 수 있습니다. 이러한 목적으로 사용되는 서버는 이 문서의 "추가 정보" 절에 자세히 설명되어 있는 데이터 쓰기 순서 지정 및 쓰기(write-through) 보증에 대한 SQL Server 요구 사항을 충족해야 합니다.

위로 가기

WHQL(Windows Hardware Quality Lab) 인증 장치

WHQL(Windows Hardware Quality Lab)에서 인증한 Microsoft Windows 서버 및 네트워크 기반 서버 또는 NAS 저장소 서버는 SQL Server 저장 장치를 지원하는 데 필요한 데이터 쓰기 순서 지정 및 쓰기(write-through) 보증을 자동으로 충족합니다. Microsoft는 이러한 구성에서 응용 프로그램과 저장소 관련 문제를 모두 지원합니다.

위로 가기

기타 장치

이 문서에 설명되어 있는 트랜잭션 데이터베이스 사용을 위해 I/O 보증을 지원하는 비WHQL 인증 저장 장치를 SQL Server에서 사용하는 경우 Microsoft는 SQL Server와 SQL Server 기반 응용 프로그램을 완전히 지원합니다. 그러나 장치나 장치의 저장소 하위 시스템과 관련된 문제나 이로 인해 발생되는 문제는 해당 장치 제조업체에 문의해야 합니다. 이 문서에 설명되어 있는 트랜잭션 데이터베이스 사용을 위해 I/O 보증을 지원하지 않는 비WHQL 인증 저장 장치를 사용하는 경우 Microsoft는 SQL Server나 SQL Server 기반 응용 프로그램을 지원할 수 없습니다. 비WHQL 인증 저장 장치가 이 문서에 설명되어 있는 트랜잭션 데이터베이스 사용을 위해 I/O 보증을 지원하는지 여부와 데이터베이스 사용을 위해 설계되었는지 여부를 확인하려면 해당 장치 공급업체에 문의하십시오. 또한 트랜잭션 데이터베이스 사용을 위해 장치가 올바르게 배포되고 구성되었는지 여부도 장치 공급업체에 문의하십시오.

위로 가기

추가 정보

기본적으로 네트워크 파일 공유에 SQL Server 데이터베이스를 만들 수 없습니다. 매핑된 네트워크 또는 UNC 네트워크 위치에 데이터베이스 파일을 만들려고 하면 다음과 같은 오류 메시지가 나타날 수 있습니다. 

메시지 1

5105 "장치 활성화 오류입니다."

메시지 2

5110 "'file_name' 파일이 데이터베이스 파일을 지원하지 않는 네트워크 장치에 있습니다."

이것은 예상된 동작입니다. 추적 플래그 1807은 오류를 무시하고 네트워크 기반 데이터베이스 파일로 SQL Server를 구성할 수 있도록 해줍니다. SQL Server와 대부분의 다른 엔터프라이즈 데이터베이스 시스템은 트랜잭션 로그와 관련 복구 논리를 사용하여 시스템 오류가 발생하거나 시스템이 예상치 않게 종료될 경우 트랜잭션 데이터베이스가 일관된 상태로 유지되도록 합니다. 운영 체제 I/O(입/출력) 쓰기 요청이 데이터베이스 관리자로 반환되면 복구 시스템에서 쓰기가 실제로 완료되거나 쓰기 완료를 보증할 수 있도록 이러한 복구 프로토콜은 디스크 미디어에 직접 쓰는 기능을 사용합니다. 시스템 오류가 발생할 경우 이 프로토콜을 사용하는 소프트웨어나 하드웨어 구성 요소의 오류로 인해 데이터의 일부 또는 전체가 손실되거나 손상될 수 있습니다. SQL Server의 이러한 로깅 및 복구 프로토콜 현상에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.

230785  SQL Server 7.0, SQL Server 2000 및 SQL Server 2005의 로깅 및 데이터 저장소 알고리즘으로 인해 데이터 안정성이 높아진다

Microsoft는 이러한 연속 쓰기 및 쓰기 순서 지정 요구 사항을 충족하지 않는 NAS나 네트워크 기반 저장소 서버에서 SQL Server 네트워크 기반 데이터베이스 파일을 지원하지 않습니다.

네트워크 파일 공유를 사용하여 데이터베이스를 저장할 경우 네트워크 오류로 인해 데이터베이스 무결성이 손상되거나 성능이 저하될 수 있으므로 데이터베이스 파일을 로컬 디스크 하위 시스템이나 SAN(저장 영역 네트워크)에 저장하는 것이 좋습니다.

NAS(네트워크 연결 저장소) 시스템은 클라이언트가 TCP/IP 같은 네트워크 프로토콜을 사용하여 네트워크 리디렉터를 통해 연결하는 파일 기반 저장소 시스템입니다. 디스크 리소스에 액세스하기 위해 공유를 매핑해야 하거나 디스크 리소스가 네트워크에 UNC 경로(예: \\Servername\Sharename)를 통한 원격 서버로 나타나면 기본적으로 SQL Server 데이터베이스의 위치로 디스크 저장소 시스템을 사용할 수 없습니다.

위로 가기

성능 문제

SQL Server는 다른 엔터프라이즈 데이터베이스 시스템과 마찬가지로 I/O 하위 시스템에 많은 양의 데이터를 로드할 수 있습니다. 대부분의 대용량 데이터베이스 응용 프로그램에서 실제 I/O 구성과 튜닝은 전체 시스템 성능에 중요한 역할을 합니다. 다음 세 가지 주요 I/O 성능 요인을 고려하십시오.

• I/O 대역폭: 데이터베이스 장치에 대해 유지할 수 있는 집계 대역폭으로, 일반적으로 초당 MB로 측정됩니다.
• I/O 대기 시간: 데이터베이스 시스템의 I/O 요청과 I/O 요청의 완료 시점 사이의 대기 시간으로, 일반적으로 밀리초로 측정됩니다.
• CPU 비용: 데이터베이스 시스템이 단일 I/O를 완료하는 데 필요한 호스트 CPU 비용으로, 일반적으로 CPU 마이크로초로 측정됩니다.

이러한 I/O 요인으로 인해 병목 현상이 발생할 수 있으므로 데이터베이스 응용 프로그램을 위한 I/O 시스템을 설계할 때는 이러한 요인을 고려해야 합니다.

가장 간단한 형태로 NAS 솔루션은 표준 네트워크 리디렉터 소프트웨어 스택, 표준 NIC(네트워크 인터페이스 카드) 및 표준 이더넷 구성 요소를 사용합니다. 이 구성의 단점은 모든 파일 I/O가 네트워크 스택을 통해 처리되고 네트워크 자체의 대역폭이 제한될 수 있다는 점입니다. 이로 인해 특히 SQL Server와 같이 매우 높은 수준의 파일 I/O를 필요로 하는 프로그램에서 성능과 데이터 안정성 문제가 발생할 수 있습니다. Microsoft에서 테스트한 일부 NAS 구성에서 이 I/O 처리량은 같은 서버에 있는 직접 연결된 저장소 솔루션 처리량의 약 1/3 정도였습니다. 이러한 구성에서는 NAS 장치를 통해 I/O를 완료하는 CPU 비용이 로컬 I/O CPU 비용의 약 두 배가 됩니다. NAS 장치와 네트워크 인프라가 발전하면서 이러한 비율도 직접 연결된 저장소나 SAN과 비례해서 향상될 수도 있습니다. 또한 응용 프로그램 데이터의 대부분이 데이터베이스 버퍼 풀에 캐시되고 I/O 병목 현상이 발생하지 않을 경우 NAS 기반 시스템의 성능이 사용 중인 응용 프로그램에 적합하다고 할 수 있습니다.

위로 가기

백업 및 복원 고려 사항

SQL Server는 백업용으로 VDI(가상 장치 인터페이스)를 제공합니다. 가상 장치 인터페이스는 백업 소프트웨어 공급업체에 핫 백업 수행과 SQL Server 데이터베이스 복원을 위해 성능이 좋고 확장이 용이한 매우 안정적인 방법을 제공합니다.

백업 소프트웨어는 NAS와 관련된 특별 지원 없이 VDI를 통해 NAS 장치에 저장되어 있는 데이터베이스 파일에서 작동합니다. 그러나 이로 인해 백업과 복원을 수행하는 동안 많은 양의 추가 네트워크 트래픽이 발생할 수 있습니다. VDI를 통해 백업하는 동안 SQL Server는 원격으로 파일을 읽고 SQL Server 컴퓨터에서 실행 중인 타사 백업 소프트웨어에 데이터를 전달합니다. 복원도 이와 유사합니다.

추가 네트워크 오버헤드를 피하려면 백업 공급업체에서 백업 공급업체와 NAS 공급업체별로 NAS 관련 지원을 제공해야 합니다. SQL Server VDI를 사용하면 백업 소프트웨어에서 NAS 장치가 지원하는 하드웨어인 분할 미러(split-mirror) 또는 소프트웨어인 쓰기 중 복사(copy-on-write) 기술을 통해 NAS의 로컬 데이터베이스 파일을 신속히 복사할 수 있습니다. 이러한 기술을 사용하면 네트워크를 통해 백업 파일을 복사하는 오버헤드를 피하고 복원 횟수를 크게 줄일 수도 있습니다.

NAS에 저장된 백업은 NAS에 저장된 데이터베이스 파일과 동일한 오류에 취약하므로 이러한 백업을 대체 미디어에 복사하여 보호하는 것이 좋습니다.

주의 SQL Server VDI 지원 없이 NAS 백업 기술을 사용하면 백업에서 데이터베이스 손상이 발생할 수 있습니다. 예를 들어, 페이지가 조각나거나 로그 파일과 데이터 파일을 별도의 장치에 저장한 경우 이 두 파일이 일치하지 않을 수 있습니다. 데이터베이스를 복원하고 손상된 데이터에 액세스할 때까지 SQL Server에서 이러한 조각난 페이지나 불일치를 검색하지 못할 수 있습니다. Microsoft는 SQL Server와 통합되지 않는 NAS 백업 기술의 사용을 지원하지 않습니다.

SQL Server VDI의 백업 및 NAS 공급업체 지원은 다양합니다. VDI 지원에 대한 자세한 내용은 NAS 및 백업 소프트웨어 공급업체에 문의하십시오.

NAS 솔루션을 SQL Server 데이터베이스용으로 배포하려면 엔드 투 엔드 솔루션 설계가 데이터베이스 사용에 적합한지 해당 NAS 공급업체에 문의해야 합니다. 대부분의 NAS 공급업체는 이러한 목적으로 최상의 사용 안내와 인증된 구성을 마련해 놓고 있습니다. 또한 앞서 언급한 I/O 요인으로 인해 응용 프로그램에서 병목 현상이 발생하지 않도록 I/O 성능을 벤치마킹하는 것이 좋습니다. 

다음은 추적 플래그 1807이 있거나 없는 Microsoft SQL Server 2005, Microsoft SQL Server 2000 및 Microsoft SQL Server 7.0의 네트워크 기반 데이터베이스 파일의 동작에 대한 설명입니다. 매핑된 구문은 NET USE 명령에 의해 네트워크 경로와 연결된 드라이브 문자를 나타냅니다. UNC 구문은 \\Servername\Sharename 같은 네트워크 경로에 대한 직접 참조를 나타냅니다.

• 추적 플래그 1807이 없는 SQL Server 7.0에서 DISK INIT 이전 버전과 호환되는 구문 다음에 CREATE DATABASE 문을 매핑된 구문이나 UNC 구문에 사용할 경우 오류 5105가 발생합니다.
• 추적 플래그 1807이 있는 SQL Server 7.0에서 DISK INIT 이전 버전과 호환되는 구문 다음에 CREATE DATABASE 문을 매핑된 구문에 사용할 경우 파일이 성공적으로 만들어집니다. UNC 구문에 DISK INIT를 사용하면 오류 5105가 발생합니다.
• 추적 플래그 1807이 없는 SQL Server 2005, SQL Server 2000 또는 SQL Server 7.0에서 CREATE DATABASE 문을 매핑된 구문이나 UNC 구문으로 실행하면 SQL Server 7.0의 경우 오류 5105가 발생하고 SQL Server 2000의 경우 오류 5110이 발생합니다.
• 추적 플래그 1807이 있는 SQL Server 2005, SQL Server 2000 또는 SQL Server 7.0에서 매핑된 구문이나 UNC 구문으로 수행한 CREATE DATABASE 문은 성공합니다.

SQL Server는 SQL Server의 비장애 조치 클러스터 설치에 추적 플래그 1807을 사용하는 네트워크 기반 파일만 지원합니다. SQL Server 2005 및 SQL Server 2000에서는 MSCS(Microsoft Cluster Service) 클러스터 관리자가 저장 장치를 인식하고 등록해야 하므로 SQL Server의 장애 조치 클러스터 설치는 네트워크 기반 파일과 함께 사용할 수 없습니다.

위로 가기

추가 정보

NAS 제품에서 데이터베이스 소프트웨어를 잘못 사용하거나 잘못 구성된 NAS 제품에서 데이터베이스를 사용하면 전체 데이터베이스 손실 같은 데이터 손실이 발생할 수 있습니다. NAS 장치나 네트워크 소프트웨어에 쓰기 순서 지정이나 쓰기(write-through) 같은 데이터 보증이 완전히 적용되지 않을 경우 하드웨어, 소프트웨어 또는 전원 오류로 인해 데이터 무결성이 심각하게 손상될 수 있습니다.

위로 가기

참조

SQL Server의 쓰기 순서 지정이나 쓰기(write-through)에 대한 자세한 내용은 Microsoft 기술 자료의 다음 문서를 참조하십시오.

234656  INF: SQL Server에서 디스크 드라이브 캐싱 사용

SQL Server 온라인 설명서 항목: "추적 플래그"

출처 : http://support.microsoft.com/kb/955726/ko

SQL Server 2008의 syspolicy_purge_history SQL Server 에이전트 작업에 실패할 수 있습니다.

기계 번역된 문서와 영문 원본 문서 나란히 보기

기계 번역 고지 사항 보기

이 페이지에서

모두 확대 | 모두 축소

현상

클러스터된 인스턴스에서 syspolicy_purge_history 작업을 실행할 때 Microsoft SQL Server 2008의syspolicy_purge_history SQL Server 에이전트 작업에 실패할 수 있습니다.syspolicy_purge_history 작업 기록 로그 파일에 다음과 유사한 오류 메시지가 나타날 수 있습니다.

날짜 datetime
(syspolicy_purge_history) 작업 기록 로그 

단계 ID 3 
서버 SQLVirtualName \ instancename
작업 이름 syspolicy_purge_history 
단계 이름 지우기 존재하지 않는 시스템 상태 레코드입니다. 
기간 00시: 33 
SQL 심각도 0 
SQL 메시지 ID 0 
전자 메일을 받는 연산자 
운영자에게 보낸 Net 
페이징 연산자 
재시도 0을 시도했습니다. 

메시지 
사용자로 실행: user. 작업 스크립트를 다음 오류가 발생했습니다. 이러한 오류는 스크립트가 중지되지 않았습니다: A 작업 단계 1 줄에서 오류가 PowerShell 스크립트에서 받은. '(Get-Item SQLSERVER:\SQLPolicy\SQLVirtualName\instancename).EraseSystemHealthPhantomRecords() 해당 줄이 '. 

스크립트를 수정하고 작업을 다시 예약하십시오. PowerShell에 의해 반환된 오류 정보: ' SQL Server PowerShell 공급자 오류: 연결할 수 없습니다. ' SQLVirtualName \ instancename '. [SQLVirtualName서버에 연결하지 못했습니다. \ instancename. 서버에 연결하는 동안--> 오류가 발생했습니다. 

SQL Server 2005 연결할 때 기본 설정에서 SQL Server 원격 연결을 허용하지 않도록 팩트에 의해 이 오류가 발생할 수 있습니다. (provider: Named Pipes Provider, error: 40-Could not open a connection to SQL Server)] SQLVirtualName 서버에 연결하지 못했습니다. \ instancename. 서버에 연결하는 동안 오류가 발생했습니다. SQL Server 2005 연결할 때 기본 설정에서 SQL Server 원격 연결을 허용하지 않도록 팩트에 의해 이 오류가 발생할 수 있습니다. (공급자: 명명된 파이프 공급자 오류: 40 - SQL Server로의 연결을 열 수 없습니다.) ' 

작업 단계 1 줄에서 오류가 PowerShell 스크립트에서 받았습니다. '(Get-Item SQLSERVER:\SQLPolicy\SQLVirtualName\instancename).EraseSystemHealthPhantomRecords() 해당 줄이 '. 스크립트를 수정하고 작업을 다시 예약하십시오. PowerShell에 의해 반환된 오류 정보: '경로를 찾을 수 없습니다.' SQLSERVER:\SQLPolicy\ SQLVirtualName \ instancename ' 존재하지 않기 때문에. ' 작업 단계를 PowerShell 스크립트를 1 줄에서 오류를 받았습니다. '(Get-Item SQLSERVER:\SQLPolicy\SQLVirtualName\instancename).EraseSystemHealthPhantomRecords() 해당 줄이 '. 스크립트를 수정하고 작업을 다시 예약하십시오. PowerShell에 의해 반환된 오류 정보: ' null 값 식에 대해 메서드를 호출할 수 없습니다. '. 프로세스 종료 코드 -1입니다. 단계가 실패했습니다.

위로 가기

원인

syspolicy_purge_history 작업 클러스터 인스턴스의 가상 서버 이름 대신 컴퓨터 노드 이름을 사용하는 경우 이 문제가 발생할 수 있습니다.

위로 가기

해결 방법

이 문제를 해결하려면 다음 방법 중 하나를 사용하십시오.

위로 가기

방법 1: syspolicy_purge_history 작업 편집

syspolicy_purge_history 작업 단계를 3 편집하십시오. 이렇게 하려면 다음과 같이 하십시오.

1. SQL Server 관리 Studio 시작하십시오.
2. SQL Server 에이전트 를 확장한 다음 작업 확장하십시오.
3. syspolicy_purge_history, 마우스 오른쪽 단추로 클릭한 다음 속성 을 클릭하십시오.
4. 단계 를 클릭하십시오.
5. 존재하지 않는 시스템 상태 레코드 지우기 를 클릭한 다음 편집 을 클릭하십시오.
6. 명령 상자에서 클러스터 인스턴스의 가상 서버 이름을 사용하여 컴퓨터 노드 이름을 바꿉니다.
7. 확인 을 누른 다음 닫기 를 클릭하십시오.

위로 가기

방법 2: syspolicy_purge_history 작업을 다시 만들기

syspolicy_purge_history 작업 다시 만들려면 다음 Transact-SQL 문을 실행하십시오.

DECLARE @jobId uniqueidentifier

-- Obtain the current job identifier that is associated with the PurgeHistory
SELECT @jobId = CAST(current_value AS uniqueidentifier)
FROM msdb.dbo.syspolicy_configuration_internal
WHERE name = N'PurgeHistoryJobGuid'

-- Delete the job identifier association in the syspolicy configuration

DELETE FROM msdb.dbo.syspolicy_configuration_internal
WHERE name = N'PurgeHistoryJobGuid'

-- Delete the offending job
EXEC msdb.dbo.sp_delete_job @job_id = @jobId

-- Re-create the job and its association in the syspolicy configuration table
EXEC msdb.dbo.sp_syspolicy_create_purge_job

위로 가기