Azure SQL에서 선택할 있는 다양한 배포 옵션

                                                                                                                                       

·       Version : Azure SQL

 

Microsoft Azure SQL 다양한 배포 옵션을 제공한다. 리프트 시프트 마이그레이션에서 기존 애플리케이션 현대화, 최신 클라우드 서비스 구축에 이르기 까지 Microsoft SQL Server 엔진으로 구동되는 여러 배포 옵션을 제공한다. Azure SQL 단일 통합 관리 환경을 제공하여 다양한 SQL Server 기반 응용 프로그램 모음을 대규모로 관리하는 복잡성을 제거한다. 배포에 옵션에 관한 자세한 내용은 아래 링크를 참고 한다.

·       (영어) https://docs.microsoft.com/en-us/azure/sql-database/sql-database-paas-vs-sql-server-iaas?WT.mc_id=DP-MVP-4039834

·       (한국어) https://docs.microsoft.com/ko-kr/azure/sql-database/sql-database-paas-vs-sql-server-iaas?WT.mc_id=DP-MVP-4039834

Microsoft 데이터 플랫폼은 SQL Server 기술을 활용하며 물리적 -프레미스 컴퓨터, 사설 클라우드 환경, 타사 호스팅 사설 클라우드 환경 공용 클라우드에 걸쳐 사용할 있도록 한다. Azure virtual machine ( SQL virtual machines) 대한 SQL Server 사용하면 동일한 서버 제품, 개발 도구 전문 지식 집합을 사용하는 동시에 -프레미스 클라우드 호스팅 배포를 조합하여 고유하고 다양한 비즈니스 요구사항을 충족할 있다. 아래 그림에 표시된 것처럼 제품은 인프라를 통해 보유하고 있는 관리 수준 비용 효울성을 기준으로 지정할 있다.

 

 

[SQL Database ]

안정적인 최신 SQL Server 기능을 사용하고 개발 마케팅에 시간 제한이 있는 최신 클라우드 응용 프로그램에 가장 적합하다. 안정적인 최신 SQL Server Enterprise Edition 기준으로 하는 완전 관리형 SQL 데이터베이스 엔진은PaaS(Platform as a Service) 범주로 분류되며, Azure 클라우드에서 호스트되는 관계형 DBaaS(Database as a Service)이다. SQL 데이터베이스는 여러 배포 옵션을 제공하며, 배포 옵션은 Microsoft에서 소유하고 호스트하고 유지 관리하는 표준화된 하드웨어 소프트웨어를 기반으로 한다. SQL Server 사용하면 광범위한 구성 (-프레미스 또는 Azure 가상 컴퓨터) 필요로 하는 기본 제공기능 기능을 사용할 있다. SQL Database 사용할 경우 추가 성능에 맞게 중단 없이 강화 확장하는 옵션을 통해 사용량에 따라 지불한다. SQL Database에는 기본 제공 고가용성, 인텔리전스 관리와 같이 SQL Server에서 사용할 없는 가지 추가 기능이 있다.

·       데이터베이스 서버를 통해 관리되는 자체 리소스 집합이 포함 단일 데이터베이스는 SQL Server 포함 데이터베이스와 비슷하다. 옵션은 새로운 클라우드 기반 애플리케이션의 최신 애플리케이션 개발에 맞게 최적화되어 있다. Hyperscale 서버 리스 옵션을 사용할 있다.

·       데이터베이스 서버를 통해 관리 되는 리소스의 공유 집합이 있는 데이터베이스를 Elastic Pool 이동하거나 Elastic Pool에서 제거할 있다. 옵션은 다중 테넌트 SaaS 응용 프로그램 패턴을 사용하여 새로운 클라우드를 사용 하는 응용 프로그램의 최신 응용 프로그램 개발에 최적화 되어 있다. Elastic Pool 변수 사용 패턴이 있는 여러 데이터베이스의 성능을 관리 하는 비용 효율적인 솔루션을 제공한다.

·       단일 데이터베이스 Elastic Pool 그룹을 관리하는 사용되는 데이터베이스 서버입니다. 데이터베이스 서버는 여러 단일 데이터베이스 또는 풀링된 데이터베이스, 로그인, 방화벽 규칙, 감사 규칙, 위협 검색 정책및 장애조치 (failover) 그룹에 대한 중앙 관리 지점 역할을 한다.

 

[SQL Managed Instance]

클라우드로의 대부분 마이그레이션에 적합 하다.Managed Instance 리프트 시프트 준비가 리소스의 공유 집합을 사용하는 시스템 사용자 데이터베이스의 컬렉션이다. 안정적인 최신 SQL Server 기능을 사용하고 최소한의 변경으로 클라우드로 마이그레이션되는 응용 프로그램 또는 기존 -프레미스 응용 프로그램에 가장 적합하다. Managed Instance 데이터베이스의 공유 리소스 추가 인스턴스 범위 기능을 제공 하는 Microsoft SQL Server 데이터베이스 엔진의 인스턴스와 비슷하다. Managed Instance 데이터베이스 변경없이 또는 최소한의 변경으로 -프레미스에서 데이터베이스를 마이그레이션할 있도록 지원한다. 옵션은 Azure SQL Database 모든 PaaS 혜택을 제공하지만 이전에 SQL VM에서만 사용할 있었던 기능을 추가한다. 여기에는 기본 가상 네트워크(VNet) -프레미스 SQL Server와의 거의 100% 호환성이 포함된다. Managed Instance SQL Server Azure 마이그레이션하기 위한 전체 SQL Server 액세스 기능 호환성을 제공한다.

 

[SQL virtual machines]

OS 수준 액세스를 필요로 하는 마이그레이션 응용 프로그램에 가장 적합하다. SQL 가상 머신은 변경 내용을 최소화 하거나 변경 하지 않고 클라우드로 신속하게 마이그레이션해야 하는 기존 응용 프로그램에 대해 리프트 시프트가 준비된다. SQL 가상 머신은 Azure로의 마이그레이션을 위해 SQL Server 인스턴스 기본 OS 모든 관리 권한을 제공한다. SQL 가상 머신은 IaaS (Infrastructure as a Service ) 포함 되며, Azure 클라우드의 완전히 관리 되는 VM (가상 머신) 내에서 SQL Server 실행할 있다. SQL 가상 머신은 Microsoft에서 소유하고 호스트 하며 유지관리하는 표준화된 하드웨어에서도 실행된다. SQL 가상 컴퓨터를 사용하는경우 이미 SQL Server 이미지에 포함 SQL Server 라이선스를 지불하거나 기존 라이선스를 쉽게 사용할 있다. 필요에 따라 VM 중지하거나 다시 시작할 수도 있다. 클라우드에 설치 호스트 되는 SQL Server Azure에서 실행 되는 Windows Server 또는 Linux 가상 컴퓨터 (IaaS (infrastructure as a service) 라고도 )에서 실행된다. SQL 가상 머신은 데이터베이스를 변경 하지않고 -프레미스 SQL Server 데이터베이스 응용 프로그램을 마이그레이션하는데 적합한 옵션이다. 모든 최신 버전의 SQL Server IaaS 가상 머신에 설치할 있다. SQL database SQL Managed Instance 가장 중요한 차이점은 SQL Server VM 데이터베이스 엔진에 대한 모든 권한을 허용 한다는 것이다. 유지 관리/패치를 시작할 시기를 선택하고, 복구 모델을 단순 또는 대량 로그로 변경하거나, 필요에 따라 서비스를 일시 중지 하거나 시작 , SQL Server 데이터베이스 엔진을 완벽하게 사용자 지정할 있다. 추가 컨트롤을 사용 하면 가상 머신을 관리하는 추가 책임이 있다.

 

Azure Portal에서는 SQL 가상 머신을 비롯 모든 Azure SQL 리소스 관리할 있는 단일 페이지를 제공 한다. Azure SQL 리소스 페이지에 액세스 하려면 Azure Portal 왼쪽 메뉴에서 Azure SQL 선택한. Azure SQL 목록에 없는 경우 모든 서비스를 선택한 다음 검색 상자에 Azure SQL 입력 합니다.기존 리소스를 관리 하려면 목록에서 원하는 항목을 선택한다. Azure SQL 리소스를 만들려면 [+ Add] 선택한다.

 

[+ Add] 선택한 여러 옵션에 대한 추가 정보를 확인할 있다.

 

 

[참고자료]

·       (영어) https://docs.microsoft.com/en-us/azure/sql-database/sql-database-paas-vs-sql-server-iaas?WT.mc_id=DP-MVP-4039834

·       (한국어) https://docs.microsoft.com/ko-kr/azure/sql-database/sql-database-paas-vs-sql-server-iaas?WT.mc_id=DP-MVP-4039834

 

 

 

2019-10-10 / Sungwook Kang / http://sungwookkang.com/

 

 

Azure SQL, Managed Instance, Azure SQL Database, Azure Virtual Machine

Azure SQL Database vCore 모델과 DTU 모델에서 마이그레이션

 

l  Version : Azure SQL

 

Azure SQL Database에서 vCore(가상코어) 구매 모델은 컴퓨팅 스토리지 리소스를 독립적으로 확장하고 -프레미스 성능을 조정하며 가격을 최적화할 있다. 또한 하드웨어 세대(Generation) 선택할 있다. 하드웨어 세대는 시간 지역에 따라 지원되는 세대가 다르므로, 항상 Microsoft 공식 문서를 참고할 있도록 한다.

l  (영어) https://docs.microsoft.com/en-us/azure/sql-database/sql-database-service-tiers-vcore/?WT.mc_id=DP-MVP-4039834

l  (한국어) https://docs.microsoft.com/ko-kr/azure/sql-database/sql-database-service-tiers-vcore/?WT.mc_id=DP-MVP-4039834

 

vCore 기반 구매 모델은 범용, 중요 비스니스, 하이퍼 규모의 계층을 제공한다. 이러한 서비스 계층은 다양한 계산 크기, 고가용성 디자인, 내결함성 방법, 저장소의 형식 크기, I/O 범위로 구분된다. 백업에 필요한 스토리지와 보존 기간을 개별적으로 구성해야 한다. 백업 보존 기간을 설정하려면 Azure Portal에서 백업 관리에서 있다.  아래 표는 계층 간의 차이점을 설명한다.

 

범용

업무상 중요

대규모

적합한 대상

