Microsoft OLE DB Driver for SQL Server 문제 해결

적용 대상:SQL Server Azure SQL Database Azure SQL Managed Instance Azure Synapse Analytics Microsoft Fabric의 SQL 데이터베이스

이 글을 통해 OLE DB 작업의 실패 단계를 식별하고, 다음 체크를 선택하며, 자세한 문제 해결 지침을 찾아보세요. 지침은 현재 제공자인 MSOLEDBSQL19를 사용합니다. 릴리스별 결함 및 업그레이드 변경 사항은 알려진 문제 및 주요 버전 차이를 참조하세요.

증상을 파악하세요

설정 변경 전에 전체 오류 설명과 모든 사용 가능한 오류 기록을 캡처하세요. 최상위 수준 HRESULT, 예: DB_E_ERRORSOCCURRED는 스스로 원인을 식별하지 못합니다. 제공자 로드, 연결 열기, 명령 실행, 데이터 가져오기, 트랜잭션 커밋 시 실패가 발생하는지 기록하세요.

증상	여기에서 시작
제공자를 찾을 수 없거나, 수업이 등록되어 있지 않습니다.	제공자 등록 및 아키텍처
로그인 실패, 접근 거부, 통합 인증 실패 등이 발생합니다.	로그인 및 인증 실패
인증서 체인이 신뢰되지 않거나, 인증서 이름이 일치하지 않는 경우도 있습니다.	TLS 인증서 실패
서버나 인스턴스를 찾을 수 없거나, 연결이 거부되는 경우도 있습니다.	네트워크 및 인스턴스 탐색 실패
매개변수가 실패하거나, 값이 잘려나거나, 데이터를 변환할 수 없게 됩니다.	매개변수 및 데이터 변환 오류
연결이 끊기거나, 복구에 실패하거나, 타임아웃이 만료됩니다.	연결 손실과 타임아웃
오류 정보가 누락되었거나, 지원을 위해 추적이 필요합니다.	진단 및 추적

연결 실패의 경우, 애플리케이션을 Universal Data Link(UDL) 연결 테스트와 비교하세요. 동일한 컴퓨터, 제공자, 프로세스 아키텍처, 인증 신원, 서버, 데이터베이스, 암호화 설정을 사용하세요. 다른 제공자나 신원으로 테스트가 성공했다고 해서 애플리케이션의 구성이 제대로 작동하는지 확인하지는 못합니다.

제공자 등록 및 아키텍처

Provider를 찾을 수 없거나 REGDB_E_CLASSNOTREG (0x80040154클래스가 등록되지 않음)와 같은 오류는 SQL Server 인증 전에 제공자 로딩이 발생했음을 나타냅니다.

신청서에서 요청하는 제공자를 확인하세요. MSOLEDBSQL19 그리고 MSOLEDBSQL 다양한 주요 모델을 식별할 수 있습니다. 현재 드라이버를 설치한다고 해서 애플리케이션의 제공자 선택이 바뀌지는 않습니다. 애플리케이션이 여전히 다른 제공자를 요청한다면 마이그레이션 단계를 따르세요.
애플리케이션을 호스팅하는 프로세스의 아키텍처를 확인하세요. 32비트 애플리케이션은 64비트 Windows에서도 32비트 제공자가 필요합니다. 서비스나 예약 작업의 경우, 개발 환경뿐만 아니라 해당 호스트가 사용하는 실행 파일과 계정을 확인하세요.
해당 애플리케이션을 실행하는 컴퓨터에서 지원되는 설치 프로그램으로 드라이버를 설치하거나 수리하세요. x64 설치 프로그램은 64비트와 32비트 드라이버 바이너리를 모두 포함하고 있습니다. ' OLE DB 드라이버 설치 및 시스템 요구사항'에서 필수 의존성을 확인하세요. 설치 대신 다른 컴퓨터에서 드라이버 라이브러리를 복사하지 마세요.
일치하는 아키텍처와 제공자를 사용하여 UDL 테스트를 다시 실행합니다. 작동은 하지만 애플리케이션이 여전히 공급자를 로드하지 못한다면, 애플리케이션의 효과적인 공급자 선택과 호스트 아키텍처를 테스트와 비교하세요.

오류가 명시적으로 명시adal.dll되어 있다면, 누락된 SQL Server 제공자로 간주하지 말고 알려진 인증 라이브러리 문제를 확인하세요.

서버 로그인 거부와 자격 증명 획득 실패 또는 암호화된 연결 설정 실패를 구분하세요. 중첩된 제공자 오류를 포함한 전체 오류 텍스트를 읽어보세요.

