오늘은 MSSQL 의 튜닝과 성능분석에 도움을 주는 SQL Handle과 Query Hash 에 대하여 간단하게 알아보려고 한다.

 

오라클에서는 유사한 성격의 SQL ID 가 존재하지만, MSSQL 과 개념이 조금 달라서 정리해두면 좋을 것 같다. 


 

우선 SQL Handle 이란 ?

 

SQL Handle : SQL 텍스트 자체를 식별하는 해시 값
- 동일한 SQL Text는 동일한 sql_handle을 가짐.
- 파라미터 값이 달라도 SQL 텍스트가 같으면 sql_handle은 동일

- 실제 SQL Text를 조회 할 때 SQL Handle을 조합하여 사용 
sys.dm_exec_sql_text 파라미터 사용 
sys.dm_exec_requests  파라미터로 실제 running session에 대한 sql_id 조회 후 sql_text 조회 

 

↓ 아래는 sys.dm_exec_requests 파라미터를 활용하여 아주 간단하게 running session 에 대한 query 정보를 확인한 모습

sql_handle 조회

select * from sys.dm_exec_requests 
where status = 'running'

 

위 쿼리는 sql_handle 및 plan_handle을 조회하는 쿼리로 sql_text 를 구할때는 아래 쿼리문을 사용해야한다. 

 

select * from sys.dm_exec_sql_text(sql_handle)

 

 

SQL Text 출력


Query Hash란?

Query Hash : Oracle SQL ID 와 유사한 개념으로, SQL 텍스트를 기반으로 생성된 쿼리 해시 값.

- 유사한 SQL을 그룹핑 하는데 사용함. 

- 성능 분석 및 자동 튜닝, 쿼리 그룹핑등에 사용됨.

 

sys.dm_exec_query_stats 파라미터 사용

아래는 간단하게 조회된 SQL 에 대한 Query Hash, Query Plan Hash 조회값이다.

sys.dm_exec_query_stats 조회 결과

SELECT query_hash, query_plan_hash, execution_count
FROM sys.dm_exec_query_stats;

 

실제 SQL Handle의 경우는 SQL 텍스트를 식별하는 식별자의 역할을 한다고 정의되어 있는데, 실제로 스페이스바 하나의 실제 논리적인 쿼리 결과값은 동일할지라도, 실제적인 쿼리문의 변화가 생겼을때 SQL handle 이 변화하는지 예제를 통해 실습해보고자 합니다.

 

우선 DB에 부하를 발생 시킬 수 있는 long running query를 수행하고, 위의 예제 쿼리를 활용하여 실제 sql text와 SQL ID 를 조회해봅니다.

 

DB에 부하를 발생시키는 long running query 강제 실행

 

최초 조회한 쿼리의 SQL ID 는 0x02000000DD69EF34F714DD6EBCFCAF32A72676D595EE14C90000000000000000000000000000000000000000

입니다. 이제 기존의 SQL Text 에 스페이스 바를 입력하여 쿼리의 변화를 주겠습니다. 

SQL ID 와 SQL Text 조회 결과값

 

기존의 쿼리에서 sysobjects o 항목에 스페이스바를 추가해주었습니다.

변화를 준 SQL Text

 

SQL ID가 0x02000000B1CFC72553CF1C92975EAC837C2072928BECF4940000000000000000000000000000000000000000

로 변하였습니다. 

 

SQL ID 와 SQL Text 조회 결과

 

이렇듯 실제 결과값은 동일하고 논리적인 쿼리의 수행과정 및 실행계획도 같은 쿼리지만, 스페이스바 하나로 SQL ID 는 변경되는 것을 확인 할 수 있습니다.

 

이렇게 간단하게 오늘은 쿼리 분석과 튜닝에 도움을 줄 수 있는 SQL Handle 과 Query Hash 에 대하여 알아보았습니다. 

다음에도 DB 분석 및 쿼리 튜닝에 도움이 되는 항목이 있으면 함께 공유해보도록 하겠습니다.

'Database | SQL | OS > MS-SQL' 카테고리의 다른 글

MSSQL 2019 설치  (0) 2025.02.24
MSSQL 쿼럼과 구성 방법  (0) 2025.02.18
MSSQL 2016 -> MSSQL 2019 DB 업그레이드  (3) 2025.02.05
Always On 테이블 동기화 테스트  (6) 2025.02.04
Always On Failover 테스트  (1) 2025.02.03