예산 중심의 균형 잡힌 컴퓨팅 스토리 옵션을 제공

트랜잭션 속도가 높고 IO 대기 시간이 낮은 OLTP 빠른 장애조치에 높은 복원력을 제공

대부분의 비즈니스 워크로드. 최대 100TB 자동 스케일링 스토리지 크기, 유동적인 수직 수평 컴퓨팅 스케일링, 빠른 데이터 베이스 복원

컴퓨팅

프로 비전 계산:

Gen4: 1 개에서 24 까지의 vCores

Gen5: 2 ~ 80 vCores

서버를 사용 하지 않는 계산:

Gen5: 0.5-16 vCores

프로 비전 계산:

Gen4: 1 개에서 24 까지의 vCores

Gen5: 2 ~ 80 vCores

프로 비전 계산:

Gen4: 1 개에서 24 까지의 vCores

Gen5: 2 ~ 80 vCores

메모리

프로 비전 계산:

Gen4: vCore 7GB

Gen5: vCore 5.1GB

서버를 사용 하지 않는 계산:

Gen5: VCore 최대 24gb

프로 비전 계산:

Gen4: vCore 7GB

Gen5: vCore 5.1GB

프로 비전 계산:

Gen4: vCore 7GB

Gen5: vCore 5.1GB

스토리지

원격 저장소 사용

로컬 SSD 저장소 사용

필요에 따라 유연하게 증가하는 저장소 사용, 최대 100TB 저장소 지원

I/O 처리량 (근사치)

단일 데이터베이스 탄력적 : 최대 4만의 vCore 500 IOPS.

관리 되는 인스턴스: 파일의 크기에 따라 다름

최대 20만의 코어 5000 IOPS 최대 IOPS

Hyperscale 여러 수준에서 캐싱을 사용 하는 다중 계층 아키텍처이며 유효 IOPs 워크 로드에 따라 다름

가용성

복제본 1 , 읽기 확장 복제본 없음

3 복제본, 1 읽기 크기 조정 복제본,

영역 중복 HA (고가용성)

1 읽기/쓰기 복제본 0-4 읽기 확장 복제본

백업

읽기 액세스 지역 중복 저장소 (RA-GRS), 7-35 (기본적으로 7 )

RA-GRS, 7-35(기본값: 7)

Azure 원격 저장소의 스냅숏 기반 백업 복원은 빠른 복구를 위해 이러한 스냅샷을 사용, 백업은 즉시 수행

In-Memory

지원되지 않음

지원됨

지원되지 않음

 

 

vCore 기반 구매 모델의 프로비전 계산 계층에서는 SQL Server 대한 Azure 하이브리드 혜택을 사용하여 SQL Database 대한 할인된 요금으로 기존 라이선스를 교환할 있다. Azure 혜택을 통해 소프트웨어 보증이 있는 -프레미스 SQL Server 라이선스를 사용하여 Azure SQL Database 최대 30%까지 절약할 있다.

 

Azure 하이브리드 혜택을 사용하면 SQL database 엔진 자체 (기본 계산 가격 책정) 기존 SQL Server 라이선스를 사용하여 기본 Azure 인프라에 대해서만 비용을 지불하도록 선택하거나 기본 인프라와 SQL Server 대해 비용을 지불할 있다.

 

DTU 기반 모델에서 vCore 기반 구매 모델로 마이그레이션하는 것은 standard premium 서비스 계층에 있는 데이터베이스 간의 지역에서 복제 관계를 업그레이드하거나 다운그레이드 하는 것과 비슷하다. 마이그레이션 중에 지역에서 복제를 중지할 필요는 없지만 아래 규칙을 따라야 한다.

l  업그레이드하는 경우 보조 데이터베이스를 먼저 업그레이드한 다음, 데이터베이스를 업그레이드해야 한다.

l  다운그레이드하는 경우 반대 순서로 데이터베이스를 먼저 다운그레이드한 다음, 보조 데이터베이스를 다운그레이드 해야 한다.

l  Elastic Pool 복제를 사용하는 경우 하나의 풀을 기본 풀로 지정하고 다른 풀을 보조 데이터베이스로 지정하는 것이 좋다. 경우 Elastic Pool 마이그레이션하는 경우 동일한 순서의 지침을 사용해야 한다.

l  데이터베이스와 보조 데이터베이스를 모두 포함하는 Elastic Pool 사용하는 경우 사용률이 높은 풀을 데이터베이스로 처리하고 그에 따라 시퀀싱 규칙을 따른다.

 

아래 표는 특정 마이그레이션 시나리오에 대한 지침을 제공한다.

현재 서비스 계층

대상 서비스 계층

마이그레이션 유형

사용자 작업

Standard

범용 가상 컴퓨터

수평

순서에 관계없이 마이그레이션할 있지만 적절한 vCore 크기 조정을 보장해야 한다.

Premium

중요 비즈니스용

수평

순서에 관계없이 마이그레이션할 있지만 적절한 vCore 크기 조정을 보장해야 한다.

Standard

중요 비즈니스용

업그레이드

먼저 보조 데이터베이스를 마이그레이션해야 한다.

중요 비즈니스용

Standard

다운그레이드

먼저 데이터베이스를 마이그레이션해야 한다.

Premium

범용 가상 컴퓨터

다운그레이드

먼저 데이터베이스를 마이그레이션해야 한다.

범용 가상 컴퓨터

Premium

업그레이드

먼저 보조 데이터베이스를 마이그레이션해야 한다.

중요 비즈니스용

범용 가상 컴퓨터

다운그레이드

먼저 데이터베이스를 마이그레이션해야 한다.

범용 가상 컴퓨터

중요 비즈니스용

업그레이드

먼저 보조 데이터베이스를 마이그레이션해야 한다.

 

여러 데이터베이스가 있는 장애 조치 그룹을 마이그레이션하려면 데이터베이스와 보조 데이터베이스를 개별적으로 마이그레이션해야 한다. 과정에서 동일한 고려사항과 순서지정 규칙이 적용된다. 데이터베이스를 vCore 기반 구매 모델로 변환한 후에는 장애 조치 (failover) 그룹이 동일한 정책 설정에 계속 적용된다.

 

데이터베이스에 사용한 것과 동일한 서비스 계층을 사용하여 지역에서 복제 보조 데이터베이스 (지역 보조 데이터베이스) 만들 있다. 로그 생성 비율이 높은 데이터베이스의 경우 데이터베이스와 동일한 계산 크기로 지역 보조 데이터베이스를 만드는 것이 좋다.

단일 데이터베이스에 대한 Elastic Pool에서 지역 보조 데이터베이스를 만드는 경우 풀에 maxVCore 설정이 데이터베이스의 계산 크기와 일치하는지 확인한다. 다른 Elastic Pool에서 데이터베이스에 지역 보조 데이터베이스를 만드는 경우 풀에 동일한 @no__t 0 설정을 갖는 것이 좋다.

 

 

[참고자료]

l  (영어) https://docs.microsoft.com/en-us/azure/sql-database/sql-database-service-tiers-vcore/?WT.mc_id=DP-MVP-4039834

l  (한국어) https://docs.microsoft.com/ko-kr/azure/sql-database/sql-database-service-tiers-vcore/?WT.mc_id=DP-MVP-4039834

 

 

2019-10-09 / Sungwook Kang / http://sungwookkang.com/

 

 

Azure SQL, Managed Instance, Azure vCore

Azure SQL Database 서비스 계층에 따른 DTU 구매 모델

 

l  Version : Azure SQL

 

이전 포스트에서 Azure SQL Database 전반적인 내용에 대해서 살펴 보았다. Azure SQL Overview 대해서 자세히 알고 싶으면 아래 링크를 참고한다.

l  (영어) https://docs.microsoft.com/en-us/azure/sql-database/sql-database-technical-overview/?WT.mc_id=DP-MVP-4039834

 

l  (한국어) https://docs.microsoft.com/ko-kr/azure/sql-database/sql-database-technical-overview/?WT.mc_id=DP-MVP-4039834

 

Azure SQL Database 구매 모델에는 vCore 기반, DTU 기반, 서버리스 가지 모델이 있지만 이번 포스트에서는 DTU 기반 구매 모델에 대해서 살펴본다. DTU 기반 구매 모델에 대한 자세한 정보는 아래 링크를 통해서 확인할 있다.

l  (영어) https://docs.microsoft.com/en-us/azure/sql-database/sql-database-service-tiers-dtu/?WT.mc_id=DP-MVP-4039834

l  (한국어) https://docs.microsoft.com/ko-kr/azure/sql-database/sql-database-service-tiers-dtu/?WT.mc_id=DP-MVP-4039834

 

DTU 기반 구매 모델에서 서비스 계층은 포함된 스토리지의 고정된 , 고정된 백업 보존 기간 고정 가격을 갖춘 다양한 컴퓨팅 크기로 구분된다. DTU 기반 구매 모델의 모든 서비스 계층은 가동 중지 시간을 최소화하면서 계산 크기를 유연하게 변경할 있다. Single Database Elastic Pool 서비스 계층 컴퓨팅 크기에 따라 시간 단위로 청구된다. , Managed Instance DTU 구매 모델을 지원하지 않는다.

서비스 계층을 선택하는 방법은 비즈니스의 연속성, 스토리지 성능 요구사항에 따라 다르다. 아래 표는 서비스 계층에 따른 특징을 간략히 표로 정리한 것이다.

 

기본

표준

Premium

대상 워크로드

개발 프로덕션

개발 프로덕션

개발 프로덕션

SLA

99.99%

99.99%

99.99%

최대 백업 보존

7

35

35

CPU

낮음

낮음, 보통, 높음

보통, 높음

I/O 처리량 (근사치)

DTU 1-5 IOPS

DTU 1-5 IOPS

DTU 25 IOPS

I/O 대기시간 (근사치)

5ms(읽기), 10ms(쓰기)

5ms(읽기), 10ms(쓰기)

2ms (읽기/쓰기)

Columnstore indexing

해당 사항 없음

S3 이상

지원됨

In-memory OLTP

해당 사항 없음

해당 사항 없음

지원됨

 

 

컴퓨팅 크기는 단일 데이터베이스에 대해서는 DTU(데이터베이스 트랜잭션 단위), Elastic Pool 대해서는 eDTU(Elastic 데이터베이스 트랜잭션 단위) 표현된다. DTU eDTU 대한 내용은 아래 링크에서 자세히 확인할 있다.