SQL Server 오류 18456의 경우, 데이터베이스 관리자에게 해당 서버 오류 로그 항목과 상태를 검사해 달라고 요청하세요. 인증 모드, 로그인 상태, 요청된 데이터베이스, 데이터베이스 접근 권한을 MSSQLSERVER_18456로 확인하세요. 모든 로그인 거부가 비밀번호 오류라고 가정하지 마세요.
통합 인증을 위해서는 애플리케이션이 실행되는 신원을 확인하세요. 서비스 계정이나 예약 작업 계정은 연결을 성공적으로 테스트한 사용자와 다를 수 있습니다. 메시지에 'SSPI 컨텍스트 생성 불가'가 포함되어 있다면, 보안 지원 제공자 인터페이스(SSPI) 문제 해결 과 서비스 주체명(SPN) 지원을 따르세요.
Microsoft Entra ID의 경우, 선택한 인증 방법이 애플리케이션의 실행 환경에 적합한지, 그리고 그 아이덴티티가 대상 데이터베이스에 접근할 수 있는지 확인하세요. Use Microsoft Entra ID에서 메서드별 설정과 접근 토큰 제한을 검토하세요. 인증 또는 자격 증명 속성이 충돌하는 액세스 토큰을 결합하지 마세요.
효과적인 설정과 올바른 연결 문자열 키워드 테이블을 비교하세요. IDBInitialize::Initialize IDataInitialize::GetDataSource, , 그리고 ActiveX Data Objects(ADO)는 서로 다른 키워드 테이블을 사용합니다. 애플리케이션이 사용하는 인터페이스를 표에서 확인하세요.

텍스트 '목표 주교 이름이 잘못되었다 '는 문구는 다양한 맥락에서 나타날 수 있습니다. Cannot generate SSPI context와 함께 나타나는 경우 Windows 인증 및 SPN을 조사하세요. 오류가 인증서나 암호화 핸드셰이크를 식별한다면 다음 섹션을 사용하세요.

TLS 인증서 실패

전송 계층 보안(TLS) 오류는 로그인이 SQL Server에 도달하기 전에 발생할 수 있습니다. 현재 드라이버는 기본적으로 필수 암호화를 활성화하므로, 업그레이드 시 이전 연결 구성에서 감지하지 못한 인증서 신뢰나 이름 문제를 노출시킬 수 있습니다.

인증서 체인이 신뢰할 수 없는 권한에서 발급된 경우, SQL Server가 제공하는 인증서와 클라이언트 컴퓨터가 신뢰하는 발급 인증서 체인을 확인하세요. 유효한 서버 인증서를 구성하고, 조직의 인증서 관리 프로세스를 통해 필요한 신뢰할 수 있는 루트 및 중간 인증서를 설치하세요.
인증서 이름 불일치가 발생하면, 애플리케이션이 사용하는 서버 또는 리스너 이름을 인증서 내 이름과 비교하세요. 의도한 연결 이름을 포함하는 인증서를 사용하세요. 애플리케이션이 의도적으로 다른 연결 이름을 사용한다면, 예상 인증서 이름을 설정하기 전에 문서화된 HostNameInCertificate 속성을 검토하세요.
유효한 암호화 및 검증 설정, 레지스트리 설정을 확인하세요. 암호화 및 인증서 검증 테이블에서 우선순위와 Strict 동작을 검토하세요. 모드에서는 Strict 드라이버가 trust-server-certificate 설정과 상관없이 인증서를 검증합니다.
만약 실패가 마이그레이션 중에 시작되었다면, 암호화 속성의 값 유형과 외부 Strict 모드 사용 ServerCertificate 제한 등 메이저 버전 문제 해결 사항을 확인하세요.

상세 점검을 위해 SQL Server에 대한 인증서 요구사항과 신뢰할 수 없는 인증서 체인 문제 해결을 사용하세요. 프로덕션 환경에서 암호화와 인증서 검증을 계속 활성화하세요. 이 둘 중 하나를 비활성화해도 인증서 배포 문제가 해결되지 않습니다.

네트워크 및 인스턴스 탐색 실패

서버 찾지 못하는 경우, 서버/인스턴스 위치 지정 오류 또는 연결 거부 오류는 애플리케이션이 도달하려는 엔드포인트를 식별합니다.