오늘은 지난번 MSSQL 2022에 이어서 2019 버전을 설치 할 일이 생겨 포스팅하면서 MSSQL 2019도 설치해보려고 합니다.

우선 서버는 가상 환경인 VM 환경을 구성하여 진행하였고, iso 파일은 아래 공식 링크에서 받아 사용하였습니다.

 

[서버환경]

- OS : Window Server 2019 Datacenter

- DB : SQL Server 2019 Standard

 

ISO 파일 링크 주소 : https://www.microsoft.com/ko-kr/evalcenter/download-windows-server-2019

DB 파일 링크 주소 : https://www.microsoft.com/ko-kr/evalcenter/download-sql-server-2019

 

 

 

Window 2019 iso file

 

해당하는 OS에 맞게 ISO 를 받아서 설치하고, 가상환경을 구성해줍니다. 

추가로 저는, Administrator OS와 DB OS를 구분하기 위헤 MSSQL2019 라는 OS를 새로 생성해주었습니다. 

 

MSSQL 2019 계정 생성

MSSQL 2019 계정으로 로그인 후 SQL Server 2019 설치 파일 다운로드

MSSQL 2019 설치파일

SQL Server 설치 기본 클릭 

MSSQL 2019 설치

 

기본 -> 약관 수락 -> 설치 위치 지정 

MSSQL 2019 설치 / 설치 위치 지정

설치 위치를 지정하게 되면, 신규 패키지를 다운하게 된다. 

MSSQL 2019 패키지 설치

설치 완료 후 SQL Server Tool 인 SSMS 설치 진행 후 마무리

설치 완료 후 SSMS 설치

 

SELECT @@VERSION 으로 버전을 확인 해보니 정상적으로 설치 완료 된 모습

설치 완료

 

오늘은 간단하게 MSSQL 2019 설치를 진행해보았습니다. 다음에는 아키텍쳐와 개인적으로 공부하는 포스팅을 이어서 진행하도록 하겠습니다.

MSSQL DBA로 지원하여 면접을 보고 왔는데, 제대로 답변을 하지 못했던 내용이 있었다. 바로 MSSQL Always On 을 구성하는데 필수적으로, 기본적으로 필요한 쿼럼이라는 구성이었다. 들어는 보았지만, 제대로 답변을 하지 못해서 오늘은 그 쿼럼 구성에 대해 알아보고 구성하는 포스팅을 진행해보려고 한다. 


 

쿼럼 (Quorum) 이란?

- Always On 고가용성 그룹이나 Failover Cluster Instance 에서 클러스터 노드들이 정상적으로 동작하고 있는지 판단하고, 장애 발생 시 어떤 노드가 주도권을 가져 가는지 결정한다.

--> 한마디로 클러스터 노드가 정상적으로 동작하는지 자체적인 클러스터내의 투표를 통해 데이터의 안정성과 무결성을 유지하기 위한 개념입니다. 과반 이상의 클러스터가 동의해야만 클러스터가 작동하는 구조라 홀수 구성에서 더 효율성을 가집니다.

 

쿼럼이 필요한 이유는? 

- Split-Brain 이라는 DB 장애 상황을 방지하기 위함. Split-Brain 이란 네트워크 분할로 인해 클러스터가 두 그룹으로 분리되는 장애 상황을 의미하는데, 이로 인하여 파일시스템 파손, 역복제 등으로 데이터의 무결성과 정합성이 훼손되고 모든 노드들이 Primary 라고 인식하는 상황이 발생함.

- 이러한 상황 속에서, 쿼럼을 통해 클러스터 내에서 동시에 활성화되는 Primary 노드를 하나만 유지하여 데이터 무결성을 보장 할 수 있음.

 

쿼럼 구성을 잘못 하게 된다면?

- Split-Brain 이나, 불필요한 Failover의 발생으로 데이터베이스에 장애를 유발 할 수 있음.

 

쿼럼 구성에는 대표적으로 3가지 종류가 있습니다.

1. 디스크 감시 구성 : 공유 스토리지 (디스크)를 감시자로 사용함.