l  (영어) https://docs.microsoft.com/en-us/azure/sql-database/sql-database-purchase-models#dtu-based-purchasing-model/?WT.mc_id=DP-MVP-4039834

l  (한국어) https://docs.microsoft.com/ko-kr/azure/sql-database/sql-database-purchase-models#dtu-based-purchasing-model/?WT.mc_id=DP-MVP-4039834

 

아래 표는 Single Database 대한 최대 스토리지 DUT 크기를 나타낸다.

 

기본

표준

 Premium

최대 스토리지 크기

2GB

1TB

4TB

최대 DTU

5

3000

4000

 

 

아래 표는 Elastic Pool 최대 스토리지 eDTU 크기를 나타낸다.

 

기본

Standard

Premium

데이터베이스당 최대 스토리지 크기

2GB

1TB

1TB

풀당 최대 스토리지 크기

156GB

4TB

4TB

데이터베이스당 최대 eDTU

5

3000

4000

풀당 최대 eDTU

1600

3000

4000

풀당 최대 데이터베이스

500

500

100

 

 

[참고자료]

l  (영어) https://docs.microsoft.com/en-us/azure/sql-database/sql-database-service-tiers-dtu/?WT.mc_id=DP-MVP-4039834

l  (한국어) https://docs.microsoft.com/ko-kr/azure/sql-database/sql-database-service-tiers-dtu/?WT.mc_id=DP-MVP-4039834

 

 

 

2019-10-09 / Sungwook Kang / http://sungwookkang.com/

 

 

Azure SQL, Managed Instance, Azure DTU

Azure SQL Database 서비스

 

·       Version : Azure SQL

 

Azure SQL Database 관리 서비스로 제공되는 범용 관계형 데이터베이스 이며, Azure Portal에서 응용 프로그램 솔루션에 대한 고가용성 고성능 데이터 저장소 계층을 만들 있다. 데이터 또한graph, JSON, spatial(공간), XML 관계형 데이터와 비관계형 구조 모두 처리할 수있다. Azure SQL Database Microsoft SQL Server 데이터베이스 엔진을 기반으로 하며, high-performance In-Memory Optimize 기능및 지능형 쿼리 같은 고급 처리 기술을 사용할 있다. 실제 Microsoft에서는 최신 기능은  Azure SQL Database 출시한 다음 SQL Server 출시한다.

Azure SQL Database 대한 자세한 내용은 아래 링크를 참고 한다.

·       What is the Azure SQL Database service? : https://docs.microsoft.com/en-us/azure/sql-database/sql-database-technical-overview/?WT.mc_id=DP-MVP-4039834

 

SQL Database 사용하면 vCore 기반 구매 모델 DTU 기반 구매 모델이라는 가지 구매 모델 내에서 성능을 쉽게 정의하고 확장할 있다. (vCore DTU 대한 내용은 다른 포스트에서 자세히 다루도록 한다.) SQL Database 고가용성, 백업 기타 일반적인 유지 관리 작업을 기본 제공하는 완전히 관리되는 서비스이다. Microsoft SQL 운영체제 코드의 모든 패치 업데이트를 처리한다. 사용자는 기본 인프라를 관리할 필요가 없다.

 

[Deployment models]

Azure SQL Database Azure SQL 데이터베이스에 다음과 같은 옵션을 제공한다.

 

·       Single Database 완전히 관리되는 격리된 데이터베이스를 나타낸다. 안정적인 단일 데이터 원본이 필요한 경우 최신 클라우드 응용프로그램 마이크로 서비스를 사용하는 경우 옵션을 사용할 있다. 단일 데이터베이스는 Microsoft SQL Server 데이터베이스 엔진의 포함된 데이터베이스와 비슷하다.

·       Managed instance Microsoft SQL Server 데이터베이스 엔진의 완전히 관리되는 인스턴스이다. 함께 사용할 있는 데이터베이스 집합이 포함되어 있다. -프레미스 SQL Server 데이터베이스를 Azure 클라우드로 쉽게 마이그레이션할 있으며, 데이터베이스 엔서 제공하는 SQL Server 데이터베이스 기능을 사용해야하는 경우 옵션을 선택한다.

·       Elastic Pool CPU, 메모리등의 공유 리소스 집합을 포함하는 단일 데이터베이스 컬렉션이다. 단일 데이터베이스를 Elastic Pool 이동하거나 Elastic Pool에서 제거할 있다.

 

[Scalable performance and pools]

할당된 리소스의 양을 정의할 있다.

·       Single Database 사용하는 경우 데이터베이스는 다른 데이터베이스와 격리 되며 이식 가능하다. 데이터베이스에는 자체 보장된 컴퓨팅, 메모리 스토리지 리소스가 있다.  데이터베이스에 할당된 리소스양은 해당 데이터베이스 전용이며 Azure 다른 데이터베이스와 공유되지 않는다. 단일 데이터베이스 리소스를 동적으로 확장 축소 있다. 또한 hyperscale service tier 사용하면 빠른 백업 복원기능을 통해 100TB 까지 확장할 있다.

·       Elastic Pool 사용하면 풀에 있는 모든 데이터베이스에서 공유하는 리소스를 할당할 있다. 데이터베이스를 만들거나 기존 단일 데이터베이스를 리소스 풀로 이동하여 리소스 사용을 최대화 하고 비용을 절감할 있다. 또한 옵션을 사용하면 Elastic Pool 리소스를 동적으로 확장 축소할 있다.

·       Managed Instance 사용할 경우 각각의 관리되는 인스턴스가 다른 인스턴스에서 격리되고 리소스가 보장된다. Managed Instance 내에서 데이터베이스 인스턴스는 리소스 집합을 공유한다. Managed Instance 리소스를 동적으로 확장 축소할 있다.

 

동적확장성과 자동 크기 조정은 의미가 조금 다르다. 자동 크기 조정은 서비스가 조건에 따라 자동으로 크기를 조정하는 경인 반면, 동적 확장성은 가동 중지 시간 없이 수동 크기 조정을 허용한다. Single Database 옵션은 수동 동적확장성을 지원하지만 자동 크기 조정 기능은 지원하지 않는다. 많은 자동 환경을 위해 데이터베이스에서 개별 요구 사항에 따라 풀의 리소스를 공유할 있도록 하는 Elastic Pool 사용하는 것이 좋다.

 

[Purchasing models]

SQL Database 다음과 같은 구매 모델을 제공한다.

·       vCore 기반 구매 모델 : vCore , 메모리 , 스토리지 속도를 선택할 있다. vCore 기반 구매 모델을 사용하면 SQL Server Azure 하이브리드 혜택을 사용하여 비용을 절감 있다.

·       DTU 기반 구매 모델 : DTU 기반 구매 모델은 3 가지 서비스 계층에 컴퓨팅, 메모리 I / O 리소스를 혼합하여 다양한 워크로드를 지원합니다. 계층 내의 컴퓨팅 크기는 이러한 리소스를 다르게 혼합하여 추가 스토리지 리소스를 추가 있다.

·       서버리스 모델은 워크로드 요구를 기반으로 계산을 자동으로 조정하고 초당 사용 계산량을 청구한다. 또한 서버리스 컴퓨팅 계층은 스토리지만 청구될 비활성 기간 동안 데이터베이스를 자동으로 일시 중지하고 활동이 반환되면 데이터베이스를 자동으로 다시 시작한다.

 

 [Elastic pools to maximize resource utilization]

사용 패턴이 비교적 예측 가능한 경우 많은 비즈니스 애플리케이션에서 단일 데이터베이스를 만들고 필요에 따라 충분히 성능을 확정하거나 축소할 있다. 예측할 없는 경우 비즈니스 모델을 관리하기 어려운데 Elastic Pool 문제를 해결하도록 설계되어 있다. 개별 데이터베이스 대신 풀에 성능 리소스를 할당한다. 단일 테이터베이스 성능이 아닌 풀의 집합적 성능 리소스에 대해 비용을 지불한다.

 

Elastic Pool 사용하면 리소스에 대한 요구가 변동함에 따라 데이터베이스 성능을 높이거나 낮추는데 집중할 필요가 없다. 풀링된 데이터베이스는 필요에 따라 탄력적 풀의 성능 리소스를 사용한다. 풀링된 데이터베이스는 풀의 한도를 사용하지만 초과하지 않으므로 개별 데이터베이스 사용량을 예측할 없는 경우에도 비용을 계속 예측할 있다.

 

[Extensive monitoring and alerting capabilities]

Azure SQL Database 고급 모니터링 문제 해결 기능을 제공한다. 최신 버전의 SQL Server 데이터베이스 엔진에서 제공하는 기본 모니터링 뿐만 아니라 Azure에서 제공되는 PassS 모니터링 기능을 통해 많은 데이터베이스 인스턴스를 모니터링하고 문제를 해결 있다.

·       Azure  Storage : 적은 비용으로 방대한 양의 원격 분석을 보관

·       Azure Event Hubs : SQL Database 원격 분석을 사용자 지정 모니터링 솔루션 또는 파이프 라인과 통합한다.

·       Azure Monitor logs : 보고, 경고 완화 기능이있는 기본 제공 모니터링 솔루션.

 

 

[Availability capabilities]

Azure 가용 영역은 단일 지역 단일 데이터 센터 건물의 중단을 방지하려고한다. 건물의 전력 또는 네트워크 손실을 방지한다. SQL Database에서는 서로 다른 가용 영역 (다른 건물, 효과적으로) 서로 다른 복제본을 배치한다. SQL Database 기본 제공 비즈니스 영속성 글로벌 확장성 기능을 제공한다.

·       Automatic backups : SQL Database SQL 데이터베이스의 전체, 차등 트랜잭션 로그 백업을 자동으로 수행하여 특정 시점으로 복원할 있도록 한다. 단일 데이터베이스 풀링된 데이터베이스의 경우 장기 백업 보존을 위해 Azure Storage 전체 데이터베이스 백업을 저장하도록 SQL Database 구성할 있다. Managed Instance 경우 장기 백업 보존을 위해 복사 전용 백업도 수행할 있다.

·       Point-in-time restores : 모든 SQL Database 배포 옵션은 SQL 데이터베이스에 대해 자동 백업 보존기간내의 특정 시점으로 복구를 지원한다.