서버 이름, 인스턴스 이름, 그리고 설정된 리스닝 포트를 데이터베이스 관리자와 함께 확인하세요. 데이터베이스 서비스가 실행 중인지, 그리고 의도한 프로토콜과 리스너가 활성화되어 있는지 확인하세요. 모든 인스턴스가 포트 1433에서 듣는다고 가정하지 마세요.
원격 전송 제어 프로토콜(TCP) 연결의 경우, 드라이버의 tcp:<server>,<port> 서버 이름 형식을 사용하여 알려진 엔드포인트를 테스트합니다. 인증, 데이터베이스, 암호화 설정을 동일하게 유지하세요. 인터페이스에 적용되는 서버 키워드는 연결 문자열 키워드 를 참고하세요.
명시적인 호스트와 포트는 작동하지만 이름 있는 인스턴스는 작동하지 않는다면, SQL Server 브라우저와 인스턴스 탐색을 조사해 보세요. 브라우저 서비스와 브라우저 검색이 사용되는 사용자 데이터그램 프로토콜(UDP) 포트 1434 경로를 확인하세요.
명시적 엔드포인트도 실패하면, 도메인 네임 시스템(DNS) 해상도, 라우팅, 애플리케이션 호스트의 실제 리스닝 포트에 대한 방화벽 접근을 확인하세요. 여러 연결 설정을 한꺼번에 변경하기보다는 네트워크 관련 또는 인스턴스별 연결 오류를 따르세요.

가용성 그룹 리스너를 위해 고가용성 및 재해 복구 지원도 검토하세요. LocalDB의 경우, 원격 TCP 탐색 단계 대신 로컬 인스턴스와 사용자 컨텍스트를 확인하는 데 LocalDB 지원을 사용하세요.

매개변수 및 데이터 변환 오류

연결이 열렸지만 명령 실행이나 데이터 검색이 실패하면, 복제를 실패한 명령과 값으로 줄입니다. 민감한 데이터를 교체할 때 원본 데이터 타입, 길이, 널 상태, 문자 인코딩을 유지하세요.

각 ? 매개변수 마커를 그 결합 순서, 방향, 메타데이터와 비교하세요. 를 사용할 ICommandWithParameters::SetParameterInfo때, SQL 소스 타입을 명령어나 저장 프로시저와 일치시킵니다. 파라미터 메타데이터가 항상 자동으로 파생된다고 가정하지 마세요. 명령 어 매개변수 를 검토하여 유도 제한과 출력 매개변수 동작을 확인하세요.
전체 HRESULT만이 아니라 접근자 바인딩 상태와 반환된 각 값의 상태 및 길이도 확인하세요. 속성 설정 실패의 경우, 각 속성의 dwStatus를 검사하세요. 부분 성공 반환 DB_S_ERRORSOCCURRED 같은 경우, 오류 객체가 없더라도 상태 배열 검사가 필요할 수 있습니다. 반환 코드를 참조하세요.
변환 또는 절단을 위해 소비자 버퍼 유형과 크기를 실제 열이나 매개변수 메타데이터와 비교하세요. 숫자 값의 정밀도와 스케일, 날짜/시간 값의 유효 범위와 소수점 이하 초, 문자 버퍼의 바이트 길이를 확인하세요. 조사하고, DBSTATUS_E_CANTCONVERTVALUEDBSTATUS_S_TRUNCATED를 완전한 값으로 취급하지 마세요. 해당 규칙에는 데이터 타입 매핑, 행 가져오기, 날짜 및 시간 변환 을 사용하세요.
만약 할당된 출력 매개변수가 빠진 것으로 보이면, 읽기 전에 반환된 행셋을 모두 소진하세요. 여러 결과 집합을 처리하기 위해 IMultipleResults 사용 항목을 따르세요. 스트리밍 출력 매개변수의 경우, 스트리밍 지원 결과 매개변수에 설명된 대로 다음 결과를 요청하기 전에 대기 중인 스트림을 소비하거나 해제하세요.

ADO 관련 전용 매핑의 경우 OLE DB 드라이버와 함께 ADO 사용 및 DataTypeCompatibility의 에 대한 인증 제한을 검토하세요. 두 가지 모두를 확인하지 않고 호환성 설정을 추가하지 마세요.

드라이버 업그레이드 후 sql_variant 열에서 손상된 좁은 문자열의 경우, 저장된 데이터를 수정하기 전에 기존 SSVARIANT의 알려진 문제와 복구 절차를 검토하세요.

연결 손실과 타임아웃