2. 파일 공유 감시 구성 : 네트워크 상의 특정 파일 공유 위치를 감시자로 사용함.

3. 클라우드 감시 구성 : Azure 클라우드 스토리지를 감시자로 사용함. 

 

오늘은 파일 공유 감시 구성으로 쿼럼을 구성해 보겠습니다. 서버 구성은 일전에 구성했던 MSSQL Always On 을 참고해주세요. 

 

MS SQL Always On 설치 가이드 - 3

AD서버 구성과 클러스터 구성은 앞전의 설치 가이드를 참고 부탁드립니다.    MS SQL Always On 설치 가이드 - 1오늘은 Always On 설치 테스트를 진행해보려고 합니다.저도 SQLTAG 라는 책으로 공부하였

hyungyun.tistory.com


장애 조치 클러스터 관리자에 들어가서, 구성된 Always On 서버에 우클릭 -> 추가 작업 -> 클러스터 쿼럼 설정 구성 진행 

Failover Cluster 에서 쿼럼 설정 구성

 

클러스터 쿼럼 구성 마법사에서 기본 쿼럼 구성과 감시 할 수 있는 쿼럼을 선택하는 옵션이 있는데 공유 폴더를 감시자로 하여 구성할 것이기 때문에 쿼럼 감시 선택 

클러스터 쿼럼 마법사

파일 공유에 의한 감시 구성 선택 

파일 공유 수준의 감시 구성

AD 서버에 위치한 파일 공유 경로를 지정하고, 해당 경로를 찾아보기해서 입력한다.

 

공유 폴더 경로 입력

저장 한 뒤 다음 클릭

공유 폴더 쿼럼 구성

정상적으로 쿼럼 구성이 완료 된 모습

쿼럼 구성 완료

 

쿼럼 구성 완료

 

 

<부록>

파일 공유 차원의 쿼럼 구성이 안돼서 확인해보니, 파일에 액세스 권한을 Everyone 으로 지정하지 않았다. Everyone 으로 지정하고 해소.

쿼럼 구성 실패
쿼럼 권한 부여

 

 


이렇게 쿼럼에 대해서 알아보고, 구성도 함께 진행해보았습니다.

Always On에 대해서 공부하니, 설치만 되면 끝이 아니고 아키텍쳐 적으로 배워할 부분이 정말 많다고 생각되네요. 다음에는 이중화시 주의점이나 아키텍쳐, DB 장애별 대응 등을 살펴보려고 합니다. 

'Database | SQL | OS > MS-SQL' 카테고리의 다른 글

MSSQL SQL Handle과 Query Hash 란?  (0) 2025.05.19
MSSQL 2019 설치  (0) 2025.02.24
MSSQL 2016 -> MSSQL 2019 DB 업그레이드  (3) 2025.02.05
Always On 테이블 동기화 테스트  (6) 2025.02.04
Always On Failover 테스트  (1) 2025.02.03

오늘은 MSSQL 2016 에서 MSSQL 2019로 업그레이드를 진행해보려고 합니다. 

더보기

[서버정보]

OS : Window Server 2019 (VM 가상환경)

DB : AS-IS | SQL Server 2016 / TO-BE | SQL Server 2019

MSSQL 2016 설치는 2022와 방법이 동일합니다. 아래 링크를 참고해서 설치 진행했습니다.

https://hyungyun.tistory.com/entry/MSSQL-2022-%EC%84%A4%EC%B9%98

 

MSSQL 2022 설치

