Azure SQL Managed Instance의 알려진 문제
적용 대상:
Azure SQL Managed Instance
이 문서에는 Azure SQL Managed Instance의 현재 알려진 문제와 해결 날짜 또는 가능한 해결 방법이 나와 있습니다. Azure SQL Managed Instance에 대한 자세한 내용은 Azure SQL Managed Instance란? 및 Azure SQL Managed Instance의 새로운 기능을 참조하세요.
참고 항목
Microsoft Entra ID는 이전의 Azure Active Directory(Azure AD)입니다.
알려진 문제
해결 방법 있음
Azure Portal의 장기 백업 목록에는 이름이 같은 활성 및 삭제된 데이터베이스에 대한 백업 파일 표시
Azure Portal 페이지의 Backups 탭에서 Azure SQL Managed Instance에 대해 장기 백업 목록을 나열하고 관리할 수 있습니다. 페이지에는 활성 또는 삭제된 데이터베이스, 장기 백업에 대한 기본 정보 및 백업 관리를 위한 링크가 나열됩니다. 관리 링크를 클릭하면 백업 목록이 있는 측면 블레이드가 열립니다. FILTER 논리와 관련된 문제로 인해 목록에는 동일한 이름의 활성 데이터베이스와 삭제된 데이터베이스 모두에 대한 백업이 표시됩니다. 삭제할 백업을 선택할 때 잘못된 데이터베이스에 대한 백업을 삭제하지 않도록 특별히 주의해야 합니다.
해결 방법: 목록에 표시된 백업 시간(UTC) 정보를 사용하여 데이터베이스에 속하는 백업 중 이름이 같지만 인스턴스에서 다른 기간에 존재한 백업을 구분합니다. 또는 PowerShell 명령 Get-AzSqlInstanceDatabaseLongTermRetentionBackup 및 Remove-AzSqlInstanceDatabaseLongTermRetentionBackup을(를) 사용하거나 CLI 명령 az sql midb ltr-backup list 및 az sql midb ltr-backup delete을(를) 사용하여 장기 백업을 관리합니다. DatabaseState 매개 변수 및 DatabaseDeletionTime 반환 값을 사용하여 데이터베이스 백업을 필터링합니다.
system_health 이벤트 세션의 event_file 대상에 액세스할 수 없음
system_health 이벤트 세션의 event_file 대상 콘텐츠를 읽으려고 하면 "지정된 파일 경로의 값으로 'https://'로 시작하는 유효한 URL이 필요합니다." 오류 40538이 발생합니다. SQL Server Management Studio에서 또는 sys.fn_xe_file_target_read_file 함수를 사용하여 세션 데이터를 읽을 때 발생합니다.
이러한 동작 변경은 최근 필수 보안 수정의 의도하지 않은 결과입니다. 고객이 Azure SQL Managed Instance에서 system_health 세션을 안전하게 계속 사용할 수 있도록 하는 추가 변경의 타당성을 조사하고 있습니다. 그 동안 고객은 Azure Blob Storage의 event_file 대상에서 system_health 세션과 동등한 항목을 생성하여 이 문제를 해결할 수 있습니다. system_health와 동등한 항목을 생성하기 위해 수정 가능한 system_health 세션을 생성하는 T-SQL 스크립트를 포함하여 자세한 내용은 system_health 세션 사용을 참조하세요.
Nov22FW 지원 관리형 인스턴스에서 @query 매개 변수를 사용하는 경우 sp_send_dbmail 프로시저에 실패할 수 있습니다.
@query 매개 변수를 사용할 때 sp_send_dbmail 프로시저에 실패할 수 있으며 이는 2022년 11월 기능 웨이브를 사용하도록 설정된 인스턴스에 영향을 줍니다. 저장 프로시저가 sysadmin 계정으로 실행될 때 실패합니다.
이 문제는 sp_send_dbmail에서 가장을 사용하는 방법과 관련된 알려진 버그로 인해 발생합니다.
해결 방법: sysadmin 계정이 아닌, 사용자가 생성한 적절한 사용자 지정 계정으로 sp_send_dbmail을 호출해야 합니다.
다음은 전용 계정을 생성하고 sp_send_dbmail을 통해 이메일을 전송하는 기존 개체를 수정하는 방법에 관한 예제입니다.
USE [msdb]
GO
-- Step 1: Create a user mapped to a login to specify as a runtime user.
CREATE USER [user_name] FOR LOGIN [login_name]
GO
EXEC msdb.dbo.sp_update_jobstep @job_name=N'db_mail_sending_job', @step_id=db_mail_sending_job_id , @database_user_name=N'user_name'
GO
-- Step 2: Grant DB Mail permissions to the user who created it.
ALTER ROLE [DatabaseMailUserRole] ADD MEMBER [user_name]
GO
-- Step 3: If the database of the job step is not msdb, the permission error cannot be avoided even if it is a member of the role, so set it to msdb.
EXEC msdb.dbo.sp_update_jobstep @job_name=N'db_mail_sending_job', @step_id=db_mail_sending_job_id , @database_name=N'msdb'
GO
-- Step 4: Set a principal in the email profile
EXEC msdb.dbo.sysmail_add_principalprofile_sp @principal_name=N'user_name', @profile_name=N'profile_name', @is_default=0
GO
칠레의 2022년 표준 시간대 업데이트에 대한 중간 지침
2022년 8월 8일, 칠레 정부는 DST(일광 절약 시간) 표준 시간대 변경에 대해 공식 발표했습니다. 2022년 9월 10일 토요일 오전 12:00부터 2023년 4월 1일 토요일 오전 12:00까지 공식 시간은 60분 앞서 설정됩니다. 이 변경은 태평양 SA 표준시, 이스터 섬 표준시 및 마가야네스 표준시라는 세 가지 표준 시간대에 영향을 줍니다. 영향을 받는 표준 시간대를 사용하는 Azure SQL Managed Instance는 Microsoft가 이를 지원하기 위해 OS 업데이트를 릴리스하고 Azure SQL Managed Instance 서비스가 OS 수준에서 업데이트를 흡수할 때까지 변경 내용을 반영하지 않습니다.
해결 방법: 관리형 인스턴스에 대해 영향을 받는 표준 시간대를 변경해야 하는 경우 제한 사항에 유의하고 설명서의 지침을 따르세요.
연결 유형을 변경해도 장애 조치(failover) 그룹 엔드포인트를 통한 연결에는 영향을 주지 않습니다.
인스턴스가 장애 조치(failover) 그룹에 참여하는 경우 인스턴스의 연결 형식을 변경해도 장애 조치(failover) 그룹 수신기 엔드포인트를 통해 설정된 연결에는 적용되지 않습니다.
해결 방법: 연결 유형을 변경한 후 장애 조치(failover) 그룹을 삭제하고 다시 생성합니다.
@query 매개 변수를 사용하면 sp_send_dbmail 프로시저가 일시적으로 실패할 수 있음
@query 매개 변수를 사용하면 sp_send_dbmail 프로시저가 일시적으로 실패할 수 있습니다. 이 문제가 발생하면 sp_send_dbmail 프로시저의 두 번째 실행이 Msg 22050, Level 16, State 1 오류 및 Failed to initialize sqlcmd library with error number -2147467259 메시지와 함께 실패합니다. 이 오류를 제대로 확인하려면 @exclude_query_output 매개 변수에 대해 기본값 0으로 프로시저를 호출해야 합니다. 그러지 않으면 오류가 전파되지 않습니다.
이 문제는 sp_send_dbmail이 가장 및 연결 풀링을 사용하는 방법과 관련된 알려진 버그로 인해 발생합니다.
이 문제를 해결하려면 출력 매개 변수 @mailitem_id에 의존하는 다시 시도 논리로 이메일을 보내기 위한 랩 코드를 사용합니다. 실행이 실패하면 매개 변수 값이 NULL이 되어 이메일을 성공적으로 전송하기 위해 sp_send_dbmail을 한 번 더 호출해야 함을 나타냅니다. 다음은 이 다시 시도 논리의 예제입니다.
CREATE PROCEDURE send_dbmail_with_retry AS
BEGIN
DECLARE @miid INT
EXEC msdb.dbo.sp_send_dbmail
@recipients = 'name@mail.com', @subject = 'Subject', @query = 'select * from dbo.test_table',
@profile_name ='AzureManagedInstance_dbmail_profile', @execute_query_database = 'testdb',
@mailitem_id = @miid OUTPUT
-- If sp_send_dbmail returned NULL @mailidem_id then retry sending email.
--
IF (@miid is NULL)
EXEC msdb.dbo.sp_send_dbmail
@recipients = 'name@mail.com', @subject = 'Subject', @query = 'select * from dbo.test_table',
@profile_name ='AzureManagedInstance_dbmail_profile', @execute_query_database = 'testdb',
END
서버 트러스트 그룹에서 관리형 인스턴스를 제거한 후 분산 트랜잭션을 실행할 수 있음
서버 트러스트 그룹은 분산 트랜잭션을 실행하기 위한 필수 조건인 관리형 인스턴스 간에 신뢰를 설정하는 데 사용됩니다. 서버 트러스트 그룹에서 관리형 인스턴스를 제거하거나 그룹을 삭제한 후에도 분산 트랜잭션을 실행할 수 있습니다. 분산 트랜잭션이 사용하지 않도록 설정되고 관리되는 인스턴스에서 사용자가 시작한 수동 장애 조치인지 확인하기 위해 적용할 수 있는 해결 방법이 있습니다.
관리형 인스턴스 스케일링 작업 후 분산 트랜잭션을 실행할 수 없음
서비스 계층 또는 vCore 수 변경을 포함하는 SQL Managed Instance 스케일링 작업은 백 엔드에서 서버 트러스트 그룹 설정을 다시 설정하고 분산 트랜잭션 실행을 사용하지 않도록 설정합니다. 해결 방법으로 Azure Portal에서 새 서버 신뢰 그룹을 삭제하고 만듭니다.
이전에 삭제한 논리 서버와 동일한 이름으로 SQL Managed Instance를 생성할 수 없습니다.
Azure SQL Database용으로 Azure에서 논리 서버를 만들고 SQL Managed Instance를 만들면 <name>.database.windows.com의 DNS 레코드가 만들어집니다. DNS 레코드는 고유해야 합니다. 따라서 SQL Database에 대한 논리 서버를 만든 후 삭제하는 경우 이름이 레코드에서 릴리스되기까지 7일의 임계값 기간이 있습니다. 해당 기간에 삭제된 논리 서버와 동일한 이름으로 SQL Managed Instance를 생성할 수 없습니다. 해결 방법으로, SQL Managed Instance에 대해 다른 이름을 사용하거나 논리 서버 이름을 릴리스하기 위한 지원 티켓을 만듭니다.
서비스 주체가 Microsoft Entra ID 및 AKV에 액세스할 수 없음
경우에 따라 Microsoft Entra ID(이전의 Azure Active Directory) 및 Azure Key Vault(AKV) 서비스에 액세스하는 데 사용되는 서비스 주체에 문제가 있을 수 있습니다. 따라서 이 문제는 SQL Managed Instance에서 Microsoft Entra 인증 및 TDE(투명한 데이터 암호화) 사용에 영향을 줍니다. 이는 일시적인 연결 문제 또는 다음과 같은 문을 실행할 수 없는 경우 발생할 수 있습니다. CREATE LOGIN/USER FROM EXTERNAL PROVIDER 또는 EXECUTE AS LOGIN/USER. 새 Azure SQL Managed Instance에서 고객 관리형 키로 TDE를 설정하는 것도 일부 상황에서 작동하지 않을 수 있습니다.
해결 방법: 업데이트 명령을 실행하기 전에 SQL Managed Instance에서 이 문제가 발생하지 않도록 하거나 업데이트 명령 후에 이미 이 문제가 발생한 경우 Azure Portal로 이동하여 SQL Managed Instance Active Directory 관리 페이지에 액세스합니다. 다음 오류 메시지가 표시되는지 확인합니다. "Microsoft Entra ID에 액세스하려면 관리형 인스턴스에 서비스 주체가 필요합니다. 서비스 주체를 만들려면 여기를 클릭하세요." 이 오류 메시지가 발생한 경우 해당 메시지를 선택하고 이 오류가 해결될 때까지 제공된 단계별 지침을 따르세요.
장애 조치(failover) 그룹용 포털을 통한 수동 장애 조치(failover)의 제한 사항
장애 조치(failover) 그룹이 서로 다른 Azure 구독이나 리소스 그룹의 인스턴스에 걸쳐 있으면 장애 조치(failover) 그룹의 주 인스턴스에서 수동 장애 조치(failover)를 시작할 수 없습니다.
해결 방법: 지리적 보조 인스턴스에서 포털을 통해 장애 조치(failover)를 시작합니다.
SQL 에이전트 역할에는 non-sysadmin 로그인에 대한 명시적 EXECUTE 권한이 필요함
비 sysadmin 로그인이 SQL 에이전트 고정 데이터베이스 역할에 추가되어 있는 경우 해당 로그인이 작동하려면 master 데이터베이스의 세 개 저장 프로시저에 명시적인 EXECUTE 권한을 부여해야 하는 문제가 있습니다. 이 문제가 발생하면 오류 메시지(The EXECUTE permission was denied on the object <object_name> (Microsoft SQL Server, Error: 229))가 표시됩니다.
해결 방법: SQL 에이전트 고정 데이터베이스 역할인 SQLAgentUserRole, SQLAgentReaderRole 또는 SQLAgentOperatorRole에 로그인을 추가하면 이러한 역할에 추가된 각 로그인에 대해 다음 T-SQL 스크립트를 실행하여 나열된 저장 프로시저에 EXECUTE 권한을 명시적으로 부여합니다.
USE [master];
GO
CREATE USER [login_name] FOR LOGIN [login_name];
GO
GRANT EXECUTE ON master.dbo.xp_sqlagent_enum_jobs TO [login_name];
GRANT EXECUTE ON master.dbo.xp_sqlagent_is_starting TO [login_name];
GRANT EXECUTE ON master.dbo.xp_sqlagent_notify TO [login_name];
메모리 내 OLTP 메모리 제한이 적용되지 않음
중요 비즈니스용 서비스 계층이 메모리 최적화 개체에 대한 최대 메모리 제한을 올바르게 적용하지 않는 경우가 있습니다. SQL Managed Instance를 사용하면 워크로드가 메모리 내 OLTP 작업에 메모리를 더 많이 사용할 수 있기 때문에 인스턴스의 가용성과 안정성에 영향을 줄 수 있습니다. 한도에 도달한 메모리 내 OLTP 쿼리는 즉시 실패하지 않을 수도 있습니다. 메모리 내 OLTP 메모리를 더 많이 사용하는 쿼리는 한도에 도달하면 더 빨리 실패합니다.
해결 방법:SQL Server Management Studio를 사용하여 메모리 내 OLTP 스토리지 사용량을 모니터링하여 워크로드가 사용 가능한 메모리보다 많은 메모리를 사용하지 않도록 합니다. vCore 수에 따라 메모리 한도를 늘리거나 메모리를 덜 사용하도록 워크로드를 최적화합니다.
비어 있지 않은 파일을 제거하는 동안 잘못된 오류가 반환됨
SQL Server 및 SQL Managed Instance에서는 사용자가 비어 있지 않은 파일을 삭제할 수 없습니다. ALTER DATABASE REMOVE FILE 문을 사용하여 비어 있지 않은 데이터 파일을 삭제하려고 하면 Msg 5042 – The file '<file_name>' cannot be removed because it is not empty 오류가 즉시 반환되지 않습니다. SQL Managed Instance에서 파일을 삭제하려고 계속 시도하며, 30분이 지나면 Internal server error로 인해 작업이 실패합니다.
진행 중인 데이터베이스 복원으로 인해 서비스 계층 변경 및 인스턴스 만들기 작업이 차단됨
RESTORE 문, Data Migration Service 마이그레이션 프로세스, 기본 제공 특정 시점 복원을 실행 중이면 복원 프로세스가 완료될 때까지 서비스 계층 업데이트 또는 기존 인스턴스 크기 조정 및 새 인스턴스 생성이 차단됩니다.
복원 프로세스는 복원 프로세스를 실행 중인 동일한 서브넷의 Managed Instance 및 인스턴스 풀에서 이러한 작업을 차단합니다. 인스턴스 풀의 인스턴스는 영향을 받지 않습니다. 서비스 계층 생성 또는 변경 작업이 실패하거나 시간 초과되지 않고 복원 프로세스가 완료되거나 취소되면 계속 진행됩니다.
해결 방법: 복원 프로세스가 완료될 때까지 기다리거나, 서비스 계층 만들기 또는 업데이트 작업의 우선 순위가 더 높으면 복원 프로세스를 취소합니다.
장애 조치(failover) 후 중요 비즈니스용 서비스 계층의 Resource Governor를 재구성해야 할 수도 있음
사용자 워크로드에 할당된 리소스를 제한할 수 있는 Resource Governor 기능이 장애 조치(failover) 후에 또는 사용자가 시작한 서비스 계층 변경(예: 최대 vCore 변경 또는 최대 인스턴스 스토리지 크기 변경) 후에 일부 사용자 워크로드를 잘못 분류할 수 있습니다.
해결 방법: ALTER RESOURCE GOVERNOR RECONFIGURE를 정기적으로 실행하거나 Resource Governor를 사용하는 경우에는 인스턴스가 시작될 때 SQL 작업을 실행하는 SQL 에이전트 작업의 일부로 실행합니다.
서비스 계층 업그레이드 후 데이터베이스 간 Service Broker 대화를 다시 초기화해야 함
데이터베이스 간 Service Broker dialog는 서비스 계층 변경 작업 후에 다른 데이터베이스의 서비스로 메시지를 배달하지 않습니다. 메시지는 손실되지 않으며 보낸 사람 큐에서 찾을 수 있습니다. SQL Managed Instance에서 vCore 또는 인스턴스 스토리지 크기를 변경하면 모든 데이터베이스에 대해 sys.databases 뷰의 service_broke_guid 값이 변경됩니다. 다른 데이터베이스의 Service Broker를 참조하는 BEGIN DIALOG 문을 사용하여 생성된 DIALOG가 있으면 대상 서비스에 메시지 전달이 중지됩니다.
해결 방법: 서비스 계층을 업데이트하기 전에 데이터베이스 간 Service Broker 대화를 사용하는 작업을 중지했다가 다시 초기화합니다. 서비스 계층 변경 후 배달되지 않은 메시지가 남아 있으면 소스 큐에서 메시지를 읽어서 대상 큐로 다시 보냅니다.
작은 데이터베이스 파일이 포함된 스토리지 공간 초과
CREATE DATABASE, ALTER DATABASE ADD FILE, RESTORE DATABASE 문은 인스턴스가 Azure Storage 제한에 도달할 수 있기 때문에 실패할 수 있습니다.
각 범용 SQL Managed Instance의 인스턴스에는 최대 35TB의 스토리지가 Azure 프리미엄 디스크 공간용으로 예약되어 있습니다. 각 데이터베이스 파일은 별도의 실제 디스크에 배치됩니다. 디스크 크기는 128GB, 256GB, 512GB, 1TB 또는 4TB일 수 있습니다. 디스크에서 사용되지 않은 공간은 요금이 부과되지 않지만 Azure 프리미엄 디스크 크기의 총 합계는 35TB를 초과할 수 없습니다. 경우에 따라 총 8TB가 필요하지 않은 관리형 인스턴스는 내부 조각화로 인해 스토리지 크기에 대한 35TB Azure 제한을 초과할 수 있습니다.
예를 들어 SQL Managed Instance의 범용 인스턴스에는 4TB 디스크에 크기가 1.2TB인 대용량 파일이 하나 있을 수 있습니다. 또한 각각 1GB이고 별도의 128GB 디스크에 있는 248개의 파일이 있을 수 있습니다. 이 예제에서:
- 전체 할당된 디스크 스토리지 크기는 1x4TB + 248x128GB = 35TB입니다.
- 인스턴스에서 데이터베이스에 대해 예약된 총 공간은 1x1.2TB + 248x1GB = 1.4TB입니다.
이 예는 특정 상황에서 특정 파일 배포로 인해 SQL Managed Instance의 인스턴스가 연결되지 않은 Azure 프리미엄 디스크에 예약되어 있는 35TB 한도에 도달할 수 있음을 보여줍니다.
이 예에서 기존 데이터베이스는 계속 작동하며, 새 파일이 추가되지 않는 한 문제 없이 커질 수 있습니다. 모든 데이터베이스의 총 크기가 인스턴스 크기 제한에 도달하지 않더라도 새 디스크 드라이브에 대한 충분한 공간이 없기 때문에 새 데이터베이스를 만들거나 복원할 수 없습니다. 이 경우 반환되는 오류가 명확하지 않습니다.
시스템 뷰를 사용하여 남은 파일 수를 식별할 수 있습니다. 이 제한에 도달하면 DBCC SHRINKFILE 문을 사용하여 작은 파일 중 일부를 비우고 삭제해보거나 이런 제한이 없는 중요 비즈니스용 계층으로 전환합니다.
데이터베이스 이름 대신 GUID 값이 표시됨
몇 가지 시스템 뷰, 성능 카운터, 오류 메시지, XEvent 및 오류 로그 항목에는 실제 데이터베이스 이름 대신 GUID 데이터베이스 식별자가 표시됩니다. 이러한 GUID 식별자는 나중에 실제 데이터베이스 이름으로 대체되기 때문에 사용하지 마세요.
해결 방법: sys.databases 뷰를 사용하여 실제 데이터베이스 이름에서 GUID 데이터베이스 식별자 형식으로 지정된 실제 데이터베이스 이름을 확인합니다.
SELECT name AS ActualDatabaseName,
physical_database_name AS GUIDDatabaseIdentifier
FROM sys.databases
WHERE database_id > 4;
CLR 모듈 및 연결된 서버에서 로컬 IP 주소를 참조할 수 없는 경우가 있음
SQL Managed Instance 및 연결된 서버 또는 현재 인스턴스를 참조하는 분산 쿼리의 CLR 모듈에서 로컬 인스턴스의 IP를 확인할 수 없는 경우가 있습니다. 이 오류는 일시적인 문제입니다.
동일한 인스턴스 내의 두 데이터베이스에 대한 트랜잭션 범위가 지원되지 않음
(2020년 3월에 해결됨) 동일한 트랜잭션 범위의 동일한 인스턴스 내에서 데이터베이스 두 개에 쿼리 두 개를 보내면 .NET의 TransactionScope 클래스가 작동하지 않습니다.
using (var scope = new TransactionScope())
{
using (var conn1 = new SqlConnection("Server=quickstartbmi.neu15011648751ff.database.windows.net;Database=b;User ID=myuser;Password=mypassword;Encrypt=true"))
{
conn1.Open();
SqlCommand cmd1 = conn1.CreateCommand();
cmd1.CommandText = string.Format("insert into T1 values(1)");
cmd1.ExecuteNonQuery();
}
using (var conn2 = new SqlConnection("Server=quickstartbmi.neu15011648751ff.database.windows.net;Database=b;User ID=myuser;Password=mypassword;Encrypt=true"))
{
conn2.Open();
var cmd2 = conn2.CreateCommand();
cmd2.CommandText = string.Format("insert into b.dbo.T2 values(2)"); cmd2.ExecuteNonQuery();
}
scope.Complete();
}
해결 방법(2020년 3월 이후 필요하지 않음):SqlConnection.ChangeDatabase(String)를 사용하여 두 연결을 사용하는 대신 연결 컨텍스트에서 다른 데이터베이스를 사용합니다.
해결 방법 없음
트랜잭션 복제에 사용되는 시스템 로그인 수 증가
Azure SQL Managed Instance 서비스는 트랜잭션 복제를 위해 시스템 로그인을 생성합니다. 이 로그인은 SSMS(개체 탐색기, 보안, 로그인) 또는 시스템 보기 sys.syslogins에서 찾을 수 있습니다. 로그인 이름 형식은 'DBxCy\WF-abcde01234QWERT'와 같으며 로그인에는 퍼블릭 서버 역할이 있습니다. 특정 조건에서 이 로그인이 다시 만들어지고 시스템의 오류로 인해 이전 로그인이 삭제되지 않습니다. 이로 인해 로그인 수가 증가할 수 있습니다. 이러한 로그인은 보안 위협을 나타내지 않습니다. 무시해도 됩니다. 이러한 로그인 중 하나 이상이 트랜잭션 복제에 사용되므로 삭제하면 안 됩니다.
수동 백업을 위한 msdb의 테이블에서 사용자 이름을 유지하지 않음
최근 msdb에서 자동 백업에 대한 지원을 도입했지만 테이블에는 현재 사용자 이름 정보가 포함되어 있지 않습니다.
Microsoft Entra 로그인 및 사용자가 SSDT에서 지원되지 않음
SQL Server Data Tools는 Microsoft Entra 로그인 및 사용자를 완전히 지원하지 않습니다.
Microsoft Entra 로그인 형식의 가장이 지원되지 않음
다음 Microsoft Entra 보안 주체의 EXECUTE AS USER 또는 EXECUTE AS LOGIN을 사용하는 가장은 지원되지 않습니다.
- 별칭이 지정된 Microsoft Entra 사용자입니다. 이 경우 다음과 같은 오류가 반환됩니다.
15517. - Microsoft Entra 애플리케이션 또는 서비스 주체를 기반으로 하는 Microsoft Entra 로그인 및 사용자입니다. 이 경우 다음과 같은 오류가 반환됩니다.
15517및15406.
지역 장애 조치(failover) 후 트랜잭션 복제를 다시 구성해야 함
장애 조치(failover) 그룹의 데이터베이스에서 트랜잭션 복제를 사용하도록 설정된 경우에는 다른 지역으로 장애 조치(failover)가 발생한 후 SQL Managed Instance 관리자가 모든 게시를 이전 주 데이터베이스에서 정리하고 새로운 주 데이터베이스에서 다시 구성해야 합니다. 자세한 내용은 복제를 참조하세요.
tempdb 구조와 콘텐츠가 다시 생성됨
tempdb 데이터베이스는 항상 12개의 데이터 파일로 분할되며 파일 구조를 변경할 수 없습니다. 파일당 최대 크기는 변경할 수 없으며, tempdb에 새 파일을 추가할 수 없습니다. tempdb 데이터베이스는 인스턴스가 시작되거나 장애 조치될 때 항상 빈 데이터베이스로 다시 생성되며 tempdb에서 변경한 내용은 유지되지 않습니다.
오류 로그가 지속되지 않음
SQL Managed Instance에서 사용할 수 있는 오류 로그는 유지되지 않으며, 해당 크기는 최대 스토리지 한도에 포함되지 않습니다. 장애 조치(failover)가 발생하면 오류 로그가 자동으로 지워질 수 있습니다. 여러 가상 머신에서 SQL Managed Instance가 여러 번 이동했기 때문에 오류 로그 기록에 차이가 있을 수 있습니다.
크기 조정 작업 중에 장애 조치(failover) 그룹 수신기를 사용하여 임시 인스턴스에 액세스할 수 없음
관리형 인스턴스 크기를 조정하려면 연결된 서비스에서 유지 관리하는 DNS 레코드와 함께 다른 가상 클러스터로 인스턴스를 이동해야 하는 경우가 있습니다. 관리형 인스턴스가 장애 조치(failover) 그룹에 참여하는 경우 연결된 장애 조치(failover) 그룹 수신기에 해당하는 DNS 레코드(인스턴스가 현재 지역 주 위치인 경우 읽기 전용 수신기, 인스턴스가 현재 지역 보조 위치인 경우 읽기 전용 수신기)가 새 가상 클러스터로 이동됩니다.
현재 크기 조정 작업 디자인에서 관리형 인스턴스가 새 가상 클러스터로 완전히 마이그레이션되기 전에 수신기 DNS 레코드는 원래 가상 클러스터에서 제거됩니다. 때때로 이 경우 수신기를 사용하여 인스턴스의 IP 주소를 확인할 수 없는 시간이 길어질 수 있습니다. 이 시간 동안 수신기 엔드포인트를 사용하여 크기가 조정되는 인스턴스에 액세스하려는 SQL 클라이언트에서는 로그인에 실패하며 다음 오류 메시지가 표시될 수 있습니다. "오류 40532: 로그인에서 요청한 "xxx.xxx.xxx.xxx" 서버를 열 수 없습니다. 로그인이 실패했습니다. (Microsoft SQL Server, 오류: 40532)".
이 문제는 크기 조정 작업 재설계를 통해 해결됩니다.
해결됨
지원되지 않는 오류 메시지와 함께 외부 테이블 쿼리 실패
외부 테이블 쿼리가 실패하고 "외부 테이블에 대한 쿼리는 이 데이터베이스의 현재 서비스 계층 또는 성능 수준에서 지원되지 않습니다. 데이터베이스의 서비스 계층 또는 성능 수준을 늘리십시오” 오류 메시지가 나타날 수 있습니다. Azure SQL Managed Instance에서 지원되는 유일한 외부 테이블 유형은 PolyBase 외부 테이블(미리 보기)입니다. PolyBase 외부 테이블에 대한 쿼리를 허용하려면 sp_configure 명령을 실행하여 관리형 인스턴스에서 PolyBase를 사용하도록 설정해야 합니다.
Azure SQL Database의 탄력적 쿼리 기능과 관련된 외부 테이블은 SQL Managed Instance에서 지원되지 않습니다. 그러나 생성 및 쿼리는 명시적으로 차단되지 않았습니다. PolyBase 외부 테이블을 지원하여 PolyBase를 사용하도록 설정하지 않는 한 관리되는 인스턴스의 모든 유형의 외부 테이블 쿼리를 차단하는 새로운 검사가 도입되었습니다.
지원되지 않는 Elastic Query 외부 테이블을 사용하여 관리되는 인스턴스에서 Azure SQL Database 또는 Azure Synapse의 데이터를 쿼리하는 경우 대신 연결된 서버 기능을 사용해야 합니다. SQL Managed Instance에서 SQL Database로 연결된 서버 연결을 설정하려면 이 문서의 지침을 따릅니다. SQL Managed Instance에서 SQL Synapse로 Linked Server 연결을 설정하려면 단계별 지침을 확인합니다. Linked Server 연결을 구성하고 테스트하는 데 시간이 걸리므로 임시 솔루션으로 임시 솔루션을 사용하여 Elastic Query 기능과 관련된 외부 테이블을 쿼리할 수 있습니다.
해결 방법: 외부 테이블에 대한 쿼리를 사용하도록 설정하는 다음 명령(인스턴스당 한 번)을 실행합니다.
sp_configure 'polybase enabled', 1;
GO
RECONFIGURE;
GO
SQL Server 인증을 사용하는 경우 ‘@’이 있는 사용자 이름은 지원되지 않음
중간에 '@' 기호가 포함된 사용자 이름(예: 'abc@xy')은 SQL Server 인증을 사용하여 로그인할 수 없습니다.
CHECKSUM 없는 수동 백업 복원이 실패할 수 있음
특정 상황에서 CHECKSUM 없이 관리형 인스턴스에서 수행한 데이터베이스 수동 백업이 복원되지 않을 수 있습니다. 이러한 경우 성공할 때까지 백업 복원을 다시 시도하세요.
해결 방법: CHECKSUM을 사용하도록 설정한 상태로 관리형 인스턴스에서 데이터베이스 수동 백업을 수행합니다.
기존 작업을 수정하면 또는 사용하거나 사용하지 않도록 설정하면 에이전트가 응답하지 않음
특정 상황에서 기존 작업을 수정하거나 사용하거나 사용하지 않도록 설정하면 에이전트가 응답하지 않을 수 있습니다. 이 문제는 감지되면 자동으로 완화되어 에이전트 프로세스가 다시 시작됩니다.
리소스 그룹에 대한 권한이 SQL Managed Instance에 적용되지 않음
SQL Managed Instance 기여자 Azure 역할이 RG(리소스 그룹)에 적용되면 SQL Managed Instance에 적용되지 않으며 효과가 없습니다.
해결 방법: 사용자용 SQL Managed Instance 기여자 역할을 구독 수준에서 설정합니다.
에이전트 프로세스를 다시 시작하면 SQL 에이전트 작업이 중단될 수 있음
(2020년 3월에 해결됨) SQL 에이전트는 작업이 시작될 때마다 새 세션을 생성하여 메모리 사용이 점차적으로 증가합니다. 예약된 작업 실행이 차단되는 내부 메모리 제한에 도달하지 않도록 메모리 사용량이 임계값에 도달하면 에이전트 프로세스가 다시 시작됩니다. 이로 인해 다시 시작될 때 실행 중인 작업이 중단될 수 있습니다.
@query 매개 변수가 sp_send_db_mail에서 지원되지 않음
sp_send_db_mail 프로시저의 @query 매개 변수가 작동하지 않습니다.
서비스 주체를 다시 만들도록 제안하는 Azure Portal의 잘못된 오류 메시지
Azure SQL Managed Instance에 대한 Azure Portal의 Active Directory 관리자 페이지에는 서비스 주체가 이미 있더라도 다음 오류 메시지가 표시될 수 있습니다.
"Microsoft Entra ID(이전의 Azure Active Directory)에 액세스하려면 Managed Instance에 서비스 주체가 필요합니다. 서비스 주체를 만들려면 여기를 클릭하세요.”
관리형 인스턴스의 서비스 주체가 이미 있거나 관리형 인스턴스의 Microsoft Entra 인증이 작동하는 경우 이 오류 메시지를 무시할 수 있습니다.
서비스 주체가 있는지 확인하려면 Azure Portal의 엔터프라이즈 애플리케이션 페이지로 이동하고, 애플리케이션 종류 드롭다운 목록에서 관리 ID를 선택하고, 적용을 선택하고, 검색 상자에 관리형 인스턴스 이름을 입력합니다. 인스턴스 이름이 결과 목록에 표시될 경우 서비스 주체가 이미 존재하며 추가 작업이 필요하지 않습니다.
오류 메시지의 지침을 이미 따르고 오류 메시지에서 링크를 선택한 경우 관리형 인스턴스의 서비스 주체가 다시 생성됩니다. 이 경우 Microsoft Entra 인증이 제대로 작동하려면 새로 생성한 서비스 주체에 Microsoft Entra ID 읽기 권한을 할당합니다. 이 작업은 지침에 따라 Azure PowerShell을 통해 수행할 수 있습니다.
콘텐츠에 기여
Azure SQL 설명서에 기여하려면 Docs 기여자 가이드를 참조하세요.
관련 콘텐츠
SQL Managed Instance 업데이트 및 개선 사항 목록은 SQL Managed Instance 서비스 업데이트를 참조하세요.
모든 Azure 서비스에 대한 개선 사항 및 업데이트는 서비스 업데이트를 참조하세요.
피드백
출시 예정: 2024년 내내 콘텐츠에 대한 피드백 메커니즘으로 GitHub 문제를 단계적으로 폐지하고 이를 새로운 피드백 시스템으로 바꿀 예정입니다. 자세한 내용은 다음을 참조하세요. https://aka.ms/ContentUserFeedback
다음에 대한 사용자 의견 제출 및 보기