Oracle 등록에 문제가 있습니다.MS SQL Server 2012의 SQLCLR 어셈블리로 데이터 액세스

Oracle 등록에 문제가 있습니다.MS SQL Server 2012의 SQLCLR 어셈블리로 데이터 액세스

EDIT 3.5 (아래 항목 3을 마지막 업데이트에 넣으려 했으나 간과했습니다.아아...)

문제에 대한 어셈블리 등록이 실패하는 방법과 ProcExplor 추적에서 추론할 수 있는 제한된 정보를 살펴보면 몇 가지에 대해 결론을 내릴 수 있습니다.해결책은 없고, 몇 가지 추론만 있을 뿐입니다.

Microsoft는 Framework 2.0 어셈블리가 로드되도록 허용하려고 합니다.이러한 추론은 이러한 것들이 이러한 것들을 배제한다는 개념에만 국한되어 있다면, 어셈블리의 프레임워크 메타데이터에 대한 즉각적인 검사로 검증이 실패할 수 있다는 것을 근거로 합니다.이 실패는 2008 R2에서 4.0 어셈블리를 로드하는 것과 유사할 것입니다. 이와 반대로 엄격하고 구체적인 오류가 있습니다.

2.0 어셈블리가 포함된 2008 R2 데이터베이스로 업그레이드하면 어셈블리가 로드되고 해당 어셈블리의 기능이 SQL 2012 데이터베이스에서 실행됩니다.따라서 2.0 기반 어셈블리를 실행할 수 있는 기능이 매우 많습니다.로더를 통과시키는 것이 요령입니다. 따라서 CLR에서 갑자기 2.0 프레임워크 어셈블리를 활성화하는 패치나 SP를 발견하는 것이 놀랍지 않을 것이라는 믿음을 강화합니다.

의도적인 변경이나 버그를 통해 PERMISSION_SET = SUNFORK가 암시하는 검증 의미론의 일부가 SQL 2012에서 변경되었다고 생각합니다. 제 경험에 비추어 볼 때 이전 버전의 SQL Server CLR Verifier는 지정된 경우(관리되지 않는 포인터와 같은 항목을 확인하지 않음)와 동일한 성능을 발휘했습니다. 그러나 SQL 2012에서는 CLR 검증자가 안전하지 않은 권한 플래그와 상관없이 를 수행하는 것으로 보입니다. 저는 누군가가 이 이론을 검증할 수 있는지 알고 싶습니다*

EDIT2

이 문제에 대한 지속적인 연구 끝에, 저는 현재 사용되지 않는 시스템을 사용하기 위해 프로젝트를 개선하는 것 외에는 아직 해결책을 찾지 못했습니다.Microsoft가 몇 년 전에 만든 Data.Oracle Client 공급자입니다. 또한, 추가 조사와 이메일을 통해 SQL 2008 R2와 SQL 2012 간 어셈블리 검증 변경에 대한 "배터리 미포함" 공지가 적어도 한 두 건 이상 있을 것으로 생각됩니다. 이 어셈블리는 이를 정확하게 보여주는 것 같습니다. SQLCLR 어셈블리 등록 문제에 대한 몇 개 이상의 블로그 게시물로 인해 검증 프로세스에서 변경된 내용은 없지만 두 데이터베이스 간에 동일한 어셈블리를 등록하면 설명할 수 없는 문제가 발생한다는 주장이 제기되었습니다. SQL Server가 어셈블리를 검증하는 방법을 찾을 수 없으므로 현재로서는 (완전히) 어둠 속에서 솔루션을 계속 찾고 있습니다.*

MS SQL Server 데이터베이스 내에는 Oracle 데이터베이스에 대한 다양한 중요 쿼리를 수행하는 오래된 SQLCLR 프로젝트가 있습니다.이 프로젝트는 SQL 2005의 32비트 어셈블리에서 MS SQL Server 2008 R2용 64비트 어셈블리로 마이그레이션된 후 약 6년 동안 제대로 작동하고 있습니다.

MS SQL 2012 Upgrade Advisor가 특정 지리적 유형과 관련하여 SQLCLR 마이그레이션과 관련된 일반적인 문제만 지적했음에도 불구하고, 이러한 마이그레이션이 정말로 문제가 될 수 있다는 의심이 들었습니다.아니나 다를까, 이 프로젝트를 SQL Server 2012로 마이그레이션하는 것은 어려운 문제라고 생각합니다.

동일한 64비트 Oracle을 등록하려고 할 때한동안 SQL Server 2008 R2(및 그 상위 항목)에서 행복하게 살고 있던 DataAccess.dll(2.112.1.0)은 이제 어셈블리가 "확인에 실패"한다고 데이터베이스에 알립니다.편집: 안전하지 않은 권한이 부여된 어셈블리는 유효성 검사를 거치지 않는 것으로 알고 있습니다. 이거 맞지 않아요?