·       Active get-replication : 단일 데이터베이스 풀링된 데이터베이스 옵션을 사용하여 동일하거나 세계적으로 분산된 Azure 데이터센터에서 최대 4개의 읽기 가능한 보조 데이터베이스를 구성할 있다.

·       Auto-failover groups : 모든 SQL Database 배포 옵션을 사용하면 장애 조치 그룹을 사용하여 글로벌 규모로 고가용성 부하 분산을 사용하도록 설정할 있다. 여기에는 데이터베이스, Elastic Pool Managed Instance 지역 복제 장애조치가 포함된다.

·       Zone-redundant database :  SQL Database 사용하면 여러 가용 영역에 걸쳐 프리미엄 또는 비즈니스 크리티컬 데이터베이스 또는 Elastic Pool 프로비저닝 있다. 이러한 데이터베이스와 Elastic Pool에는 가용성을위한 중복 복제본이 여러 있으므로 이러한 복제본을 여러 가용 영역에 배치하면 복원력이 향상된다. 여기에는 데이터 손실없이 데이터 센터 스케일 오류에서 자동으로 복구하는 기능이 포함된다.

 

[참고자료]

·       What is the Azure SQL Database service? : https://docs.microsoft.com/en-us/azure/sql-database/sql-database-technical-overview/?WT.mc_id=DP-MVP-4039834

 

 

 

2019-10-09 / Sungwook Kang / http://sungwookkang.com

 

Azure SQL, Managed Instance, Azure overview

SQL Server 2019 temp table 사용한 워크로드에서 recompile 감소

 

·       Version : SQL Server 2019

 

SQL Server 2019에는 응용프로그램 코드에 필요한 변경을 최소화 하면서 성능을 향상시키는 가지 성능 최적화가 도입 되었다. 이번 포스트에서는 SQL Server 2019 성능 개선 사항 하나인 temp 테이블을 사용한 작업 부하에 대해 리컴파일 감소로 인한 성능 향상을 설명한다.

·       Intelligent query processing in SQL databases : https://docs.microsoft.com/en-us/sql/relational-databases/performance/intelligent-query-processing?view=sql-server-2017

 

개선 사항을 이해하기 위해 먼저 SQL Server 2017 이전의 동작을 살펴본다. DML (SELECT, INSERT, UPDATE, DELETE) 사용하여 임시 테이블을 참조할 임시 테이블이 외부 범위 배치에 의해 생성된 경우에는 실행 마다 DML 문을 다시 컴파일 힌다.

아래 스크립트는 실습를 사용하여 재현할 있다. OuterProc 프로시저에서는 아래와 같은 기능을 한다.

1. 임시테이블 만들기

2. InnerProc 저장 프로시저 호출

 

 

InnerProc 저장 프로시저의 경우 OuterProc에서 생성된 임시 테이블을 참조하는 개의 DML 문이 있다.

3. 임시 테이블에 행을 삽입

4. 임시 테이블에서 행을 리턴

 

 

우리는 임시 테이블을 DML문과 다른 범위로 만들었으며 기존 구현(SQL Server 2019 이전) 대해 임시 테이블 스키마가 실질적으로 변경되지 않음을 신뢰하지 않으므로 실행될 때마다 연관된 DML문이 추가 리컴파일 활동을 하여 CPU 사용률을 높이고 전체 워크로드 성능 처리량을 줄여 성능 저하로 이어질 있다.

 

SQL Server 2019 부터는 불필요한 리컴파일을 피하기 위해 추가 검사를 수행한다.

·       컴파일 타임에 임시 테이블을 생성하는데 사용된 외부 범위 모듈이 연속 실행에 사용된 것과 동일한지 확인한다.

·       초기 컴파일시 변경 DDL (Data Definition Language) 변경 사항을 추적하고 이를 연속 시행을 위한 DDL작업과 비교한다.

결과적으로 보증하지 않은 리컴파일 관련  CPU 오버헤드가 줄어든다.

 

아래 그림은 “OuterProc“ 저장 프로시저를 1,000 (in a loop) 실행하는 16개의 동시 스레드의 테스트 결과를 보여준다. Y축은 발생횟수를 나타내며 파란색 선은 Batch Requests/sec 나타내고 녹색 선은 SQL Re-Compilations/sec 나타낸다.

 

예제에서 기능이 활성화 되면 다음과 같은 결과가 나타난다.

·       Batch Requests/sec (파란색 , 번째 ) 표시되는 처리량 개선

·       전체 작업 시간 단축

·       SQL Re-Compilations/sec (녹색선) 표시되는 리컴파일 감소. ( 번째 테스트 시작시 약간의 증가가 발생하였음)

 

기능은 모든 데이터베이스 호환성 수준에서 SQL Server 2019에서 기본적으로 사용된다. 글을 쓰는 시점에서 기능은 데이터베이스 호환성 수준 150에서 Azure SQL Database에서도 사용할 있지만, 향후 다른 호환성 수준에서도 적용될 있다.

 

 

2019-09-24/ Sungwook Kang / http://sungwookkang.com

 

 

 

Azure SQL, SQL Server 2019, temp table, SQL Re-compilations, Batch Requests, Intelligent query processing in SQL databases

Azure SQL Managed Instance SQL Server 2016 Later에서 대기 통계 분석

 

·       Version : Azure SQL, SQL Server 2016 Later

 

대기 통계(Wait Statistics)는데이터베이스 엔진에서 무언가를 기다리는 쿼리를 식별하는데 도움이 되며 쿼리 지속시간이 이유를 분석할 있는 정보를 나타낸다. 이번 포스트에서는 워크로드가 대기하는 이유와 일부 리소스에서 대기중인 쿼리를 식별하는 방법에 대해서 살펴본다.

 

Azure SQL Managed Instance 사용하면 아래 DMV 사용하여 쿼리가 리소스를 대기하는 이유를 찾을 있다.

·       sys.dm_os_wait_stats : 인스턴스 레벨에서  대기 정보 반환

·       sys.query_store_wait_stats : 데이터베이스 레벨에서 대기중인 쿼리의 실행계획 반환

 

이러한 정보는 DMO/Query Store 사용하여 찾을 있다. 그러나 분석을 쉽게 하기 위해 무료 오픈소스인 QPI 라이브러리를 사용할 있다.

·       QPI  : https://github.com/JocaPC/qpi

 

QPI 라이브러리를 설치하려면 아래 링크에서 SQL Server 버전에 대한 SQL 스크립트를 다운로드 있다. Query Store 의존하기 때문에 SQL Server 2016 이상, Azure SQL 에서 가능하다.

·       QPI Installation : https://github.com/JocaPC/qpi#installation

 

sys.dm_os_wait_stats 인스턴스 시작 이후 또는 통계를 마지막으로 재설정 이후에 대기 통계를 수집하므로 대기 통계의 스냅샷을 작성하거나 최소한 재설정을 해야한다. 아래 스크립트를 실행하여 QPI에서대기 통계를 재설정 있다.

exec qpi.snapshot_wait_stats

 

절차는 인스턴스의 대기 통계를 재설정하고 관리형 인스턴스는 대기 통계를 수집을  시작한다. 워크로드가 실행되는 동안 qpi.wait_stats보기에서 대기 통계 정보를 읽을 있다. 결과를 보면 인스턴스의 기본 대기 통계는 INSTANCE_LOG_RATE_GOVERNON이며 Log Rate Governor 분류 된다. 대기 유형의 영향을 받는 쿼리를 찾으려면 실제 대기 유형 이름이 아닌 쿼리 저정소에서 Category 사용해야 하므로 Category 중요하다. 쿼리 저장소의 대기 통계는 대기 유형별로 기록되지 않는다.

 

 

대기가 발생한 Category 영향을 받는 상위 쿼리를 보려면 qpi.db_query_wait_stats 보기를 사용하여 Category 해당하는 대기 통계를 필터링 있다.

 

예제의 경우 관리형 인스턴스에서 로그 속도 제한에 도달하고 있으며, 원인은 인덱스 재구축으로 인한것일 있다. 데이터베이스가 여러개인 경우 데이터베이스마다 쿼리 저장소가 구성되므로 데이터베이스에서 쿼리를 실행해야한다.

 

 

[참고자료]

https://blogs.msdn.microsoft.com/sqlserverstorageengine/2019/03/05/analyzing-wait-statistics-on-managed-instance/

 

 

2019-09-23/ Sungwook Kang / http://sungwookkang.com

 

 

Azure SQL, SQL Server Managed Instance, Query Store, QPI, sys.dm_os_wait_stats, sys.query_store_wait_stats

QPI(Query Performance Insights) 라이브러리를 사용하여 Azure SQL Managed Instance 로그쓰기 사용량 확인

 

·       Version : Azure SQL

 

Azure SQL Managed Instance Azure 클라우드에서 호스팅되는 완전히 관리되는 SQL Server 인스턴스이다. 관리형 인스턴스에는 최대 로그쓰기 처리량 성능에 일부 제한이 있어 워크로드 속도가 느려질 있다. 이번 포스트에서는 관리형 인스턴스에서 쓰기 로그 처리량 문제를 식별하는 방법에 대해서 살펴본다.

 

Azure SQL Managed Instance에는 최대 로그 쓰기 속도와 같은 가지 기본 제공 리소스 제한이 있다. 로그 쓰기 제한을 도입한 이유는 로그 백업이 들어오는 데이터를 포착할 있어야 하기 때문이다.

·       Overview Azure SQL Database managed instance resource limits : https://docs.microsoft.com/en-us/azure/sql-database/sql-database-managed-instance-resource-limits#service-tier-characteristics

 

이번 포스트에서는 QPI 라이브러리를 사용하여 관리형 인스턴의 대기 통계를 쉽게 분석하고 있다.  QPI 라이브러리를 설치하려면 아래 링크로 이동하여 SQL Server 버전에 대한 SQL 스크립트를 다운로드 한다. QPI 라이브러리는 Query Store 보기에 의존하기 때문에 SQL Server 2016이상, Azure SQL 에서 사용이 가능하다.

·       Download QPI(Query Performance Insights) : https://github.com/JocaPC/qpi#installation

Disclaimer: QPI library is open source library provided as-is and not maintained by Microsoft. There are not guarantees that the results are correct and that there are not bugs in calculations. This is a helper library that can help you to more easily analyze performance of your Managed Instance, but you can do the same job by looking directly at DMVs.

 

