In-memory optimized table 사용되는 Hash Index

 

·         Version : SQL Server 2014 later

 

SQL Server에서 새롭게 추가된 Hash Index(해시 인덱스)  In-Memory optimized table(인메모리 최적화 테이블)에서 사용된다. 기본적으로 테이블의 행을 빠르게 찾고 읽으려면 인덱스가 필요하다.

해시 인덱스는 버킷의 컬렉션은 배열(Array) 구성된다. 해시 함수는 인덱스 키를 해시 인덱스의 해당 버킷으로 매핑한다. 아래 그림은 개의 인덱스가 해시 함수를 사용하여 해시 인덱스에 있는 개의 서로 다른 버킷에 매핑되는것을 나타낸다. 아래 그림에서 해시 함수 이름은 f(x)이다.

 


해시 인덱스에 사용되는 해시 함수의 특징은 아래와 같다.

·         SQL Server에는 모든 해시 인덱스에 사용되는 하나의 해시 함수가 있다.

·         해시 함수는 결정적이다. 동일한 인덱스 키는 항상 해시 인덱스의 동일한 버킷에 매핑된다.

·         여러 인덱스 키는 동일한 해시 버킷에 매핑할 있다.

·         해시 함수는 균형을 이룬다. , 해시 버킷에 대한 인덱스 키값의 분포는 일반적으로 포아송 분포를 따른다.

 

포아송 분포는 균등한 분포가 아니다. 인덱스 값은 해시 버킷에 균등하게 분포되지 않는다. 예를 들어 n개의 해시 버킷에 대한 n개의 고유인덱스 키의 포아송 분포는 버킷을 대략적으로 삼등분 한다. 삼등분된 버킷 부분에는 공백, 하나의 인덱스 , 개의 인덱스 키가 각각 포함된다. 소수의 버킷에 개이상의 키가 포함된다. 두개의 인덱스 키가 동일한 해시 버킷에 매핑되면 해시 충돌(Collision) 발생한다.  많은 숫자의 해시 충돌은 읽기 작업의 성능에 영향을 준다.

 

인메모리 해시 인덱스 구조는 메모리 포인터의 배열로 구성된다. 버킷은 배열의 오프셋에 매핑된다. 배열의 버킷은 해당 해시 버킷의 번째 행을 가리킨다. 버킷의 행은 다음 행을 가리키기 때문에 다음 그림과 같이 해시 버킷에 대한 체인이 만들어 진다. 아래 그림은 행이 포함된 개의 버킷이 있다.

 


위에서 두번째 버킷에는 개의 빨간색 행이 포함된다. 번째 버킷에는 하나의 파란색 행이 포함된다. 아래 버킷에는 개의 녹색 행이 포함된다. 이러한 행동은 동일한 행의 서로 다른 버전일 있다.

 

 

[참고자료]

https://docs.microsoft.com/en-us/sql/database-engine/hash-indexes?view=sql-server-2014

 

 

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

 

SQL Server, MSSQL, Hash Index, 해시 인덱스, 인모메리 최적화 테이블, In-memory optimized table


VM환경에서 AG 구성하였을때VSS 백업 동작 변경

 

·         Version : SQL Server 2016, SQL Server 2017

 

SQL Server 2016 Standard Edition(또는 이후 버전) 사용하여 가상 컴퓨터 (Virtual Machine) 환경에서 기본 가용성 그룹( AG) 구성하였을때 AG 보조 복제본을 호스팅하는 VM환경에서 백업이 실패한 것으로 나타날 있다. 이러한 이유는 Volume Shadow Copy Service(VSS) VM환경의 보조 복제본에서호스트되는 모든  SQL Server 데이터베이스를 일관된 방식으로 백업하기 때문이다.

·         Volume Shadow Copy Service : https://docs.microsoft.com/ko-kr/windows/desktop/VSS/about-the-volume-shadow-copy-service

기본 가용성 그룹에서는 보조 데이터베이스의 백업이 지원되지 않으므로 백업중인 데이터베이스의 하위 집합과 함께 VM 백업이 성공할 있도록 허용하지 않아 전체 VM백업이 실패한다. 이전 버전의 SQL Server에서  Database Mirroring VM에서 호스트되는 미러된 데이터베이스를 스킵하면서 VSS 백업을 완료할 있었다. SQL Server 2016 SP2 CU2 SQL Server 2017 CU9에서는 기본 AG VSS 백업의 기본 동작을 데이터베이스 미러링과 같이 변경하여 기본 AG 보조 복제본에서 호스트되는 보조 데이터베이스를 스킵한다. , VM환경에서 백업은 성공하지만 백업 당시에는 2 상태였던 데이터베이스는 포함되지 않는다.

 