다음은 오류 응답의 발췌문입니다.

[ : Oracle.DataAccess.Client.OracleDatabase::Startup][mdToken=0x6000021][offset 0x00000048][found unmanaged pointer][expected readonly address of value 'Oracle.DataAccess.Client.OpoConValCtx'] Unexpected type on the stack.
[ : Oracle.DataAccess.Client.OracleDatabase::Startup][mdToken=0x6000021][offset 0x00000080][found unmanaged pointer][expected unmanaged pointer] Unexpected type on the stack.
[ : Oracle.DataAccess.Client.OracleDatabase::Startup][mdToken=0x6000021][offset 0x000000E3][found unmanaged pointer][expected readonly address of value 'Oracle.DataAccess.Client.OpoConValCtx'] Unexpected type on the stack.
[ : Oracle.DataAccess.Client.OracleDatabase::Startup][mdToken=0x6000021][offset 0x0000011B][found unmanaged pointer][expected unmanaged pointer] Unexpected type on the stack.
[ : Oracle.DataAccess.Client.OracleDatabase::Shutdown][mdToken=0x6000023][offset 0x0000003C][found unmanaged pointer][expected readonly address of value 'Oracle.DataAccess.Client.OpoConValCtx'] Unexpected type on the stack.
[ : Oracle.DataAccess.Client.OracleDatabase::Shutdown][mdToken=0x6000023][offset 0x00000073][found unmanaged pointer][expected unmanaged pointer] Unexpected type on the stack.
[ : Oracle.DataAccess.Client.OracleTransaction::Commit][mdToken=0x600002f][offset 0x0000008F][found unmanaged pointer][expected readonly address of value 'Oracle.DataAccess.Client.OpoTxnValCtx'] Unexpected type on the stack.
[ : Oracle.DataAccess.Client.OracleTransaction::Commit][mdToken=0x600002f][offset 0x000000A6][found unmanaged pointer][expected unmanaged pointer] Unexpected type on the stack.
[ : Oracle.DataAccess.Client.OracleTransaction::Dispose][mdToken=0x6000034][offset 0x0000001E][found unmanaged pointer][expected Native Int] ...

2012년의 SQLCLR이 이제 .NET 4.0을 사용한다는 것을 깨닫고, 아마도 동일한 DLL의 버전 4.0이 문제를 해결할 수 있을 것이라고 생각했습니다.그래서 저는 라이브러리의 4.0 특정 버전을 제공하는 ODAC 12.1.0.1의 64비트 버전을 다운로드했습니다.그러나 특히 "관리되지 않는 포인터 유형은 확인할 수 없습니다."와 관련하여 유사한(동일하지는 않지만) 어셈블리 생성/검증 실패가 확인되었습니다.

그런 다음 Oracle의 관리되는 코드 버전을 사용하려고 했습니다.데이터 액세스(Oracle).ManagedDataAccess) 및 이 어셈블리는 "순수" PE 형식 어셈블리가 아니기 때문에 등록에 실패하는 보조 어셈블리에 의존합니다(이후 연구 결과 MSIL과 어셈블리가 허용되지 않는 혼합물로 간주됨).즉, 관리 코드 버전은 SQLCLR에 로드할 수 없습니다.

그래서 저는 이 시점에서 질문과 대답이 거의 없습니다.2005/2008/2008R2와 2012년 사이에 어셈블리 유효성 검사와 관련하여 현재 주어진 어셈블리의 유효성 검사를 방해하는 정확히 무엇이 변경되었습니까?Oracle을 얻을 수 있는 옵션이나 솔루션이 있습니까?등록할 데이터 액세스?그렇지 않으면 프로젝트를 .NET 4.0으로 재구성/재대상화할 수 없습니다.시스템에서 이 구성 요소를 제거하는 것은 엄청난 골칫거리가 될 것이므로 어떠한 해결책이나 제안도 매우 감사할 것입니다.

실제로 SQL 서버 2012는 .NET Framework 4.0과 함께 작동합니다.SQL Server에서는 CLR의 여러 버전을 로드할 수 없습니다.SQL Server 2012에서는 혼합 어셈블리를 더 이상 로드할 수 없습니다.현재 .NET 2.0 기능을 포함하는 별도의 (웹) 서비스를 생성할 수 있습니다.그런 다음 생성한 순수 .NET 4.0 CLR 어셈블리에서 해당 서비스의 메서드를 호출합니다.저는 이것이 당신의 문제에 대한 가장 가능성 있는 해결책이라고 생각합니다.

언급URL : https://stackoverflow.com/questions/22845585/problems-registering-oracle-dataaccess-as-sqlclr-assembly-in-ms-sql-server-2012