라이브러리를 사용하면 대기 통계의 스냅샷을 쉽게 작성하고 잠시 기다렸다가 대기 통계 값을 읽을 있다.

exec qpi.snapshot_wait_stats;

 

waitfor delay '00:00:03';

 

select *

from qpi.wait_stats

order by wait_time_s desc;

 

 

결과를 살펴보면, 관리 인스턴스의 태스크가 INSTANCE_LOG_RATE_GOVERNOR 대기 유형을 기다리고 있음을 있다. 스크립트를 주기적으로 실행하여 이러한 문제쿼리를 식별할 있다.  또한 qpi에서 제공하는 다양한 명령어를 사용하여 관리형 인스턴스의 IO 성능을 분석하여 병목 현상을 식별할 있다.

·       qpi.snapshot_file_stats 프로시저는 sys.dm_io_virtual_file_stats DMV 함수에서 I/O 통계 스냅샷을 작성한다. sys.dm_io_virtual_stats에는 누적 정보가 포함되어 있으며 최근 시간 간격으로 샘플을 계산해야 하므로 스냅샷을 작성해야 한다.

·       qpi.file_stats보기는 마지막 스냅샷 이후 파일 통계를 가져온다. qpi sys.dm_io_virtual_file_stats 데이터를 기반으로 하는 IOPS 처리량등 여러 계산이 포함된다.

 

아래 스크립트는 파일 유형(LOG/DATA)별로 분류된 인스턴스의 쓰기 처리량(MB/s) IOPS 요약한다.

exec qpi.snapshot_file_stats;

 

waitfor delay '00:00:01';

 

select

       type,

       write_mbps = sum(write_mbps),

       iops = sum(iops)

from qpi.file_stats

group by rollup (type);

 

 

결과를 살펴보면 현재 인스턴스에서는 47.5MB/s 로그파일 쓰기와 1226 IOPS 사용하고 있음을 있다. Azure 설명서에서 리소스 제한에 대한 설명을 보면  ~48MB/s 현재 사용되는 인스턴스의 리밋이며, 이러한 리밋으로 인해서 INSTNACE_LOG_RATE_GOVERNOR 대기 통계가 발생하는 것이다. 인스턴스의 최대 사용량 리밋으로 인해서 성능 저하가 발생하지 않도록QPI 스크립트를 주기적으로 실행하여, 인스턴스의 리밋과 QPI결과값을 비교하여,모니터링 있도록 한다.

 

[참고자료]

https://blogs.msdn.microsoft.com/sqlserverstorageengine/2019/03/11/identify-log-write-limits-on-azure-sql-managed-instance-using-qpi-library/

 

2019-09-10 / Sungwook Kang / http://sungwookkang.com

 

Azure SQL, QPI, Query Performance Insights, SQL Server 2016, Query Store

Azure SQL Managed Instance 에서 SQL Agent Job history 기록 보관하기

 

·         Version : Azure SQL

 

Azure SQL Managed Instance Azure 클라우드에서 호스트되는 완전히 관리되는 SQL Server 이다. Managed Instance 많은 SQL Server기능을 제공하지만 가지 제약이 있다. 제약사항 하나는 SQL Agent작업 실행의 히스토리 기록을 변경할 없다는 것이다. 이번 포트스에서는 제약 사항을 다른 방법으로 우회하여 해결하는 방법 하나를 소개한다.

 

Managed Instance SQL Agent 작업당 100개의 히스토리를 기록하며,  1000개의  히스토리 기록을 유지할 있다. 아래 프로시저를 실행하면 jobhistory_max_rows_per_job열에서 정보를 확인할 있다.

exec msdb.dbo.sp_get_sqlagent_properties

 

Azure SQL Managed Instance SQL Agent 히스토리를 기록하는 정보 값을 기본 레지스트리 값에 저장하므로 SQL Agent등록 정보를 변경할 없다. 그래서 SQL Agent 작업 히스토리에 대한 보존 정책 (작업 100개의 히스토리 또는  전체 히스토리 최대 1000개의 기록) 고정시켯다. 일부 직업의 경우 오래된 작업 기록을 확인하지 있다. 따라서 이러한 작업 히스토리 정보를 장기적으로 또는 삭제되기 이전에 정보를 보존하려면 sysjobhistory 테이블에서 정보를 다른 테이블에 저장해야 한다.  아래 예제를 통해서 어떻게 저장하는지 살펴본다.

 

Azure SQL Managed Instance Job history 테이블의 변경사항(삭제, 업데이트) 기록하기 위한 테이블을 생성하고 기존 테이블에 변경 사항이 있을때 버전 배치작업을 사용하여 히스토리를 새로운 테이블을 기록한다. sysjobhistory 테이블의 변경 사항을 다른 테이블(sysjobhistoryall) 저장하도록 변환하려면 아래 스크립트를 적용한다.

ALTER TABLE [msdb].[dbo].[sysjobhistory]

ADD StartTime DATETIME2 NOT NULL DEFAULT ('19000101 00:00:00.0000000')

GO

 

ALTER TABLE [msdb].[dbo].[sysjobhistory]

ADD EndTime DATETIME2 NOT NULL DEFAULT ('99991231 23:59:59.9999999')

GO

 

ALTER TABLE [msdb].[dbo].[sysjobhistory]

ADD PERIOD FOR SYSTEM_TIME (StartTime, EndTime)

GO

 

ALTER TABLE [msdb].[dbo].[sysjobhistory]

ADD CONSTRAINT PK_sysjobhistory PRIMARY KEY (instance_id, job_id, step_id)

GO

 

ALTER TABLE [msdb].[dbo].[sysjobhistory]

SET(SYSTEM_VERSIONING = ON (HISTORY_TABLE = [dbo].[sysjobhistoryall], DATA_CONSISTENCY_CHECK = ON, HISTORY_RETENTION_PERIOD = 1 MONTH))

GO

 

스크립트를 살펴보면 PK_sysjobhistory라는 기본 키가jobhistory 테이블에 추가되고 변경사항을  추적하는데 필요한 개의 열을 추가한 것을 있다. 작업이 완료되었으면 Managed Instance 기록 정리 작업을 실행하면 변경 사항이 보존되는지 여부를 테스트 있다. 아래 스크립트르 차례로 실행하여 시뮬레이션 있다.

EXEC msdb.dbo.sp_purge_jobhistory

 

기존 sysjobhistory 테이블에서 작업 기록이 삭제되면 sysjobhistoryall 테이블에서 삭제된 작업 기록 확인할 있다.

select * from msdb.dbo.sysjobhistoryall

 

 

 

2018-10-08 / Sungwook Kang / http://sqlmvp.kr

 

Azure SQL, Managed Instance, Azure SQL Agent, jobhistory, sysjobhistory, SQL Agent

Azure VM에서 SQL Server 대한 저장소 구성 지침

 

·         Version : Azure VM

 

Azure Virtual Machines 에서 SQL Server 사용할 경우 VM SQL Server 완벽하게 제어하고 SQL Server 작업 부하를 위한 가장 간단한 클라우드 마이그레이션 경로를 제공한다.

·         SQL Server on Virtual Machines :  https://azure.microsoft.com/en-us/services/virtual-machines/sql-server/

 

SQL IaaS Extension 기본적으로 Azure Market Place 통해 생성된 SQL VM 설치 된다. SQL IaaS Extension 백업 관리, 자동 보안 패치, 연결 구성, AKV 통합 최적화된 스토리지 구성 기능을 제공한다. Azure Market SQL Server 이미지는 작업 부하 유형에 따라 SQL Server 팀이 성능에 맞춰 조절한다. 그러나 SQL Server 업무상 중요한 서비스를 하는 경우 최적의 저장소 구성은 특정 작업 부하의 I/O 특성 요구 사항에 따라 다르다. 이번 포스트는 Azure IaaS에서 수행된 테스트를 기반으로 SQL Server 팀의 지침을 설명한다.

 

[프리미엄 저장소 적절한 크기의 VM 선택]

프리미엄 스토리지는 낮은 대기 시간과 일관된 높은 I/O 성능을 제공하도록 설계되었다. 캐시되지 않은 읽기는 평균 4ms 대기 시간으로 작동하고 캐시되지 않은 쓰기는 VM 평균 2ms 대기 시간 최대 80,000 IOPS 작동한다. 또한 예측할 없는 작업에서도 호스트의 SSD 기반 BLOB 캐시 기술은 대기 시간이 1ms 미만이며 최대 160,000 IOPS 제공한다. 따라서 일관된 I/O 성능과 높은 성능으로 인해 Azure VM에서 SQL Server 서비스는 프리미엄 스토리지를 사용할 것을 권장한다.

프리미엄 스토리지는VM 따라IOPS, 대역폭 연결할 있는 디스크 수에 대한 크기 제한 성능 사양이 있다. 예를 들어 표준 DS14_v2 VM크기는 64개의 프리미엄 디스크를 사용하여 최대 51,200 IOPS또는 768MBps 디스크 처리량을 제공하며 로컬 SSD 576GB BLOB 캐시를 사용하여 최대 64,000 IOPS또는 512MBps 처리량을 제공한다. 아래 링크에서 모든 VM 크기에 할당된 제한 리소스를 확인할 있다.

·         Memory optimized virtual machine sizes : https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes-memory

 

[읽기가 많은 작업 경우 읽기 전용 캐시를 사용하여 처리량을 향상]

프리미엄 스토리지를 지원하는 Azure VM 캐싱을 위해 가상 시스템 RAM 로컬SSD 조합을 사용하는 다중 계층 캐싱 기술을 사용한다. SQL 서버 작업 부하를 가져오는 읽기 전용 캐시 이득은 작업량 특성에 따라 다르다.

아래의 테스트 결과는  10-P30 디스크가 장착된 DS14_v2 VM에서 최대 50,000 IOPS 사용하는 OLTP 작업 부하로 테스트했다. 데이터 로그 파일은 테스트를 위해 10-P30 디스크에서 동일한 저장 영역 풀에 있다.