SQL Writer Service SQL Server에서 VSS백업을 수행하는 서비스이다. 서비스는 SQL Server엔진과 별개이며 다른 버전의 SQL Server에서 공유된다.

·         SQL Writer Service : https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/sql-writer-service?view=sql-server-2017

동일한 서버 또는 VM SQL Server인스턴스가 여러 설치되어있는 경우 이러한 인스턴스는 모두 SQL Writer Service 동일한 인스턴스를 공유한다. 동일한 서비스가 버전간에 공유되더라도 SQL Server버전과 함께 제공되는 파일에는 함께 제공되는 인스턴스와 동일한 버전 번호가 표시된다. SQL Server 2016 SP2 CU2 서버에 적용하면 새로운 기능을 갖춘 SQL Writer Service 제공되지만 이후에 해당 인스턴스를 SQL Server 2017RTM으로 업그레이드 하거나 SQL Server 2017 별도 인스턴스를 설치하는 경우 RTM 동일한 서버에 설치하면 새로운 SQL Writer Service 바이너리는 버전 번호를 갖기 때문에 이전 버전으로 바뀐다. 때문에 SQL Server 2016 SP2 CU2 패치된 시스템에 SQL Server 2017인스턴스를 업그레이드 하거나 설치하는 경우 최신 CU 적옹해야 한다.

 

[참고자료]

https://blogs.msdn.microsoft.com/sql_server_team/behavior-change-for-vss-backups-on-vms-with-basic-availability-groups/

 

 

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

 

SQL Server, MSSQL, AlwaysOn,가용성 그룹, SQL 가용성 그룹, 가용성 그룹 백업, VSS, Volume Shadow Copy Service, SQL Writer Service

SQL Server 2016 향상된 가용성 그룹데이터베이스 수준의 상태 탐지 장애조치

 

·         Version : SQL Server 2016, SQL Server 2017

 

SQL Server2016에서 도입된 가용성 그룹(Availability Group) 대한 데이터베이스 수준 상태 탐지 장애 조치 (Database Level Failover) 옵션은 가용성 그룹에 있는 하나 이상의 데이터베이스에 문제가 있을 경우 가용성 그룹에 장애 조치 메커니즘을 실행시키기 위해 도입되었다. 기능을 사용하면 데이터베이스의 고가용성을 보장할 있으며 업무상 중요한 데이터베이스가 있는 모든 가용성 그룹에 권장되는 최상의 방법이다.

데이터베이스 수준 상태 탐지 장애조치의 초기 구현에서는 가용성 그룹의 복제본에서 다음 조건을 검사 하도록 설계 되었다.

·         DB Status 온라인 상태인가?

·         데이터베이스의 트랜잭션 로그 파일에 트랜잭션 쓰기를 사용할 있는가?

조건중 하나라도 true 아닌 경우 데이터베이스를 호스팅하는 가용성 그룹은 사용 가능한 동기(동기화) 보조 노드 하나에 장애조치가 된다.

 

과거에는 사용자가 하드웨어 문제 때문에 발생하는 오류와 같은 추가 검사를 진행하였으나 최신 서비스 릴리즈에서는 데이터베이스 수준의 상태 확인 검사의 일부로 포함될수 있다. SQL Server 최신 서비스 릴리스는 아래 링크를 참고한다.

·         SQL2017RTM CU9

 https://support.microsoft.com/en-us/help/4341265/cumulative-update-9-for-sql-server-2017

·         SQL2016SP1 CU10

 https://support.microsoft.com/en-us/help/4341569/cumulative-update-10-for-sql-server-2016-sp1

·         SQL2016SP2 CU2

 https://support.microsoft.com/en-us/help/4340355/cumulative-update-2-for-sql-server-2016-sp2

 

만약 릴리즈 적용이후 이전 상태로 되돌릴경우 사용자는 TF9576 시작 매개변수로 사용하거나 DBCC TRACEON 명령을 사용한다. 글을 쓰는 현재 시점에는 윈도우에서만 가능하지만 추후 Linux 버전의  SQL Server 2017에도 적용될 예정이다.

 

기존 검사외에 새로운 구현에는 다음과 같은 추가 검사가 있다.