오늘은 MSSQL 2022 설치를 진행해보겠습니다.  우선 설치 파일은 Microsoft 공식 홈페이지에서 다운로드가 가능합니다.(링크 : https://www.microsoft.com/ko-kr/sql-server/sql-server-downloads)실습 목적이므로, 개발

hyungyun.tistory.com

 


우선 MSSQL 2016 버전의 DB를 설치해주어야 합니다. 사전준비로 설치를 완료해주시면 됩니다. 

MSSQL 2016 DB 설치

 

그리고 Microsoft 공식 사이트에서 2019에 해당하는 파일을 설치해줍니다.

MSSQL 2019 설치파일

 

설치 된 파일을 클릭하면, 우측 세번째 미디어 다운로드 라는 항목이 존재한다. 이 항목을 클릭하면 iso 파일을 생성할 것인지에 대한 설정창이 나오게 되는데, 여기서 iso 파일을 선택하여 다운로드 진행한다. 

미디어 다운로드 클릭
iso 설정

다운로드 된 파일을 클릭하게 되면, setup.exe 파일이 생성되어 있을텐데, 이 파일도 클릭해준다.

파일을 클릭하면, 좌측에 여러 메뉴바가 있지만 거기에서 설치 메뉴를 클릭하고 이전 버전의 SQL Server에서 업그레이드를 클릭한다. 

setup 파일 생성
MSSQL 업그레이드

 

업그레이드를 클릭하게 되면, 아래와 같은 화면이 나오게 된다. 여기서 다음을 클릭

MSSQL 2019 업그레이드

 

다음을 클릭하게 되면, 권장사항으로 업데이트를 확인

MSSQL 2019 업그레이드

 

다음을 클릭하면, 업데이트가 존재하는지 지정된 업데이트를 설치하게 된다.

MSSQL 2019 업데이트

 

업그레이드를 진행할 인스턴스를 선택해줍니다. (인스턴스가 여러개 있는 Database가 있을지도 모르니 선택 하는 것)

MSSQL 2019 업그레이드

선택하면, 업그레이드 기능을 선택하게 됩니다. 디폴트 선택값을 선택하고 다음 클릭 

MSSQL 2019 업그레이드

인스턴스명과 지정된 ID를 확인 한 뒤 다음 클릭

MSSQL 2019 업그레이드

 

최종 업그레이드 준비가 완료됩니다. 업그레이드는 진행시 OS의 재기동이 필요하므로 영향도 있는 작업이나 시스템은 OFF 하고 진행하셔야 합니다. (MCCS 등) 

MSSQL 2019 업그레이드

 

업그레이드 버튼을 클릭하게 되면, 업그레이드가 진행됩니다. 

MSSQL 2019 업그레이드

업그레이드가 완료되었습니다. 업그레이드를 하고, OS를 재시작하면 DB 업그레이드 작업이 마무리 됩니다.  

MSSQL 2019 업그레이드 완료

최종 업그레이드 된 버전을 조회해보면 2019로 업그레이드가 되었음을 확인 할 수 있습니다.

SSMS 버전이 맞지 않다면, DB 버전에 맞는 SSMS를 설치해야합니다. 다만, 현재 SSMS 버전이 최신 버전이므로 추가 설치는 하지 않았습니다. 

MSSQL 2019 업그레이드 완료

 

실제로 업그레이드 하는 과정은 간단하지만, 이에 따른 영향도나 서버에 미치는 부하 데이터베이스 동기화 등 고려해야할 사이드 이펙트는 더 많다고 생각합니다. 실제 운영 환경에서는 이러한 요소들을 고려하여 업그레이드 진행하면 될 것 같습니다. 

'Database | SQL | OS > MS-SQL' 카테고리의 다른 글

MSSQL 2019 설치  (0) 2025.02.24
MSSQL 쿼럼과 구성 방법  (0) 2025.02.18
Always On 테이블 동기화 테스트  (6) 2025.02.04
Always On Failover 테스트  (1) 2025.02.03
MS SQL Always On 설치 가이드 - 3  (1) 2025.01.23

오늘은 일전에 구성했던 Always On 서버 Database에 테이블을 생성하고 거기에 데이터를 insert 하여 Primary 서버와 Secondary 서버에 동기화가 정상적으로 이루어지는지 테스트 해보겠습니다. 

 

환경은 이전에 구성했던 Always On 환경과 동일합니다.

 


우선 Primary 서버의 ALWAYS01 데이터베이스에 dbo.TestTable 이라는 테이블을 생성해줍니다.

Primary 서버에 TestTable 생성

테이블 생성 후에 dbo.TestTable 을 조회해보면 정상적으로 생성되었음을 확인 할 수 있습니다. 

TestTable 조회

그 이후 Secondary 화면에서 조회하였으나, 해당 에러 팝업이 발생하여 정상적으로 조회되지 않았습니다.

이런저런 검색을 하고 공식사이트를 찾아보니 DB에 Secondary 에 대한 접근 권한을 부여하지 않아서 생기는 에러였습니다.

Secondary 조회 불가 팝업

Primary 서버에서 우클릭 -> 속성 -> 일반 -> Readable Secondary 에서 YES 항목으로 변경해주면 조회가 정상적으로 가능합니다. 

다시 한번 Secondary 화면에서 조회하였을때, 동일하게 테이블이 생성 되었음을 확인 할 수 있습니다. 

Secondary 화면에서 조회

Primary 서버에서 Insert 쿼리 수행 한 뒤, 결과값을 확인해보면 정상적으로 데이터가 insert 되었음을 확인 할 수 있고, 마찬가지로 Secondary 화면에서 조회해보도록 하겠습니다.

Primary 서버에서 Data insert

Secondary 서버에서도 동일하게 조회 되는 것이 확인 됩니다. 

Secondary 화면에서의 SYNC

 

이렇게 Secondary 서버에도 동기화가 가능한 테스트를 진행해보았습니다. Availability Replica 옵션이 No로 되어있는 경우에는 보조 복제본의 모든 읽기 전용 연결을 허용하지 않게 되므로 조회가 되지 않습니다.

 

사용시에 반드시 YES, Read-intent only 옵션으로 설정해두어야지 조회가 가능하다는 점 유의해주시기 바랍니다.

다음에는 올웨이즈온의 상세한 아키텍쳐와 동작방식을 공부해보도록 하겠습니다. 

이번에는 Always On 환경의 서버를 Primary -> Secondary / Secondary -> Primary 이렇게 전환 해보는 테스트를 진행하겠습니다.

 

일전에 구성했던 설치 가이드를 참고하여, 설치를 완료한 뒤 해당 환경에서 진행하였습니다.

https://hyungyun.tistory.com/entry/MS-SQL-Always-On-%EC%84%A4%EC%B9%98-%EA%B0%80%EC%9D%B4%EB%93%9C-3

 

MS SQL Always On 설치 가이드 - 3

AD서버 구성과 클러스터 구성은 앞전의 설치 가이드를 참고 부탁드립니다.    MS SQL Always On 설치 가이드 - 1오늘은 Always On 설치 테스트를 진행해보려고 합니다.저도 SQLTAG 라는 책으로 공부하였

hyungyun.tistory.com

 


우선 최초로 구성하게 되면, Primary 와 Secondary 2개로 나뉘어 지는데 Primary 환경의 Always On Group 에서 우클릭하게 되면 Failover 이라는 옵션이 나온다.

Pirmary 의 Failover 옵션

해당 옵션을 클릭하게 되면 나오는 최초 화면으로, Next 클릭

Failover 최초 화면

Failover를 진행할 Secondary Server를 선택해준다. 현재는 서버를 하나만 등록한 상황이므로, 해당 서버 하나만 선택해준다.

절체 테스트를 진행할 서버 선택

최초로 선택을 하고 넘어가게 되면, Connect 를 하지 않아서 Not Connected 상태로 남아있게 된다. 여기서 우측의 Connect 버튼클릭

Connect 하기 전

Connect 를 클릭하면 실제 인스턴스에 연결하는 화면이 나오고, 연결을 진행해주면 아래와 같이 정상적으로 연결 됨을 확인 할 수 있다.

Secondary Replica 연결

연결 후에는 모든 세팅이 완료 되었으며, Finish 버튼을 클릭하여 Failover를 마무리 하면 된다. 

Failover 세팅 완료

Failover 위자드에 Failover 상태에 관한 메세지가 출력되며 전부 정상적으로 절체 되었음을 확인 가능하다.

Failover 성공

기존의 Secondary 서버였던 인스턴스가 절체를 완료하여 현재 Primary 로 변경 된 것을 확인 할 수 있다.

Primary 전환

 

현재는 이렇게 직접 Failover 하는 경우보다 MCCS 라는 프로그램을 사용하여 장애를 감지하고, 자동으로 Failover 하는 경우가 대부분이다. 하지만, Failover 되는 과정이나 직접 해봄으로서 실제 아키텍쳐를 이해해햐아 한다고 생각한다.

 

다음에는 실제 Table 을 생성하고 데이터를 insert 하여 SYNC 가 정상적으로 되는지 테스트를 진행하려고 한다. 

+ Recent posts