읽기 80%, 쓰기 20%, 약간의 tempdb 사용하는 OLTP 작업 부하의 경우 캐시가 없는 동일한 구성에 비해 모든 프리미엄 디스크에 대해 읽기 전용 캐시가 활성화 되었을 처리량이 42% 증가했다. 읽기 50%, 쓰기 50%, 약간의 tempdb 사용하는 OLTP 작업 부하의 경우 캐시가 없는 구성에 비해 읽기 전용 캐시의 처리량이 25% 증가했다.

 

[데이터 로그 파일의 분리]

데이터 로그 파일을 분리한 별도의 저장 영역을 사용하여 읽기 전용 캐시의 이득을 최적화 하는 것이 좋다. 캐시가 없는 프리미엄 스토리지 디스크에 로그파일을 호스팅 하면 읽기 작업에 대해서는 호스트 BLOB 캐시의 사용 가능한 공간과 처리량이 절약되어 이점을 극대화 한다. 특히  SQL Server 데이터 파일을 호스팅하는 저장소에 포함될 프리미엄 저장소 디스크에는 읽기 전용 캐시를 사용하는 것이 좋다. 예를 들어 데이터 파일에 IOPS 요구사항이 30,000 이라면 모든 디스크에 RO 캐시를 활성화 6 - P30 디스크 또는 4 - P50 디스크를 스트라이핑 하는것이 좋다.

 

로그 파일을 호스팅 하는 저장소에 포함될 프리미엄 저장소 디스크는 읽기전용 캐시를 구성하지 않는것이 좋다. 또한 로그 파일의 디스크 처리량 요구 사항이 7500 IOPS 미만인 경우 단일 P50 디스크로 IOPS 달성할 있으므로 로그 파일에 대한 저장소 풀이 필요하지 않다. 특히 작은 호스트 BLOB 캐시가 있는 VM에서SQL Server 작업의 부하가 경우 로그 파일과 데이터 파일을  분리하였을때 테스트에서 상당한 처리량 증가를 보였다. 평균적인 예로 데이터를 호스팅하는것과 비교하여 RO 캐시가 있는 별도의 스토리지 풀에서 호스트되는 캐시 데이터 파일이 없는 스토리지 풀에서 로그 파일을 호스팅할  쓰기 50% 비율의 OLTP 테스트 경우 처리량이 35%  증가했다.  

 

[올바른 크기의 VM 선택  로컬 SSD tempdb 배치]

VM 크기에 따라 로컬 SSD BLOB 캐시에 대해 최대 대역폭, 최대 처리량 크기 제한이 가능한 스토리지 용량을 정의한다. Tempdb 사용량이 높은 업무용 SQL Server 경우 로컬 SSD temp db 호스팅하면 작업 부하 성능과 처리량에 영향을 준다. VM 로컬 SSD 대한 크기, 처리량 대역폭 제한이 tempdb IO 요구 사항을 허용해야 한다. 그리고  VM 호스트 BLOB 캐시 스케일 한계는 로컬 SSD 읽기 호스트 BLOB 캐시 읽기가 발생하는 읽기 활동을 허용할 만큼 충분히 커야 한다.

최대 로컬 디스크 + SSD 캐시 성능한계는 로컬 SSD 읽기 쓰기 작업 SSD 캐시의 읽기 작업에 대한 최대 작업을 정의한다. tempdb 로컬 SSD 디스크에 배치되고 SQL Server 데이터 파일을 호스팅하는 프리미엄 디스크에 RO 캐시가 사용되는 경우 tempdb에서 구동되는 읽기 + 쓰기 IOPS RO 캐시의 읽기 IOPS 공유된다. 예를들어 표준 DS14_v2 임시 디스크의 크기가 224GB이고 호스트 캐시가 576GB이며 로컬 캐시의 tempdb 활동과 함께 읽기 캐시에 사용할 있는 최대 처리량은 64,000 IOPS 524MB/s이다.

 

Storage Optimized L-Series 또는 Memory Optimized M-Series 로컬 SSD 최대 14TB이고 메모리가 최대 4TB 이다. 이러한 서버는 고부하의 SQL Server 작업을 처리하는데 가장 적합하다. 적절한 VM 크기 선택 구성으로 Azure VM SQL Server 작업 부하에 대해 미션 크리티컬 성능을 얻을 있다.

 

[참고자료]

https://blogs.msdn.microsoft.com/sqlserverstorageengine/2018/09/25/storage-configuration-guidelines-for-sql-server-on-azure-vm/

 

 

2018-10-02 / Sungwook Kang / http://sqlmvp.kr

 

Azure SQL, Azure VM, BLOB Storage, local SSD, local cache, SQL Server On Azure VM, SQL Server on Azure

Azure SQL 도입된 새로운 집계 함수 APPROX_COUNT_DISTINCT

 

·         Version : Azure SQL

 

다양한 서비스를 운영하다보면 서비스에 따른 중요 포인트가 조금씩 다른 경우가 있다. 예를들어 정확한 숫자(결과값) 중요시하는 서비스(일일 매출, 재고량 ) 있으며, 빠른 응답을  (실시간 데이터 사용량, DB 전체 데이터 ROW 등의 대시보드 ) 중요시하는 서비스가 있다. 물론 응답성을 중시한다고 해서 데이터가 틀리면 안되겠지만 허용되는 오차범위에서 최대한 빠른 응답이 필요할 때가 있다.  이번 포스트에서는 매우 데이터 세트 전체에 대한 집계에 대해 빠른 응답을 수있는 Azure SQL APPROX_COUNT_DISTINCT 대해서 다루어 본다.

 

Azure SQL 새로운 집계함수인 APPROX_COUNT_DISTINCT NULL 아닌 고유한 값이 있는 그룹의 대략적인 수를 반환한다. 함수는 데이터 시나리오에 사용하도록 설계되었으며 아래 조건에 최적화 되어 있다.

·         수백만행 이상의 데이터 세트에 대한 액세스

·         많은 수의 고유한 값을 가진 열의 집계

이러한 조건을 가정하면 대부분의 작업에서 정확도 오차는 2%이내가 된다. 또한  APPROX_COUNT_DISTINCT 정확도 오차는 COUNT DISTINCT에서 20%이상 되어서는 안된다.

 

APPROX_COUNT_DISTINCT 고유 카운트를 계산할때, COUNT DISTINCT 보다 훨씬 적은 메모리를 사용한다. 이러한 이유 때문에 데이터 집합에 수십억개의 행이 있더라도 디스크를 사용하지  않고 메모리에서 계산을 수행할 가능성이 훨씬 크다. 일반적으로 COUNT DISTINCT 경우 메모리가 부족하면 tempdb 사용하므로 성능 저하를 초래(일반적으로 디스크가 가장 느리기 때문)한다.  APPROX_COUNT_DISTINCT tempdb 사용하지 않고 내부적 알고리즘을 사용하므로 결과적으로 APPROX_COUNT_DISTINCT COUNT DISTINCT보다 훨씬 빠르게 실행된다.

 

아래 그림은 일반적인 COUNT(DISTINCT ()) 사용한 것과 APPROX_COUNT_DISTINCT 사용한 경우이다.

[DISTINCT COUNT]

 


[APPROX_COUNT_DISTINCT]

 


COUNT DISTINCT 경우 정렬 연산자가 추가되어 있으므며 APPROX_COUNT_DISTINCT 경우 Hash match 대한 Stream Aggregate 대체 된다는 것을 있다. 또한 계획은 모두 동일한 클러스터된 인덱스 검색을 사용하며 COUNT DISTINCT 경우 검색에 95% 비용을 사용하지만, APPROX_COUNT_DISTINCT 경우99% 검색에 사용되는 것을 있다. 뜻은 전통적인 COUNT DISTINCT 작업은 외부의 스캔 처리 작업이 많다는 것을 의미한다.

 

APPROX_COUNT_DISTINCT 사용할 경우 실행 계획에 아래와 같은 연산자를 확인할 있다.

<ScalarOperator ScalarString=”APPROX_COUNT_DISTINCT_CONVERT([globalagg1004])”>

 

 

[참고자료]

https://blogs.msdn.microsoft.com/sqlserverstorageengine/2018/07/16/approximate-count-distinct-enters-public-preview-in-azure-sql-database/

 

 

2018-09-10 / Sungwook Kang / http://sqlmvp.kr

 

Azure SQL,  count distinct, APPROX_COUNT_DISTINCT

Azure SQL 데이터베이스 소유권 체인

 

·         Version : Azure SQL

 

Azure SQL Database Managed Instance에서는 SQL Server 동일한 방식으로 데이터베이스간 쿼리를 실행할 있다. 또한 데이터베이스간 소유권 체인을 지원한다. 이번 포스트에서는 Managed Instance 소유권 체인에 대해서 다루어 본다.

 

데이터베이스간의 소유권 체인을 사용하면 명시적 권한이 객체에 부여되지 않더라도SQL 인스턴스의 다른 데이터베이스에 있는 객체에 액세스 있다. DB_CHAINING옵션이 데이터베이스에서 설정되어 있는 경우 동일한 소유자로 다른 데이터베이스에 액세스할 있다.  

DB_CHAINING is disabled by default on new databases because you need to be aware what it exactly do and does it violates some security policy in your system before you explicitly enable it.

 

DB_CHAINING 시스템의 일부 보안 정책을 위반하므로 기본적으로 비활성화 되어있다.

 

여러 데이터베이스의 여러 오브젝트에서 동일한 소유자가 있고 오브젝트에 액세스하는 스토어드 프로시저가 있는 경우 프로시저가 액세스해야하는 모든 오브젝트에 대한 액세스 권한을 GRANT 필요가 없다. 프로시저와 오브젝트의 소유자가 동일한 경우 프로시저에 대한 GRANT 권한을 부여할 있으며 데이터베이스 엔진은 프로시저가 동일한 소유자를 공유하는 다른 모든 개체에 액세스 있게 한다.

아래 예제에서는 데이터에 액세스하는데 사용되는 동일한 소유자 로그인이 있는 개의 데이터베이스를 생성한다. PrimaryDatabase DataTable 이라는 테이블을 가지고 있으며,  SecondaryDatabase PrimaryDatabase DataTable 에서 데이터를 읽는 저장프로시저를 갖는다. 저장 프로시저를 실행하기 위해 로그인이 부여되었지만 테이블 데이터를 읽지는 못하였다.

-- Create two databases and a login that will call procedure in one database

CREATE DATABASE PrimaryDatabase;

GO

CREATE DATABASE SecondaryDatabase;

GO