1.       데이터베이스 상태 정보를  스냅샷으로 저장하고 사용하여 AG 오류 상태로 표시되어야 하는지 여부를 결정한다. 상태 검사 루틴은 데이터베이스 상태 관련 오류 정보를 마지막 번의 실행 결과를 캐시한 다음 현재 상태 검사 루틴의 실행 상태 정보와 비교한다. 상태 탐지 루틴의 번의 연속 실행중에 동일한 오류 조건(아래 언급된 오류코드) 존재하면 장애조치가 시작된다.

2.       아래 목록의 추가 오류를 확인한다. 이러한 오류의 대부분은 서버의 하드웨어 문제를 나타낸다. 아래 목록이 데이터베이스 가용성에 영향을 있는 모든 오류 목록은 아니다.

Error

Cause

Documentation

605

페이지 또는 할당 손상

https://docs.microsoft.com/en-us/sql/relational-databases/errors-events/mssqlserver-605-database-engine-error?view=sql-server-2017

823

검사점 실패

https://docs.microsoft.com/en-us/sql/relational-databases/errors-events/mssqlserver-823-database-engine-error?view=sql-server-2017

829

디스크 손상

 

832

하드웨어 또는 메모리 손상

 

1101

파일 그룹에 사용가능한 디스크 공간 부족

https://docs.microsoft.com/en-us/sql/relational-databases/errors-events/mssqlserver-1101-database-engine-error?view=sql-server-2017

1105

파일 그룹에 사용 가능한 디스크 공간부족

https://docs.microsoft.com/en-us/sql/relational-databases/errors-events/mssqlserver-1105-database-engine-error?view=sql-server-2017

5102

누락된 파일 그룹 ID 요청

 

5108

잘못된 파일 ID 요청

 

5515

 

https://docs.microsoft.com/en-us/sql/relational-databases/errors-events/mssqlserver-5515-database-engine-error?view=sql-server-2017

5534

FILESTREAM 작업 로그 레코드로 인해 로그가 손상됨

 

5535

FILESTREAM 데이터 컨테이너가 손상됨

 

9004

로그 손상

https://docs.microsoft.com/en-us/sql/relational-databases/errors-events/mssqlserver-9004-database-engine-error?view=sql-server-2017

 

 

 

 

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

 

SQL Server, MSSQL, AlwaysOn, SQL Failover, SQL Server Availability Group, 가용성 그룹, SQL 가용성 그룹, 장애조치, 향상된 가용성 그룹


ETL data error with MariaDB ODBC 3.0 (from Aurora to MS SQL)

 

·      Version : SQL Server 2016, AWS Aurora, Maria ODBC 3.0

 

최근 다양한 DB환경이 구성되면서 DW(Data Warehouse) 구축할 , ETL 작업 또한 이기종 DB (데이터베이스가 다른 종류간의 ETL) 작업이 증가하는 추세이다. 필자는 현재 다양한 데이터베이스를 구축 운영하고 있으며 MySQL 에서 MS SQL ETL과정중 예기치 못한 데이터 오류가 많이 발생 하였다. AWS 있는 Aurora (MySQL 5.6) 데이터 원본에서MS SQL Server ETL하는 과정에서 Decimal값이 정상적으로 표시되지 않고 /100 값으로 변환되어 출력되어지는 문제점이 발견되었다.


 

ETL방식은 SQL Server에서 MariaDB ODBC 3.0 Driver 사용하여 AWS Aurora 데이터베이스 데이터를 오픈 쿼리 방식으로 가져온다. 모든 데이터에 대해서 /100 으로 변환되지는 않으며 decimal 데이터 타입에서만 변환되는것을 확인하였다. 구글에서 Maria odbc decimal error 검색해보니 이미 많은 사용자들이 해당 이슈를 보고 하였고 관련 솔루션도 소개되어 있다.


 

다양한 해결 방법중에 MariaDB ODBC 3.03 Driver 에서는 해당 이슈가 해결되었다는 글이 있어 드라이버를 업그레이드 진행 하였다. 그리고 테스트 결과 정상적으로 값이 출력됨을 확인할 있었다.


 

 

각종  ODBC Driver 대한 버전은 ODBC Data Source Administrator에서 Drivers 탭에서 확인할 있다.


 

·       MariaDB ODBC Driver 설치 또는 업그레이드시 시스템 재부팅이 요구되므로 주의한다.

 

 

2018-05-30 / 강성욱 / http://sqlmvp.kr / http://sqlangeles.com

 

Aurora My5.6, ETL, MariaDB ODBC driver error, ODBC decimal error, ETL, ODBC driver, MySQL, MariaDB, MSSQL


+ Recent posts