연결이 마지막으로 작동한 시기, 실패한 작업, 그리고 그 작업이 얼마나 오래 지속되었는지 기록하세요. 재시도나 타임아웃 설정을 변경하기 전에 이 사례들을 구분하세요.

실패 단계	점검 및 상세 안내
연결을 여는 중.	먼저 제공업체, 네트워크, 인증, TLS 오류를 점검하세요. 유효한 `DBPROP_INIT_TIMEOUT` 또는 해당 연결 키워드를 확인하세요. 연결 타임아웃 문제 해결을 참고하세요.
명령을 실행합니다.	`DBPROP_COMMANDTIMEOUT` 또는 애플리케이션의 명령 시간 초과 설정을 확인해 보세요. Query Timeout 문제 해결을 통해 차단과 쿼리 성능을 조사하세요. 연결 타임아웃을 늘려도 명령어 타임아웃은 변하지 않습니다.
유휴 연결을 재사용하기.	유휴 연결 복원력에서 복구 조건, 재시도 설정 및 예상 오류를 확인하세요. 복구는 명령어 타임아웃이 만료되어 재연결이 완료되기 전에 실패할 수 있습니다.
실행 또는 커밋 중 연결이 끊기는 현상.	클라이언트와 서버 이벤트를 연관시켜 네트워크 중단, 서버 재시작, 또는 장애 조치 여부를 확인합니다. 재시도가 안전한지 결정하기 전에 수술 결과를 확립하세요.

유휴 연결 복원력은 초기 연결 재시도나 임의 명령어 및 트랜잭션의 자동 재생을 제공하지 않습니다. 확실한 과도 장애가 발생하면 지연이 있는 제한된 애플리케이션 재시도를 사용하고 각 시도를 기록하세요. 제공자 로딩 오류, 자격 증명 거부, 인증서 검증 실패를 원인을 수정하지 않고 반복적으로 재시도하지 마세요.

Caution

쓰기나 커밋 중에 연결이 끊기면, 클라이언트는 SQL Server가 트랜잭션을 커밋했는지 알 수 없습니다. 작전을 무작정 반복하지 마세요. 결과를 확인하거나 중복 효과를 방지하는 애플리케이션 디자인을 사용해 다시 시도하세요.

진단 및 추적

관련 없는 공급자 호출이 오류 정보를 덮어쓰기 전에, 오류가 발생한 시점의 진단 정보를 수집하세요.

실패한 작업, 타임스탬프와 시간대, 경과 시간 HRESULT등을 기록합니다. 네이티브 OLE DB 소비자의 경우, 첫 번째 설명뿐만 아니라 와 를 통해 IErrorInfoIErrorRecords모든 사용 가능한 레코드를 검색하세요. ISQLErrorInfo를 통해 사용할 수 있는 경우 SQLSTATE 및 네이티브 SQL Server 오류 번호를 포함합니다. 오류 정보 조회와 SQL Server 오류 세부 정보를 참조하세요. ADO의 경우, 연결의 Errors 컬렉션을 수집하세요.
오류를 보고하는 메서드별로 속성별, 바인딩별, 값별 상태를 수집하세요. 오류 객체가 없다고 해서 부분 성공 결과를 안심하고 무시할 수 있는 것은 아니다.
클라이언트 실패를 서버 오류 로그나 확장 이벤트와 연관 짓는 것입니다. 가능한 경우 ActivityID 및 ClientConnectionID를 기록하세요. 사전 로그인 전에 실패하면 클라이언트 연결 식별자 없이 발생할 수 있습니다.
오류 기록이 충분하지 않다면, 운전자 추적 및 상관관계 설정에 Extended Event 로그의 Access 진단 정보를 사용하세요. 재현 과정에 한정된 추적을 수집하고 이후에는 추적을 중지하세요.

에스컬레이션 시 드라이버 버전, 요청된 제공자, 애플리케이션 및 프로세스 아키텍처, 서버 버전, 인증 방법, 유효 연결 설정, 실패 단계, 오류 기록, 그리고 최소한의 재현을 포함하세요. 매칭 UDL 테스트가 성공했는지, 그리고 문제가 한 호스트에 영향을 미치는지 여러 호스트에 영향을 미치는지 명시합니다.

연결 설정과 로그에서 비밀번호, 접근 토큰 및 기타 비밀 정보를 제거하세요. 쿼리 텍스트와 민감한 데이터 추적을 검토하고, 제한된 접근 권한으로 저장하며, 승인된 지원 채널을 통해서만 공유하세요.

피드백

이 페이지가 도움이 되었나요?

Last updated on 2026-09-23