CREATE LOGIN TheLogin WITH PASSWORD = 'Very strong password!'

GO

 

-- Create one database with some data table,

-- and another database with a procedure that access the data table.

USE PrimaryDatabase;

GO

CREATE PROC dbo.AccessDataTable

AS

BEGIN

SELECT COUNT(*) FROM SecondaryDatabase.dbo.DataTable;

END;

GO

CREATE USER TheUser FOR LOGIN TheLogin;

GO

GRANT EXECUTE ON dbo.AccessDataTable TO TheUser;

GO

 

USE SecondaryDatabase;

GO

SELECT * INTO dbo.DataTable FROM sys.objects;

GO

CREATE USER TheUser FOR LOGIN TheLogin;

GO

 

저장 프로시저를 사용하여 데이터를 읽으려고 하면 로그인에 테이블에 대한 GRANT 권한이 없기 때문에 오류가 발생한다.

EXECUTE('SELECT * FROM SecondaryDatabase.dbo.DataTable') AS LOGIN = 'TheLogin' ;

GO

-- Msg 229, Level 14, State 5, Line 34

-- The SELECT permission was denied on the object 'DataTable', database 'SecondaryDatabase', schema 'dbo'.

 

저장 프로시저를 사용하여 테이블에서 데이터를 읽으려고 하는 경우에도 동일한 문제가 발생한다.

EXECUTE('EXEC PrimaryDatabase.dbo.AccessDataTable') AS LOGIN = 'TheLogin' ;

GO

--Msg 229, Level 14, State 5, Procedure dbo.AccessDataTable, Line 5 [Batch Start Line 65]

--The SELECT permission was denied on the object 'DataTable', database 'SecondaryDatabase', schema 'dbo'.

 

사용자에게 프로시저를 실행할 있는 권한은 있지만 데이터베이스 엔진은 해당 로그인에 대해 SecondaryDatabase 테이블에서 읽을 있는 액세스 권한이 없으므로 쿼리를 차단한다. 아래 스크립트는 데이터베이스 소유권 체인을 활성화 한다.

ALTER DATABASE PrimaryDatabase SET DB_CHAINING ON;

GO

ALTER DATABASE SecondaryDatabase SET DB_CHAINING ON;

GO

 

저장 프로시저를 통해 테이블에 다시 액세스하면 결과가 표시된다.

EXECUTE('EXEC PrimaryDatabase.dbo.AccessDataTable') AS LOGIN = 'TheLogin' ;

 

Managed Instance / Database Engine 저장 프로시저와 테이블이 동일한 소유자를 가지며 DB_CHAINING 켜져있기 때문에 테이블에 대한 액세스를 허용한다. 그러나 해당 로그인에 대해 직접적인 테이블에 액세스하는 권한은 없으므로 직접 테이블에 액세스 수는 없다.

EXECUTE('SELECT * FROM SecondaryDatabase.dbo.DataTable') AS LOGIN = 'TheLogin' ;

GO

--Msg 229, Level 14, State 5, Line 54

--The SELECT permission was denied on the object 'DataTable', database 'SecondaryDatabase', schema 'dbo'.

 

데이터베이스 소유권 체인이 유용할 뿐만 아니라 보안 관점에서 예기치 않은 동작이 발생할 있으므로 해당 옵션을 활성화 할때는 신중함이 필요하다.

 

[참고자료]

https://blogs.msdn.microsoft.com/sqlserverstorageengine/2018/08/17/database-ownership-chaining-in-azure-sql-managed-instance/

 

 

 

2018-09-06 / Sungwook Kang / http://sqlmvp.kr

 

Azure SQL,  Managed Instance, SQL, Azure SQL Database, SQL Server Security, DB_CHAINING


Azure SQL 내부 디스크 할당 방법   저장 가능 용량 확인

 

·         Version : Azure SQL

 

Azure SQL Database Managed Instance 모든 데이터베이스 파일을 Azure Storage 보관하는 Azure Cloud SQL Server 서비스 이다. 이번 포스트에서는 Managed Instance 스토리지 계층에 디스크를 할당하는 방법과 최대 사용한 가능한 디스크 공간을 확인하는 방법에 대해서 살펴본다.

 

 Azure SQL Database Managed Instance 일반적인 목적의  스토리지 계층과 데이터베이스 파일이 위치하는 Azure Premium 스토리지 계층을 가지고 있다. Managed Instance 모든 파일에 대해 미리 정의된 크기의 Azure disk(128GB, 256GB, 512GB ) 사용한다. 모든 파일은 현재 파일의 크기를 포함할 있는 가장 작은 단일 디스크에 저장된다. 이는 모든 Managed Instance 최대 35TB 내부 저장장치를 가지고 있기 때문에 중요하다. Managed Instance 프로비저닝하면 가지 스토리지 제한이 있다.

1.       Managed Instance 사용자 저장소는 사용자가 포털에서 선택한 managed instance 저장소 이며 저장소 크기에 따라 비용을 지불한다.

2.       Azure Premium disk 내부에서 물리적으로 공간을 할당할 35TB 초과 없다. 결과적으로 GP 인스턴스에서  가장 작은 디스크(128GB) 위치한 280개의 파일이 35TB 한도에 도달하므로 GP인스턴스에 280 넘는 파을을 저장할 없다.

 

데이터베이스 파일을 만들때,  Azure Premium Disk 사용하는데 파일크기가 경우 파일의 내부 조각화가 발생할 있다. Azure Premium Disk 고정된 디스크 크기 집합을 제공하므로 Managed Instance 데이터베이스 파일을 일치하는 디스크에 저장하도록 구현된다. 할당된 디스크 크기의 합은 35TB 초과할 없다. 만약 한계에 도달하면 에러가 발생할 있다. 아래 스크립트는 저장용량 한도에 도달했는지 확인할 있다.  sys.master_files뷰를 래핑하고 모든 파일에 할당된 디스크 크기를 반환하는 표준 스키마뷰를 만든다.

CREATE SCHEMA mi;

GO

CREATE OR ALTER VIEW mi.master_files

AS

WITH mi_master_files AS

( SELECT *, size_gb = CAST(size * 8. / 1024 / 1024 AS decimal(12,4))

FROM sys.master_files )

SELECT *, azure_disk_size_gb = IIF(

database_id <> 2,

CASE WHEN size_gb <= 128 THEN 128

WHEN size_gb > 128 AND size_gb <= 256 THEN 256

WHEN size_gb > 256 AND size_gb <= 512 THEN 512

WHEN size_gb > 512 AND size_gb <= 1024 THEN 1024

WHEN size_gb > 1024 AND size_gb <= 2048 THEN 2048

WHEN size_gb > 2048 AND size_gb <= 4096 THEN 4096

ELSE 8192

END, NULL)

FROM mi_master_files;

GO

 

이제 Azure Premium disk 할당된 모든 데이터베이스 파일에 대한 크기를 있다.

SELECT db = db_name(database_id), name, size_gb, azure_disk_size_gb

from mi.master_files;

 

Azure disk 크기의 합은 35TB 초과해서는 안된다. 그렇지 않으면 Azure disk 오류가 발생한다. 다음 쿼리를 사용하여 할당된 저장 공간을 확인할 있다.

SELECT storage_size_tb = SUM(azure_disk_size_gb) /1024.

FROM mi.master_files

 

아래 스크립트는 새로운 파일이 128GB보다 작은것으로 가정하고 Managed Instance 추가할 있는 파일 수를 확인한다. 결과값이 0 경우 (또는 0 근사할 수록) 파일을 할당할 없으므로 새로운 계획이 필요 하다.

SELECT remaining_number_of_128gb_files =

(35 - ROUND(SUM(azure_disk_size_gb) /1024,0)) * 8

FROM mi.master_files

 

 

[참고자료]

https://blogs.msdn.microsoft.com/sqlserverstorageengine/2018/08/20/reaching-azure-disk-storage-limit-on-general-purpose-azure-sql-database-managed-instance/

 

 

2018-09-05 / Sungwook Kang / http://sqlmvp.kr

 

Azure SQL,  Managed Instance, SQL, Azure disk, database file. Azure storage

Azure SQL에서 이메일 보내기

 

·         Version : Azure SQL

 

Azure SQL Database Managed Instance Azure 클라우드에서 대부분의 SQL Server 기능을 사용할 있다. 이번 포스트에서는 Managed Instance에서 메일 프로필을 설정하고 이메일을 보내는 방법에 대해서 알아본다.

 

먼저 이메일 서버에 액세스하는데 필요한 로그인/암호 정보와 함께 실제 이메일을 보낼 전자 메일 서버의 주소가 포함된 이메일 계정 정보를 설정한다. 아래 스크립트를 참고하여 설정을 사용자에게 맞게 변경 실행 한다.

-- Create a Database Mail account

EXECUTE msdb.dbo.sysmail_add_account_sp

    @account_name = '...',

    @description = '...',

    @email_address = '$(loginEmail)',

    @display_name = '...',

    @mailserver_name = '$(mailserver)' ,

    @username = '$(loginEmail)' , 

    @password = '$(password)'

 

-- Create a Database Mail profile

EXECUTE msdb.dbo.sysmail_add_profile_sp

    @profile_name = 'AzureManagedInstance_dbmail_profile',

    @description = '...' ;

 

-- Add the account to the profile

EXECUTE msdb.dbo.sysmail_add_profileaccount_sp

    @profile_name = 'AzureManagedInstance_dbmail_profile',

    @account_name = '...',

    @sequence_number = 1;

 

여기서 중요한것은 하나의 이메일 프로필만 만들 있으며 프로필명은 반드시 AzureManagedInstance_dbmail_Profile 이라고 해야 한다. 이렇게 하지 않으면 Managed Instance 프로필을 사용하여 이메일을 보낼 없다.

 

이메일 서버 설정이 완료되었으면 sp_configure에서 Database Mail XPs 옵션을 활성화 한다.

EXEC sp_configure 'show advanced options', 1; 

GO 

RECONFIGURE; 

GO 

EXEC sp_configure 'Database Mail XPs', 1; 

GO 

RECONFIGURE 

GO

 

이제 sp_send_dbmail sp_notify_operator 프로시저를 사용하여 전자 메일을 보내 구성을 테스트할 있다. 전자 메일을 보내는 방법은 아래 스크립트를 참고 한다.

DECLARE @body VARCHAR(4000) = 'The email is sent with msdb.dbo.sp_send_dbmail from ' + @@SERVERNAME;

EXEC msdb.dbo.sp_send_dbmail

        @profile_name = 'AzureManagedInstance_dbmail_profile',

        @recipients = '$(email)',

        @body = @body,

        @subject = 'Azure SQL Instance - test email' ;

 

운영자에게 이메일을 보내기 위해서는 운영자 정보를 추가해야 한다. 아래 스크립트를 참고하여 운영자 이메일을 설정하여 그룹을 생성한다.

EXEC msdb.dbo.sp_add_operator

          @name = N'SQL DevOp',

          @enabled = 1,

          @email_address = N'$(email)',

          @weekday_pager_start_time = 080000,

          @weekday_pager_end_time = 170000,

          @pager_days = 62 ;

 

운영자 등록이 완료되었으며 아래 스크립트를 참고하여 설정이 정상적으로 되었는지 운영자에게 이메일 알림을 전송해본다.

DECLARE @body VARCHAR(4000) = 'The email is sent using sp_notify_operator from ' + @@SERVERNAME;

EXEC msdb.dbo.sp_notify_operator

              @profile_name = N'AzureManagedInstance_dbmail_profile',

              @name = N'SQL DevOp',

              @subject = N'Azure SQL Instance - Test Notification',

              @body = @body;

 

아래 예시는 Managed Instance에서 작업이 성공하거나 실패할 이메을 통해 운영자에게 알릴 있다.

EXEC msdb.dbo.sp_update_job

              @job_name=N'My job name',

              @notify_level_email=2,

              @notify_level_page=2,

              @notify_email_operator_name=N'SQL DevOp'

 

 

[참고자료]

https://blogs.msdn.microsoft.com/sqlserverstorageengine/2018/08/31/sending-emails-in-azure-sql-managed-instance/

 

 

2018-09-04 / Sungwook Kang / http://sqlmvp.kr

 

Azure SQL,  Managed Instance, SQL, database mail, XPs Mail, sp_send_dbmail, sp_notify_operator


Azure SQL에서 읽기 전용 복제본에 대한 접속 링크 서버 생성

 

·         Version : Azure SQL

 

Azure SQL Database Managed Instance Azure 클라우드에서 호스트 되는 완벽하게 관리되는 SQL Server 데이터베이스 엔진으로 Azure SQL Pass SQL Server 기능(: 링크된 서버 기본 제공되는 무료 보조 읽기 전용 복제본) 제공한다. 이번 포스트에서는 연결된 서버(링크드 서버) 사용하여 읽을 있는 보조 복제본을 연결하는 방법을 살펴 본다.

 

Managed Instance Business Critical Tier 모든 데이터베이스에 대해서 리포트 목적의 용도로 사용할 있는 읽기 전용 상태의 무료 읽기 전용 복제본을 제공한다. 아래 그림에는 하나의 기본 인스턴스와   개의 읽기 전용 서버로 구성된다. 서버는 읽기 전용 끝점을 이용해서 연결된다.


어플리케이션에서 보조 복제본에 접속하는 방법은 기본 인스턴스에 액세스하는 사용하는 것과 동일한 연결 문자열을 사용한다. 다만 연결 문자열에ApplicationIntent=ReadOnly 추가하면 된다.

기본 인스턴스에서 보조 인스턴스로 연결된 서버를 만드는 경우 T-SQL 사용하여 기본 인스턴스에서 보조 인스턴스로 연결할 있다. 아래 스크립트는 보조 복제본에 연결된 서버를 만든다.

EXEC sp_addlinkedserver

@server=N'SECONDARY',

@srvproduct=N'',

@provider=N'SQLNCLI',

@provstr = N'ApplicationIntent=ReadOnly',

@datasrc= @@SERVERNAME;

 

@@SERVERNAME Managed Instance 정규화된 도메인 이름을 반환하고 동일한 이름은 보조 인스턴스에 액세스하는데 사용된다. 추가해야하는 유일한 것은 공급자 문자열에서 ApplicationIntent=ReadOnly 이다

 

읽기 보조 복제본 서버로 연결된 서버를 생성하면 T-SQL 사용하여 읽기 전용 인스턴스를 쿼리 있다. 예를 들어 아래 쿼리를 사용하여 보조 데이터베이스가 읽기 전용인지 확인할 있다.

SELECT *

FROM OPENQUERY([SECONDARY],

'SELECT DATABASEPROPERTYEX (''master'', ''Updateability'' ) ')

 

또한 4 part name 구문을 사용하여 Secondary 서버의 테이블이나 뷰를 쿼리할 있다.

SELECT *

FROM SECONDARY.master.sys.databases;

 

 

[참고자료]

https://blogs.msdn.microsoft.com/sqlserverstorageengine/2018/08/27/create-linked-server-to-readable-secondary-replica-in-managed-instance-business-critical-service-tier/

 

 

 

2018-08-30 / Sungwook Kang / http://sqlmvp.kr

 

Azure SQL,  Managed Instance, SQL, read only, High Availability, Linked server, Read-only replica

Azure SQL에서 네트워크를 구성하는 방법

 

·         Version : Azure SQL

 

Azure SQL Managed Instance Azure 클라우드에서 호스팅되고 Azure 가상 네트워크를 사용하는 완전히 관리되는 SQL Server 인스턴스이다. Managed Instance 가상 네트워크를 사용하기 때문에  Azure 관리 서비스에서 사용자가 네트워크 액세스 규칙을 정의할 있다. 잘못된 네트워크 구성은  Managed Instance  배포할때  오류가 발생하므로 아래 순서에 따라서 네트워크 환경을 구성하여 사용한다. 일반적으로 인스턴스용 가상 네트워크를 구성할 기본 5가지 단계로 정리할 있다.

1.       Managed Instance 사용할 가상 네트워크를 구성

2.       Managed Instance Azure 관리 서비스와 통신할 있도록Route 테이블 생성

3.       가상 네트워크 생성시 생성된 기본 서브넷을 사용하거나Managed Instance 전용 서브넷을생성

4.       서브넷에 Route 테이블 할당

5.       4단계 까지 올바르게 구성되었는지 확인

 

[1. 가성 네트워크 구성]

Managed Instance 사설 IP주소가 할당된 Azure Virtual network 사용한다. 가상 네트워크는 Managed Instance 만들기 전에 생성해야 한다. 가상 네트워크는 Azure Portal, PowerShell, Azure CLI등을 이용하여 생성할 있다. Azure Portal 사용하여 가상 네트워크를 생성할때 Resource Manager 배포 모델을 사용해야 한다. 클래식 가상 네트워크 모델은 지원되지 않는다. 가상 네트워크를 생성할 Virtual Network Blade Service Endpoint 옵션이 Disable 설정되어 생성 되는데 는기본 옵션이므로 변경하지 않는 것을 권장한다.

 

Managed Instance 서브넷은 16 ~ 256개의 주소를 사용할 있다. 따라서 기본 서브넷의IP범위를 정의할 서브넷 마스크 /28 - /24 범위를 사용한다. 많은 인스턴스가 있을 경우 기본 서브넷에 (인스턴스 X 2) + 5개의 주소가 있는지 확인한다.

 

[2. Route 테이블 생성]

가성 네트워크 생성이 완료 되었으면 Managed Instance Azure 관리 서비스와 통신할 있도록 Route 테이블을 구성해야한다. Route 테이블은 Managed Instance 배포된 서브넷에 연결되며 서브넷을 통해서 나가는 패킷은 연결된 Route 테이블 기반으로 처리된다. 서브넷은 단일 Route 테이블에만 연결할 있다. (Azure에서 Route 테이블을 만드는데는 비용이 부과 되지 않는다.)

Azure Portal에서 ‘Route table’이라는 리소스를 추가하고 Route 규칙에 “0.0.0.0/0 Next Hop Internet” 경로를 추가한다. 경로를 사용하면 가상 네트워크에 있는 Managed Instance 인스턴스를 관리하는 Azure 관리 서비스와 통신할 있다. 이렇게 하지 않으면 Managed Instance 배포 없다.

 

[3. 추가 서브넷 생성(선택사항)]

Managed Instance 서브넷에 배포되므로 Managed Instance 배포하기 전에 서브넷을 생성해야 한다. 기본 서브넷에 인스턴스를 배포하고 기본 경로를 사용하는경우 단계를 건너 있다. 서브넷은 Managed Instance 전용이며 다른 리소스를 포함할 없다. 서브넷에는 최소한 16개의 주소가 있어야 하고 5개의 주소는 Azure 내부 서비스용으로 예약되어 있다. 서브넷에 포함되는  모든 Managed Instance 에는 인스턴스당 2개의 주소가 필요하다. 서브넷에 Managed Instance 배치하면 서브넷의 크기를 변경할 없으므로 주의한다.

 

[4.서브넷 구성]

서브넷(기본값 1 또는 신규)에는 “0.0.0.0/0 Next Hop Internet” 정보를 포함한 User Route Table(UDR) 있어야 한다. “0.0.0.0/0 Next Hop Internet” Route 테이블을 생성하면 Managed Instance 서브넷에 할당 있다. Azure Portal에서 서브넷을 정보를 확인할 있으며 아래 항목을 확인한다.

1.       서브넷에 할당된 Managed Instance Route 테이블 있다.

2.       서브넷에는 네트워크 보안그룹이 없어야 한다.

3.       서브넷에는 서비스 엔드 포인트가 없어야 한다.

4.       서브넷에는 다른 리소스가 없다.

 

[5. 체크리스트]

4단계 까지 구성이 완료 되었으면 Managed Instance 배포할때 문제가 발생하지 않도록 아래 체크리스트 항목을 확인한다.

1.       가상 네트워크에서 서비스 끝점을 사용하지 않도록 설정한다.

2.       서브넷에는 16 ~256개의 IP 주소가 있어야 한다. (Masks from /28~ /24)

3.       Managed Instance 서브넷에는 다른 리소스가 없어야 한다.

4.       서브넷에는 0.0.0.0/0 Next Hop Internet 경로가 있어야 한다.

5.       서브넷에는 보안 그룹이 없어야 한다.

6.       서브넷에는 서비스 끝점이 없어야 한다.

 

모든 구성이 완료 되었어면 Azure Portal 사용하여  새로운 Managed Instance