MySQL/MariaDB Single-pass, Two-pass Sort Algorithm

 

·       Version : MySQL 5.X Later,  MariaDB 5.X Later

 

MySQL/MariaDB에서는 정렬 알고리즘으로Single-pass Two-pass  알고리즘을 사용한다. 그리고 정렬처리 방식으로 인덱스를 사용한 방식과 테이블을 사용하여 정렬하는 방식이 있다.

 

Single-pass 알고리즘은 Sort Buffer 정렬 기준 칼럼을 포함한 SELECT 포함된 컬럼의 데이터를 버퍼 메모리에 담아서 정렬을 수행하는 방식이다. Two-pass 알고리즘은 정렬 컬럼과  프라이머리 값만 Sort buffer 담아서 정렬을 수행하고, 정렬된 순서대로 다시 프라이머리키로 테이블을 읽어서 SELECT 포함된 컬럼의 데이터를 가져오는 방식이다. Two-pass 알고리즘은 같은 테이블을 2 읽어야 하기 때문에 매우 불합리해 보일 있으나, Sing-pass 알고리즘은 많은 소트 버퍼의 공간이 필요하다.

 

MySQL 5.0 MariaDB 5.X 버전부터는새로운 정렬 알고리즘은 Single-pass 방식이 사용되지만 아래와 같은 경우에는 Two-pass 알고리즘이 사용된다.

·       레코드의 크기가 max_length_for_sort_data 파라미터로 설정된 값보다

·       BLOB 이나 TEXT 타입의 컬럼이 SELECT 대상에 포함될때

 

싱글패스 알고리즘은 정렬 대상 건수가 작을때 빠른 성능을 보이며, 패스 알고리즘은 데이터 레코드의 건수가 많을 효율적이다. 쿼리에 ORDER BY 사용되면 정렬을 하기 위해 아래 3가지 방식중 하나로 처리 된다. 옵티마이저는 가장 먼저 인덱스를 이용할 있을지 검토하고, 인덱스가 없을 경우 조건에 일치하는 레코드를 검색하여 버퍼에 저장하면서 정렬을 처리(Filesort)한다.

정렬 처리 방법

실행 계획의 Extra 코멘트

인덱스 사용한 정렬

별도의 내용 표기 없음

트라이빙 테이블만 정렬

(조인이 없는 경우 포함)

“Using filesort” 표시됨

조인 결과를 임시 테이블로 저장한 , 임시 테이블에서 정렬

“Using temporary; Using filesort” 같이 표시됨

 

하나의 테이블로부터 SELECT해서 정렬을 하는 경우라면 임시 테이블이 필요하지 않다. 하지만 2 이상의 테이블을 조인해서 결과를 정렬해야한다면 임시 테이블이 필요할 수도 있다. 드라이빙 테이블만 정렬된 경우에는 임시 테이블을 사용하지 않는다.

 

 

 

2019-09-20 / 강성욱 / http://sungwookkang.com

 

MySQL, MariaDB, Sort Buffer, Single-pass, Two-pass , Filesort

SQL Server 2019에서 동기 통계 업데이트시 발생하는 쿼리 Blocking 확인

 

·       Version : SQL Server 2019

 

SQL Server에서 통계정보는 옵티마이저가 실행 계획을 생성할 참고하는 중요한 지표이다. 통계 자동 업데이트가  true 설정된 경우, 데이터의 변경이 특정 임계치 이상되면 자동으로 통계 정보를 업데이트 한다.

·       SQL Server Statistics : http://sqlmvp.kr/140165557766

 

이때 통계 정보를 업데이트하면서 블럭킹이 발생하는데 이전까지는 블럭킹이 발생한것에 대해서 확인할 방법이 없었다. SQL Server 2019 부터는 이러한 문제를 해결하기 위해 새로운 진단 데이터가 도입되었다. 통계 업데이트시 블럭킹을 발생하는 것을 재현하기 위해 아래와 같은 시나리오를 만들었다.

·       자동 통계 업데이트를 트리거하는  SELECT 쿼리를 실행한다.

·       동기 통계 업데이트가 실행을 시작하고 통계가 생성될때 까지 쿼리가 대기한다. (기본적으로 차단됨)

·       동기 통계 업데이트 조작이 완료 까지 쿼리 컴파일 실행이 재개되지 않는다.

시간 동안 쿼리는 동기화 통계 업데이트 작업이 완료될 까지 대기하고 있으며, 문제를 확인하기 어려웠다. 대용량 테이블또는 사용량이 많은 시스템등 통계 업데이트에 시간이 오래 걸리는 경우 원인을 쉽게 확인할 있는 방법이 없다.

 

 

SQL Server 2019에서는 동기화 통계 업데이트로 인해 쿼리가 차단되면  sys.dm_exec_requests에서‘command’컬럼에 (STATMAN) 표시된다. 그리고 통계 업데이트 작업이 완료되면 초기 명령이름으로 돌아간다.

 

또한 새로운 WAIT_ON_SYNC_STATISTICS_REFRESH 대기 유형은 동기 통계 업데이트에서 집계된 대기 시간(블럭) 측정한다. 대기시간 누적은 sys.dm_os_wait_stats 동적 관리뷰에서 확인할 있다.

 

 

[참고자료]

https://blogs.msdn.microsoft.com/sqlserverstorageengine/2018/11/13/diagnostic-data-for-synchronous-statistics-update-blocking/

 

 

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

 

 

SQL Server2019, SQL Statistics, WAIT_ON_SYNC_STATISTICS_REFRESH, sys.dm_os_wait_stats, sys.dm_exec_requests

MySQL/MariaDB Sort Buffer

 

·       Version : MySQL,  MariaDB

 

MySQL/MariaDB에서는 데이터를 정렬(ORBER BY)하기 위해 별도의 메모리 공간을 할당하는데 이때 사용되는 메모리가 Sort buffer이다. 메모리는 정렬이 필요할 경우에만 할당되며, 쿼리 실행이 완료되면 시스템으로 즉시 반납된다. Soft buffer 크기는 시스템 설정 변수인 sort_buffer_size 조정 있다. sort_buffer_size byte단위로 표시된다.

show variables where Variable_Name like '%sort_buffer%';

 

 

정렬해야하는 데이터의 크기가 작은 경우에는 Sort buffer 만으로 충분할 수도 있지만, 정렬해야하는 데이터가 sort buffer보다 경우에는 정렬해야하는 데이터를 여러 조각으로 나누어서 처리되며, 임시 저장을 위해 디스크를 사용한다. 그리고 디스크에 저장된 데이터를 다시 메모리로 읽어 처리하고, 다시 디스크에 저장하는 행위를 반복한다.

 

 

여러  조각으로 나누어진 데이터를 정렬을 위해서 디스크에 쓰고 읽고를 반복하는 것을 Multi-Merge 라고 하는데,  Multi-Merge 횟수는  sort_merge_passes 라는 변수에 누적되기 때문에 모니터링이 가능하다. Multi-Merge 발생하게되면 디스크를 사용하는데, 디스크의 성능은 메모리보다 느리기 때문에 실제 쿼리 요청이 느려질 있다. 이러한 디스크 사용을 줄이기 위해 sort_buffer_size 증가 시킬수도 있지만, 특정 크기 이상 부터는 이상의 성능 향상을 기대하기 어렵다. 아래 그림의 테스트 자료를 보면 1MB 부터는 성능 향상이 없는것을 확인할 있다.

출처 : https://www.percona.com/blog/2010/10/25/impact-of-the-sort-buffer-size-in-mysql/

 

sort_buffer_size 영역은 세션 마다 할당되기 때문에 너무 sort_buffer_size 자칫하면 메모리 부족현상을 겪을 있다. 또한 메모리가 부족할시 OS에서는 강제적으로 프로세스를 Kill 있으므로 MySQL/MariaDB 프로세스가 중지될 수도 있기 때문에 주의해야 한다.

 

 

2019-09-19 / 강성욱 / http://sungwookkang.com

 

MySQL, MariaDB, Sort Buffer, sort_buffer_size, sort_merge_passes, Multi-Merge

SQL Server 2019 Log Writer Workers

 

·       Version : SQL Server 2014, SQL Server 2016, SQL Server 2017, SQL Server 2019

 

SQL Server 2017 숨겨진 스케줄러에서 최대 4개의 Log Writer Worker 활용하여 트랜잭션 로그 처리 활동을 지원한다.

 

SQL Server 2019 버전부터는 하드웨어 성능에 따라 최대 Log Writer Worker 수가  최대 8개까지 증가한다.

;with kgroups AS

(SELECT kgroup_count = COUNT(DISTINCT processor_group)

 FROM sys.dm_os_nodes osn)

SELECT SQLServer_version = SERVERPROPERTY('ProductVersion'), sinfo.scheduler_count,

       sinfo.cpu_count, sinfo.softnuma_configuration_desc, sinfo.socket_count,

    sinfo.numa_node_count, kgroups.kgroup_count

FROM sys.dm_os_sys_info sinfo

CROSS JOIN kgroups;

 

SELECT req.session_id, req.command, sch.scheduler_id, sched_status = sch.[status],

       sch.cpu_id, sch.parent_node_id, osn.memory_node_id, osn.processor_group

FROM sys.dm_exec_requests req

JOIN sys.dm_os_schedulers sch ON req.scheduler_id = sch.scheduler_id

JOIN sys.dm_os_nodes osn ON sch.parent_node_id = osn.node_id

WHERE req.command = 'LOG WRITER';

 

 

 SQL Server 서비스 시작시 시스템 리소스 상태에 따라 Log Writer Worker수를 결정하며  아래 그림은 SQL Server 2019 2Core CP, 2GM RAM에서 실행 하였을때, Log Writer Worker 수를 SQL Server Error Log에서 확인한 것이다.

 

 

여러 Log Writer Worker 허용되지 않는 경우 단일 Log Writer Worker 사용한다. 그렇지 않으면 아래 공식을 사용하여 Log Writer Worker 수를 계산한다.

·       NUMA 노드 X 2

·       NUMA 노드에서 사용사능한 CPU 계산 (affinity mask 설정에 따라 CPU 카운트에 영향을 있음)

 

MAX_LOG_WRITERS 허용에 따라 4 또는 8개가 할당 된다.

 

[참고자료]

·       https://blogs.msdn.microsoft.com/bobsql/2019/02/11/sql-server-log-writer-workers/

·       http://sql-sasquatch.blogspot.com/2019/06/sql-server-2019-ctp-30-max-number-of.html

 

 

 

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

 

 

SQL Server2017, SQL Server 2019, Log Writer Worker, 로그 쓰기 워커, NUMA, OS NODE

MySQL/MariaDB Full Table Scan

 

·       Version : MySQL,  MariaDB

 

Full Table Scan 인덱스를 사용하지 않고 테이블 데이터를 처음부터 끝까지 읽어서 요청 작업을 처리하는것을 의미한다. MySQL MariaDB에서는 아래와 같은 조건일때, Full Table Scan 사용한다.

·       테이블의 레코드 건수가 적어서 인덱스를 통해 읽는것보다 직접 테이블을 읽는것이 빠르다고 판된될때 (일반적으로 매우 적은페이지( 1페이지)일때)

·       WHERE절이나 ON절에 사용할 있는 인덱스가 없을 경우

·       인덱스 레인지스캔을 사용할 있는 쿼리라 하더라도 옵티마이저가 판단한 조건 일치 레코드 건수가 너무 많은 경우

 

테이블 전체를 읽는 작업은 많은 디스크 읽기 오버헤드를 발생시키기 때문에 데이터를 읽을때 한번에 여러개의 블록이나 페이지를 읽어오도록 설계되어 있다. 하지만 MariaDB에서는 테이블 스캔을 실행 할때 한번에 몇개의 페이지를 읽어 올지 설정하는 변수는 없다.

 

InnoDB XtraDB 스토리지 엔진은 특정 테이블의 연속된 데이터 페이지가 읽히면 백그라운드 스레드에 의해 Read Ahead 작업이 자동으로 시작된다. 작업은 어떤 영역의 데이터가 앞으로 필요해질 것을 예측하여 요청이 오기전에 미리 읽어 버퍼풀에 두는 것을 의미한다.

 

풀테이블 스캔이 실행되면 처음 몇개의 페이지는 포그라운드 스레드(Foreground thread, 클라이언트 스레드) 페링지를 읽기를 실행하지만, 특정 시점부터는 일긱 작업을 백그라운드 스레드로 넘겨 한버네 4 또는 8개의 페이지를 읽으면서 계속해서 페이지를 증가시켜 최대 64개의 페이지까지 읽어 버퍼풀에 저장한다. 포그라운드 스레드는 버퍼풀의 데이터를 가져다 쓰면 되므로 쿼리가 빨리 처리된다. MariaDB XtraDB에서는 Read Ahead 설정은 innodb_read_ahead_threshold 시스템 변수를 이용해 변경할 있다.   옵션값을 낮추면 자주 Read Ahread 발생한다. 하지만 빈번한 Read Ahead 불필요한 I/O 작업을 유발시키므로 주의해야 한다.

 

 

 

2019-09-17 / 강성욱 / http://sungwookkang.com

 

MySQL, MariaDB, Full Table Scan, 테이블 스캔, Read Ahead, 리드어헤드, 미리읽기,

SQL Server Login Timeout 디버깅

 

·       Version : SQL Server, SQL Server Linux

 

SQL Server 2017 SQL Linux에서 로그인시 랜덤하게 연결이 실패하는 경우가있다. 이번 포스트는 SQL Server Login Timeout 발생하는 원인을 분석하기 위한 디버깅 과정을 소개한다.

 

[Report Symptoms]

·       SQL 인증 AD 기반 로그인 모두에서 무작위 연결 실패

·       서버의 원격 클라이언트 또는 sqlcmd 실행시 디렉토리(/opt/mssql-tools/bin)에서 오류가 발생

·       장애 발생시 예측 없음

·       Non-yielding 스케줄러 보고서

·       SQL Server 2017 CU10 동작이 표시되지 않음

·       SQL Server 2017 CU12 동작을 나타냄

·       서버는 많은 CPU RAM 가진Superdome 상태

 

 

[Health Session Information]

문제를 디버깅하는 방법 하나는 /var/opt/mssql/log/system_health*.xel 파일에 있는 SQL Server 상태 세션을 추적하는 것이다. SSMS (SQL Server Management Studio)에서 XEvent 상태 세션을 보고 조정할 있다.

-          실시간 데이터 시청

-          마우스 오른쪽 ->세션을 조정

-          마우스 오른쪽 -> 스크립트 세션

상태 세션에서는 여러 이벤트 유형이 포함되며, 일부 이벤트 유형에서는 시스템 상태 세션에서 노이즈를 제거하기 위한 조건자가 포함된다.

sqlclr.clr_allocation_failure

sqlclr.clr_virtual_alloc_failure

sqlos.memory_broker_ring_buffer_recorded

sqlos.memory_node_oom_ring_buffer_recorded

sqlos.process_killed

sqlos.scheduler_monitor_deadlock_ring_buffer_recorded

sqlos.scheduler_monitor_non_yielding_iocp_ring_buffer_recorded

sqlos.scheduler_monitor_non_yielding_ring_buffer_recorded

sqlos.scheduler_monitor_non_yielding_rm_ring_buffer_recorded

sqlos.scheduler_monitor_stalled_dispatcher_ring_buffer_recorded

sqlos.scheduler_monitor_system_health_ring_buffer_recorded

sqlos.wait_info

sqlos.wait_info_external

sqlserver.connectivity_ring_buffer_recorded

sqlserver.error_reported

sqlserver.security_error_ring_buffer_recorded

sqlserver.sp_server_diagnostics_component_result

sqlserver.sql_exit_invoked

sqlserver.xml_deadlock_report

 

Non-yielding, wait_info* 연결 이벤트는 문제에 필요한 정보를 제공한다. health record 보면 다음과 같은 패턴이 반복적으로 나타난다.

 

시스템 상태에 기록된 이벤트는 Non-yielding 시작, 로그인 타임아웃 종료 Non-yielding 종료를 표시한다.

 

 

[connectivity_ring_buffer_record]

connectivity_ring_buffer_record에서는 세부 정보가 표시된다.

 

연결시도가 실패하면 type=LoginTimers 레코드가 기록되어 로그인 활동에 대한 타이밍을 제공한다. total_login_time_ms = 23309 실패한 로그인 시도가 23.3초임을 표시한다. SSL 교환 시간은 낮았지만 login_trigger_and_resouce_governor_ms 값은 대부분의 시간을 소비했다. find_login_ms 이벤트는 다른 이용자였으며 login_trigger_and_resouce_governor_ms 하위이다. 아래 스크립트를 실행하여 버퍼 항목 관계를 통해서 LoginTimer 대해서 어떤 타이밍에 대한 부모 또는 자식 값인지 확인할 있다.

Select

       *

from sys.dm_os_ring_buffers

where ring_buffer_type = 'RING_BUFFER_CONNECTIVITY'

 

버퍼 xml 형식은 상위 하위 관계를 출력한다. LoginTimer  항목은 타이밍 정보를 표시한다. (전체 레코드에서 SSL, SSPI, 읽기, 쓰기 등에 대한 추가 정보가 포함됨)

<Record id="2" type="RING_BUFFER_CONNECTIVITY" time="591262106">

 

  <ConnectivityTraceRecord>

 

    <RecordType>LoginTimers</RecordType>

 

    <LoginTimersInMilliseconds>

 

      <TotalTime>23309</TotalTime>

 

      <EnqueueTime>0</EnqueueTime>

 

      <NetWritesTime>0</NetWritesTime>

 

      <NetReadsTime>0</NetReadsTime>

 

       <TriggerAndResGovTime>

 

        <TotalTime>23266</TotalTime>

 

        <FindLogin>23265</FindLogin>

 

        <LogonTriggers>0</LogonTriggers>

 

        <ExecClassifier>0</ExecClassifier>

 

        <SessionRecover>0</SessionRecover>

 

      </TriggerAndResGovTime>

 

    </LoginTimersInMilliseconds>

 

  </ConnectivityTraceRecord>

 

이름에서 있듯이 SQL Server 로그인 유효성 검사의 일부로 로그인 정보를 검색하고 필요한 경우 AD 연결한다. , 마스터에서 데이터베이스 페이지를 읽고 잠금을 획득하며 도메인 컨트롤러(DC/KDC) 호출한다.

 

 

[waint_info *]

다른 관찰은 시스템 상태 세션이 5초보다 wait_info* 이벤트를 포함하지 않는다는 것이다. 데이터베이스 읽기, 잠금 또는 선제적외부 호출을 5 이상 기다리는 경우 이벤트가 기록되었기 때문에 waint_info* 이벤트의 부족이 드러난다. 이는 데이터베이스 읽기, 잠금 또는 preemptive, 외부 호출에 문제가 발생하지 않을 것임을 의미한다.

 

 

[Network Trace]

네트워크 추적을 살펴보면 문제를 이해하는데 도움이 된다.

 

 

[Normal SQL Login, execute select @@VERSION and logout]

다음은 유요한 SQL Server 로그인의 예이다.

 

1.       ODBC CLIENT에서 LINUX SQL Server(SYN)로의 TCP 연결 설정

2.       TDS 사전 로그인 교환

3.       512 바이트 응답 (데이터베이스 컨텍스트 XXXX, 기본언어 XXXX, 테스트 크기 XXXX 사용)

4.       SQL Batch (@@VERSION 선택)

5.       FIN-TCP 연결종료 분리

 

 

[Failing Login]

다음은 실패한 SQL Server 로그인의 예이다.

1.       ODBC CLIENT에서 LINUX SQL Server(SYN) TCP 연결 설정

2.       TDS 사전 로그인 교환

3.       로그인 응답

4.       연결 끊김 상태를 유지하면서 다른 활동 없이 시간이 경과하기를 시작

5.       RST-클라이언트가 TCP연결을 재설정함(OS오류 : 10054)

가지 실패 변형이 있었지만 로그인 응답을 처리하는 가장 일반적인 대기가 발생.

 

 

[Network Layer Overloaded]

실패한 SQL Server 로그인과 달리 네트워크 계층이 오버로드 되어 SQL Server 대한 요청을 완료하지 않은 경우 네트워크 추적이 나타난다. 일반적으로 SYN 재전송이 시작된다.

 

 

[Attempting A Reproduction]

이제 패턴에 대한 아이디어를 얻었다.  문제를 재현하는 것은 문제를 추적하고 올바르게 해결되도록 하는데 도움이 된다. Ostress툴을 사용해서 재현할 있다.

"C:\Program Files\Microsoft Corporation\RMLUtils\ostress" -Usa -Pxxxxxxx  -Q"--" -Stcp:10.193.17.114 -q -n64 -r99999999 -cc:\temp\sample.ini -T146 -oc:\temp\output

 

-          Use -U and -P for SQL authentication

 

-          Use -E for AD authentication

 

-          -q ignores query results

 

-          -S target server name forcing tcp protocol

 

-          -Q with a query of --  (comment only to do nothing)

 

-          -n controls the number of threads

 

-          -r controls the number of loops for each thread

 

-          -c the control file

 

-          -T146 disable encrypted TDS

 

-          -o output location

 

설정 파일에서 DisconnectPct=100.0 설정한다. 이를 통해 ostress 연결, 쿼리 실행,연결 끊기에 대해서 -n 스레드에 대해서 -r 반복하도록 지시한다. XEvent에서  로그인 로그 아웃 이벤트를 추적하면 연결 연결 끊기 활동을 있다. 다음은 테스트가 수행하는 로그인 로그아웃 비율을 확인하기 위한 간단한 쿼리이다.

drop table #before

go

drop table #after

go

 

select * into #before

from sys.dm_os_performance_counters where counter_name in ('Logins/sec', 'Logouts/sec')

 

waitfor delay '00:00:10'

 

select * into #after       from sys.dm_os_performance_counters where counter_name in ('Logins/sec', 'Logouts/sec')

 

select b.object_name, a.cntr_value - b.cntr_value as , (a.cntr_value - b.cntr_value) / 10.0 as [Rate/sec]

       from #before b

              inner join #after a on a.counter_name = b.counter_name

 

연결 경로를 연습하는 cmd 파일 스크립트로 시작했다.

start "ostress" "C:\Program Files\Microsoft Corporation\RMLUtils\ostress" -E -Q"--" -Stcp:xxxxxxx -q -n32 -r99999999 -cc:\temp\sample.ini -T146 -oc:\temp\output

 

start "ostress" "C:\Program Files\Microsoft Corporation\RMLUtils\ostress" -E -Q"--" -Stcp:xxxxxxx -q -n32 -r99999999 -cc:\temp\sample.ini -T146 -oc:\temp\output2

 

:top

 

       sqlcmd -E -Stcp:xxxxxxx -Q"select @@VERSION"

 

       ping -n 10 xxxxxxxx

 

goto top

 

 

[Windows TCP Settings]

2TB, 144CPU 시스템에서 스트레스 수준을 높이면서 TCP 문제가 발생했다. 동안 SQL Server에서 트래픽이 발생하지 않고 갑자기 실행된 스트레스가 발생했다. 활동이 중단되는 동안, local /opt/mssql-tools/bin/sqlcmd 연결이 계속 작동했다. Linux SQL Server시스템에서 로컬로 실행되는 아래 bash 스크립트를 사용하여 원격 연결이 실패한 동안 성공적인 연결을 확인했다.

while [ 1 -gt 0 ]

 

do

 

        echo

 

        echo $(date)

 

 

 

        ./sqlcmd -Usa -Pxxxxxxx -Q"select @@VERSION" -Stcp:.

 

        sleep 2

 

done

 

Windows 클라이언트 TCP 포트가 부족하여 중단 연결 동작이 발생했다.

netsh int ipv4 show dynamicport tcp

netsh int ipv6 show dynamicport tcp

 

netsh int ipv4 set dynamicport tcp start=10000 num=50000

netsh int ipv6 set dynamicport tcp start=10000 num=50000

 

이제 네트워크 포화 상태 (재전송이 있는 SYN) 보기 시작할 까지 높은 수준의 연결 연결 끊기 작업을 시작했지만 Non-yielding 패턴은 보이지 않았다.

 

[Disrupt The Domain Controller (Keytab)]

FindLogin 도메인 컨트롤러 호출을 수행한다는 것을 알면 다음에 도메인 컨트롤러 VM 일시 중지하여 연결시간 초과로 인해 Non-yielding 발생하여 FindLogin 많이 기록되도록 하였다.  KDC/DC 쿼리 동작을 나태나는 키탭 파일(잘못된 DC 대상) 항목을 추가할 있다. 그런 다음 FindLogin에서 Linux, AD 활동을 위해 SSSD 또는 LDAP 호출하기 전에 preemptive으로 전환되지 않는 가지 코드 경로를 찾았다. SQL Server preemptive으로 전환하지 않았기 때문에 시스템 상태 로그에 wait_type * 레코드가 없다.

 

[Non-Yielding Scheduler]

Non-Yielding 문제와 관련된 주요 행동이다. 아래 다이어그램은 발생한 문제를 강조하는데 도움이 된다.

 

 

소유한 작업자가 SQL Server 스케줄러를 끄지 않고 도메인 컨트롤러를 호출(preemptive)했다. 사전 로그인 시퀀스를 통해 SQL  인증 AD 인증 작업자가 일부 생성되어 있다. 소유 작업자가 yield일때 실행 가능한 목록은 다음에 실행할 작업자를 결정하는데 사용된다. 실행 가능 목록이 스케줄러의 최대 작업자 수에 도달하면 요청이 큐에 대기된다.

KDC/DC 쿼리가 5초이상 걸리고 Scheduler Monitor(NUMA노드당 하나) non-yielding condition (BEGIN) 보고한다. SchedulerMonitor 5초마다 진행률을 확인하여 통과 횟수를 증가 시킨다. 통과 횟수가 한계(12, 60) 도달하면 non-yielding 상황이 보고된다.

테스트의 경우 non-yielding 일반적으로 5~15 동안 지속되었으며 시스템 상태 세션에서 non-yielding BEGIN END 이벤트가 브라켓 연결시간 종료 이벤트와 함께 보고되었다. 그런 다음 다양한 로그인 시간 초과가 트리거 된다. 클라이언트가 연결을 감지하면 시간 초과에 도달하면 TCP 연결을 닫기 위해 FIN 전송된다. 일반적으로 오류 10054 SQL Server 버블링-연결이 닫힌다.

·       로그인이 사전 로그인을 처리하는 중이라면 버퍼 항목에 SSL 읽기 등의 시간과 연결 끊김이 표시될 있다.

·       로그인이 DC 호출에 멈춘 경우 일반적으로 찾기 고르인 시간이 누적된다.

·       로그인이 스케줄러에 대기된 경우 로그인 실패 이벤트에 대해 1 또는 0ms 경과 시간이 표시된다. 작업자가 작업을 받을수 있을 때까지 클라이언트는 이미 10054 보냈으며 SQL Server 로그인을 처리하려고 하면 연결이 닫히고 실패한것으로 감지된다.

 

[SQL Authentication Impact]

이제 AD 인증이 어떻게 SQL 인증, 로그인 시간 초과로 이어질 있는지 있다. SQL 인증 요청이 지연된 KDC/DC 쿼리와 동일한 스케줄러에 있는 경우 리퀘스트에 영향을 준다.

 

[Other Scheduler Impacted]

코드 경로는 많은 SQL 잠금에 관여하지 않으므로 KDC/DC 쿼리를 실행하는 정지된 사용자는 일반적으로 다른 스케줄러 해당 스케줄러와 관련된 로그인에 영향을 미치지 않는다. 다른 스케줄러는 가지 방식으로 KDC/DC쿼리의 영향을 받는다.

1.       다른 스케줄러가 AD로그인을 처리하려고 시도하고 KDC/DC 쿼리가 느리면 쿼리에 동일한 동작이 발생할 있다.

2.       non-yielding 감지되면 덤프가 호출된다. 덤프는 SQL Server 프로세스를 일시 중단한다. 덤프 시간이 로그인 시간 초과를 초과하면 클라이언트가 연결을 닫고 일반적으로 SQL Server 스케줄러에서 10054 TCP 오류가 발생한다.

 

[Recap]

버그는 도메인 컨트롤러를 쿼리하기 전에 FindLogin 코드가 preemptive되지 않아 지연 로그인 시간 초과를 초래한다. 수정된 경우 KDC/DC 쿼리에서 지연이 발생한 경우 개별 AD 로그인 시도에 여전히 로그인 시간 초과가 발생하지만 다른 로그인 쿼리는 이상 영향을 받지 않는다.

 

 

[참고자료]

https://blogs.msdn.microsoft.com/bobsql/2019/02/10/sql-mysteries-sql-server-login-timeouts-a-debugging-story/

 

 

 

 

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

 

 

SQL Server2017, XEvent, Login TimeOut, SQL Authentication Impact, FindLogin, Non-Yielding Scheduler, SQL Login, SQL TimeOut, SQL Logout

MariaDB 히스토그램 (옵티마이저가 실행계획 생성시 참고하는 데이터 분포 정보)

 

·       Version : MariaDB 10.0

 

히스토그램은 테이블의 컬럼값의 분포를 분석할 있는 통계 정보이다. 히스토그램 정보가 없는 경우에는 하나의 컬럼에서 유니크한 값의 개수에 기반해서 대략적인 분포도를 예측하는 형태로 실행 계획의 비용이 계산되었다.  또한 인덱스가 생성된 컬럼에 대해서만 유니크한 개수가 관리되었다. 이처럼 히스토그램이 관리되지 않으면 컬럼에 대한 데이터 분포를 예측하여 옵티마이저가 잘못된 실행 계획을 생성할 수도 있다.

 

히스토그램  기반 통계는 옵티마이저가 선택한 쿼리 계획을 개선하기 위한 메커니즘으로 MariaDB 10.0 버전에서 도입되었다.  이전까지는 실행계획을 생성할 인덱싱 되지 않은 컬럼의 조건은 모두 무시되었다. 이번에 도입된 히스토그램은 메커니즘은 인덱스로 만들어진 컬럼 뿐만 아니라 인덱싱되지 않은 컬럼에 대해서 모두 히스토그램 정보를 저장할 있도록 개선되었다. 모든 테이블의 모드 컬럼에 대해서 최대값, 최소값, NULL 값을 가진 비율을 계산하여 mysql.column_stats 라는 테이블에 저장되어 관리된다.

 

MariaDB 10.0 Height-Balanced Histogram 알고리즘을 사용한다. 알고리즘은 컬럼의 모든 값을 정렬해서 동일한 레코드 건수가 되도록 그룹을 개로 나눈다. 그리고 그룹의 마지막 (정렬된 상태에서 가장 큰값) 히스토그램에 저장한다. MariaDB에서는 그룹의 개수를 histogram_size 라는 시스템 설정 변수로 제어할 있다. histogram_size 0 ~ 255 값을 가지며, 크게 설정하면 히스토그램의 정확도는 높아지겠지만 그만큼 저장 공간 분석 시간이 필요하다.

 

 

MariaDB에서는 히스토그램 값을 그룹별로 한바이트씩 할당해서 VARBINARY(255) 타입의 histogram 컬럼에 저장한다. 실제 저장되는 값은 단순 그룹의 최대값이 아닌 아래와 같은 계산을 거쳐서 결과를 histogram 컬럼의 바이트에 순서대로 저장한다.  a값이 클수록 히스토그램의 정확도는 높아지지만 저장공간을 많이 사용한다.

그룹 최대값 / (컬럼 최대값 칼럼 최소값) * a

 

MariaDB에서 히스토그램 생성은 ANALYZE TABLE 명령으로 다른 통계 정보와 함께 생성된다. histogram_size 기본값은 0으로 히스토그램을 사용하지 않는다는 것을 뜻한다.  히스토그램을 사용하려면 반드시 histogram_size 0보다 값으로 설정한다. 또한 정확도를 위해서 histogram_type SINGLE_PREC_HB 또는 DOUBLE_PREC_HB 설정 있다.

 

optimizer_user_condition_selectivity 옵션은 옵티마이저가 최상의 실행 계획을 사용할 있도록 통계를 제어한다.

·       optimizer_user_condition_selectivity = 1 : MariaDB 5.5 사용되었던 선택도 방식을 그대로 유지

·       optimizer_user_condition_selectivity = 2 : 인덱스가 생성된 컬럼에 대해서만 선택도 사용

·       optimizer_user_condition_selectivity = 3 : 모든 컬럼에 대해서 선택도 사용 (히스토그램 사용 안함)

·       optimizer_user_condition_selectivity = 4 : 모든 컬럼에 대해서 선택도 사용 (히스토그램 사용)

·       optimizer_user_condition_selectivity = 5 : 모든 컬럼에 대해서 선택도 사용하면 레인지 스캔이 불가한 컬럼에 대해서 샘플링해서 선택도 사용

 

 

[참고자료]

·       Histogram-Based Statistics : https://mariadb.com/kb/en/library/histogram-based-statistics/

·       http://www.aioug.org/sangam14/images/Sangam14/Presentations/201446_garg_ppt.ppt.pdf

 

 

 

2019-09-17 / 강성욱 / http://sungwookkang.com

 

MariaDB, MariaDB 10.0, 히스토그램, histogram, optimizer_user_condition_selectivity, ANALYZE TABLE, mysql.column_stats, histogram_size, histogram_type

SQL Server Worker Thread 기본 계산

 

·       Version : SQL Server

 

SQL Server 2017부터는 소규모 환경을 고려하여 SQL Server 기본 worker thread  수가 약간 변경되었다. 소규모 환경에서 SQL Server 실행하는 경우 SQL Server worker thread 줄인다. X64 설치의 경우 sp_configure ‘max worker threads’ 값을 0으로 설정하면 SQL Server 아래 계산 공식을 사용한다.

Default

512

Small Environment

256

 

소규모 환경에서는 SQL Server 항상 worker thread  256 사용한다. 환경에서 실행하면 worker thread 512 기본값이며 CPU 수에 따라 조정된다.

CPU 4개보다 많으면 worker thread  수는512 까지 증가하며,  CPU 수에 따라32또는 16 증가하여 최대 512까지 증가한다. 만약 시스템에 64 이상의 CPU 있으면 추가 worker thread CPU 32 worker thread 증가한다.

 

 

이러한 설계는 CPU 메모리 리소스가 적은 소규모 환경 CPU 메모리를 사용하는 시스템을 고려한다. worker thread 보이는 스케줄러에만 적용된다. 숨겨진 스케줄러 DAC (Dedicated Admin Connection) 스케줄러는 계산에 영향을 받지 않는다.

 

 

[참고자료]

https://blogs.msdn.microsoft.com/bobsql/2019/02/10/sql-server-worker-thread-default-calculation/

 

 

 

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

 

 

SQL Server2017, worker thread

SQL Linux fsync 버퍼된 IO (버퍼된 쓰기중 오류가 발생하였을때 파일은 유효할까?)

 

·       Version : SQL Server Linux

 

 

PostgreSQL에서 fsync() 오류처리는 안전하지 않으며 XFS에서 데이터 손실이  발생할 있다는 내용이 있다.

·       PostgreSQL's handling of fsync() errors is unsafe and risks data loss at least on XFS : https://www.postgresql.org/message-id/flat/CAMsr%2BYE5Gs9iPqw2mQ6OHt1aC5Qk5EuBFCyG%2BvzHun1EqMxyQg%40mail.gmail.com#CAMsr+YE5Gs9iPqw2mQ6OHt1aC5Qk5EuBFCyG+vzHun1EqMxyQg@mail.gmail.com

 

이번 포스트는  SQL Server에서도 Linux 동일한 문제가 발생하는지 유효성을 검증하는 내용으로,  SQL Server 경우 O_DIRECT 사용하기 때문에 PostgreSQL 같은 문제가 발생하지 않는다.

·       Direct I/O : https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/global_file_system/s1-manage-direct-io

 

응용 프로그램이 버퍼된 쓰기를 수행하고 성공을 수신한다. (이는 안정된 미디어 파일 시스템 캐시에 데이터를 저장할 있음을 의미한다.) fsync/fdatasync 데이터가 안정적인 미디어에 저장되도록 하는데 사용된다. 안정적인 미디어 쓰기는 동기화 작업중에 발생하며 EIO 오류를 보고하는 여러가지 이유로 (디스크 공간부족, SAN 연결 끊김 ) 실패할 있다.

·       fsync/fdatasync : http://man7.org/linux/man-pages/man2/fdatasync.2.html

 

 

 

위의 PostgreSQL링크에 설명된 문제는 동기화에서 오류를 반환하지만 캐시된 페이지의 상태를 지울수 있다 것이다. 다음 동기화는 캐시된 쓰기가 안정적인 미디어로 플러시 되지 않지만 응용 프로그램에 알려졌다는 것을 의미하는 ESUCCESS 반환한다.

 

데이터베이스 응용프로그램이 백업 파일을 열어 파일 시스템 캐싱 (~_O_DIRECT) 허용한다고 가장헌다. SQL Server 작업을 수행하지 않으며  실제로 Linux SQL Server에서 작업을 수행할 없도록 했다.

1.       버퍼링된 I/O 사용하여 백업이 시작된다.

2.       백업이 진행되면서 파일 시스템 캐시에 쓰기가 발생한다.

3.       파일 시스템 캐시 쓰기가 발생하는 동안 동기화에 대한 외부 호출이 발생한다.

4.       백업에 속한 버퍼에서 동기화쓰기 오류가 발생한다. 데이터베이스 응용프로그램 외부의 응용 프로그램에서 동기화를 호출하여 데이터베이스 응용프로그램이 실패를 인식하지 못한다.

5.       백업이 끝나면 데이터베이스 응용 프로그램에서 fdatasync 실행하고 EIO 반호나하는 대신 ESUCCESS 반환된다.

6.       fdatasync 성공적으로 완료되면 미디어 백업이 안정적으로 강화되고 데이터베이스 응용 프로그램이 트랜잭션 로그의 비활성 부분을 자른다.

7.       데이터베이스에 이상 트랜잭션 조작 또는 복구를 수행 적절한 로그 레코드가 없고, 일단 유효하다고 생각된 백업파일이 유효하지 않는다.

 

문제는 SQL Server 데이터베이스, 로그 백업파일에 영향을 미치지 않는다. SQL Server 파일 시스템 캐시를 무시하기 위해 O_DIRECT 사용하여 이러한 파일 형식을 연다. Linux SQL Server 강제 플러시 모드에서 실행 중인 경우에도 파일은 O_Direct 열리므로 문제가 발생하지 않는다.

 

 

[참고자료]

·       SQL Server Linux: fsync and Buffered I/O : https://blogs.msdn.microsoft.com/bobsql/2018/12/18/sql-server-linux-fsync-and-buffered-i-o/

 

 

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

 

 

SQL Server, SQL Linux, File System, Windows, Linux, fsync, fdatasync, O_Direct

SQL Server SQL Linux에서 인스턴스 파일 초기화 차이점

 

·       Version : SQL Server, SQL Server Linux

 

SQL Server 로그 파일 또는 데이터 파일이 증가하거나 새로 작성될때, 인스턴트 파일 초기화 작업을 진행한다. 이번 포스트에서는 인스턴스 파일이 초기화 될때, 기본 파일 시스템 구현과 Windows Linux 간의 동작 차이를 알아본다.

·       Database File Initialization : https://docs.microsoft.com/en-us/sql/relational-databases/databases/database-instant-file-initialization?view=sql-server-2017

 

SQL Server 데이터 로그 파일을 만들거나 확장(증가)할때 아래 API 호출 한다.

·       CreateFile : 파일 작성 또는 열기

·       SetEndOfFile : 파일 크기를 설정하고 I/O 장치에서 공간을 확보

·       SetFileValidData : 유효한 데이터 크기 설정

 

파일이 로그 파일(LDF) 경우 SQL Server 알려진 패턴값을 할당된 공간에 쓴다. 데이터 파일 (MDF, NDF) 경우 SQL Server 인스턴스 파일 초기화 추적 플래그 1805 설정을 확인하여 할당된 공간에 패턴값을 쓸지 여부를 결정한다.

TF 1805 : 데이터 파일에 대한 인스턴스 파일 초기화를 비활성화 한다.

참고 : 스탬핑은 일반적으로 최적의 성능과 Windows Linux 파일 시스템 페이지 블록크기 정렬과 정렬을 위해 4MB 청크로 수행

 

[Windows]

Windows 파일 시스템(NTFS, RTFS)에는 파일을 즉시 초기화 하기 위한 개의 멤버키가 있다.

·       EOF : 파일 위치

·       VDL : 유효한 데이터 길이 위치

 

Empty File

파일이 처음 작성될  EOF VDL 모두 파일의 시작을 가리킨다.

·       EOF = 0

·       VLD = 0


     

 

SetEndOfFile

SetEndOfFile 파일을 확장하여 I/O 장치에서 공간을 확보하고 EOF 값을 조정한다. VLD 값은 변경되지 않은 상태로 유지된다.

·       EOF = 10G

·       VLD = 0

   

SetFileValidData

SetFileValidData VDL 이동하는데 사용된다. VDL 기록된 것으로 간주되는 경우(쓰기가 수행되지 않은 경우에도) VDL 오프셋 이전의 모든 데이터와 VDL 이전의 공간 읽기는 I/O 장치에서 오래된 데이터를 반환할  있다. VDL 이후의 데이터는 유효하지 않은 것으로 간주되며 읽기 요청에 대해 0 리턴된다.

·       EOF = 10GB

·       VDL = 1GB

참고 : 보안 고려사항과 관련된 내용은 위의Database File Initialization 문서를 참고한다.

 

Write beyond the current VDL (WriteFile*)

VDL 오프셋 이상으로 쓰기가 발생하면 WindowsVDL 이동하여 쓰기를 수용하고 이전 VDL 쓰기 요청 시작 사이의 오프셋에 0 쓴다.

·       EOF = 10GB

·       이전 VDL =1 GB

·       VDL = 5GB

 

Instant File Initialization (New File)

VDL 증분 변경 대신 SQL Server SetEndOfFile 빠른 할당 기능을 사용하고  동일한 오프셋으로 SetFileValidData 호출한다. VDL이전의 모든 데이터는 Windows 파일 시스템에 의해 쓰여진(유효한) 것으로 간주된다. 인스턴트 파일 초기화가 활성화  경우 Windows 0 쓰지 않으며 SQL Server 데이터 파일의 패턴을 스탬프 처리 하지 않는다. 내부 SQL Server 데이터베이스 할당 구조는 SQL Server 데이터 파일 할당  유효한 데이터 읽기 활동을 추적한다.

 

Instant File Initialization (Grow)

인스턴스 파일 초기화를 사용하여 파일을 확장하면  오프셋으로 SetEndOfFile  SetFileValidData 수행된다. Windows   오프셋과 이전 오프셋 사이의 데이터를 유요한 것으로 취급한다.

 

 

[Linux]

Fallocate(http://man7.org/linux/man-pages/man2/fallocate.2.html) 시스템 호출(ABI) 사용한 Linux 지원 파일 할당 Windows API호출은 아래와 같이 Linux ABI 호출에 매핑 된다.

·       CreateFile : Linux 사용

·       SetEndOfFile : Linux fallocate 사용

·       SetFileValidData : Linux Noop

 

Windows Linux 파일 시스템의 주요 차이점은 유효한 데이터 길이( VDL) 아닌 범위를 추적한다. Linux에서 범위에는 I/O 장치에 쓰여 졌는지 여부를 나타내는 플래그가 포함된다.

Empty File

파일이 처음 작성될   EOF= 0이고 포함 범위는 기록되지 않도록 (N)으로 설정된다. 쓰지 않은 범위의 읽기는 Linux에서 항상 0 반환한다. LinuxI/O 장치를 사용하지 않지만 단순히 쓰지 않는 범위로 추적된 공간에 대해 리턴 버퍼를 0으로 채운다.

 

힌트 : 익스텐트 크기  조정에 대해서는 Linux 파일 시스템 설명서를 확인한다. 기본 크기는 일반적으로 최적의 성능을 위해 SQL Server 페이지는8K  64K 범위 경계에  맞는 메모리 페이지 크기 경계(주로4K) 정렬된다.

 

SetEndOfFile

파일 크기 증가는 대체 호출로 발생한다. Linux I/O 장치에서 공간을 확보하고  EOF 추적 범위 메타 데이터를 설정하여 기록되지 않음을 나타낸다. Fallocate SetEndOfFile Windows 파일 시스템의 공간을 확보하는 것처럼 공간을 확보하여 대용량 파일을 빠르게 생성할  있다. 차이점은 SetFileValidData이다. Linux 실제 쓰기 없이 범위 추적을 쓰기 설정하는 기능을 제공하지 않는다.

 

 

성능 고려 사항 : 대상 파일 시스템에 대해 fallocate 지원되지 않으면 SQL Server ftruncate 사용한다. 이름과 달리 ftruncate ABI 파일을 늘리는데 사용될  있지만  프로비저닝된 조장이다.(공간은 메타데이터만 업데이트 되지 않는다.) ftruncate 필요한 경우 실제 공간을 확보하고 제공하기 위해 SQLPAL 파일에 0 쓴다. SQLPAL 프로세스에 대한 오류가 없고 읽기 동작이 없다.

 

Write

 번째 쓰기가 수행되면 범위에 대한 메타 데이터도 업데이트 된다. 쓰기  쓰기 되지 않은 데이터를 추적하기 위해 익스텐트를 분할하거나Linux 커널에 의해 확장된 쓰기는 디스크의 공간에 0 쓰므로 전체 익스텐트가 쓰기 된것으로 표시될  있다.

 

참고 : 대부분의 Linux 파일 시스템에서는  번의 쓰기 요청이 발생하지만 쓰기 크기  오프셋 정렬에 따라  커질수 있다. (데이터 파일 요청1개와 메타데이터 변경 요청 1)

 

 

Windows 에서 SetFileValidData 단일  메타 데이터 작업이다. VDL 설정되면 쓰기(순차 또는 임의) VDL == EOF 추가 메타 데이터 업데이트가 필요하지 않다. Linux에서 쓰기에는 데이터 쓰기 메타 데이터 쓰기가 필요한 익스텐트 업데이트가 필요하다. Linux 또는 Windows에서 가능한 빨리 파일을 쓰고 확장할 있다. 그러나 Linux에서 처음 쓰기를 수행하면 메타 데이터가 유지관리 된다.

·       데이터베이스에서 쓰기 속도가 중요한 경우 익스텐트 파일 초기화를 사용하고 번째 쓰기에 추가 오버헤드가 발생하도록 한다.

 

참고 : 대부분의 쓰기 작업은Checkpoint 또는 Lazy Write 같은 백그라운드 프로세스로 수행되므로 SQL Server에서 오버헤드를 숨기는 경우가 많다. 활성 SQL Server 세션에서 쓰기가 발생할 있으므로 대량 로드는 예외이다.

 

·        쓰기 속도를 늘릴수 있는 경우 -T1805 사용하면 데이터베이스가 쓰기 확장 중에 데이터파일 공간을 스탬핑 되도록 있다. 스탬핑은 청크로 최적화되어 있으며 번째 쓰기 데이터 메타 데이터 작업이 발생하는 쓰기 경로가 된다. 위치가 기록(스탬프) 되면 이상 추가 메타 데이터 쓰기가 필요하지 않다.

 

참고 : 파일 시스템이 fallocate 지원하지 않으면 SQLPAL 의해 파일에 0 기록된다. 로그 파일(LDF) 알려진 패턴(0으로 작성) 표시하며 SQLPAL 공간을 0으로 채울때 메타데이터가 이미 업데이트 되었으므로 데이터 파일에 대한 인스턴스 파일 초기화를 안전하게 유지할 있다.

 

[참고자료]

https://blogs.msdn.microsoft.com/bobsql/2018/12/10/sql-server-instant-file-initialization-setfilevaliddata-windows-vs-fallocate-linux/

 

 

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

 

 

SQL Server, SQL Linux, File System, Windows, Linux, SetFileValidData (Windows) vs fallocate (Linux), T1805, SetEndOfFile, SetFileValidData, VDL

 

BCP 실행시 동일 세션에서 여러개의  BULK INSERT 문으로 표시되는 이유

 

·       Version : SQL Server

 

SQL Server에서 BCP 명령을 사용하여 대량의 데이터를 로드할때, sys.dm_exec_requests 항목을 모니터링 해보면 command 항목에 BCP 대신 BULK INSERT 라고 표시되어 있다. 아래 표를 보면 동일한 세션에 BULK INSERT라고 여러개의 작업이 표시된 것을 확인할 있다.

cpu_time

total_elapsed_time

writes

session_id

start_time

command

1387

1396

32

51

2018-08-07 00:45:42.670

BULK INSERT

1930

1941

66

51

2018-08-07 00:46:02.087

BULK INSERT

632

638

32

51

2018-08-07 00:46:23.313

BULK INSERT

 

단일 BULK INSERT 대신 동일한 세션에 BULK INSERT 배치가 여러번 발생하는 이유는 무엇일까? BCP 명령을 사용할때, 옵션 -b (Batch Size) 지정하면서 배치크기에 도달할때까지 행이 스트링되고 커밋이 발생한다. 그리고 후속 행에 대해서 새로운 배치가 실행된다. 따라서 BCP 아닌 일련의 BULK INSERT 작업이 표시되는 것이다.

 

[참고자료]

·       https://blogs.msdn.microsoft.com/bobsql/2018/08/07/sql-mysteries-tracing-bcp-might-fool-you/

·       https://docs.microsoft.com/en-us/sql/tools/bcp-utility?view=sql-server-2017

 

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

 

 

SQL Server BCP, Bulk Load, BULK INSERT

MySQL /MariaDB 통계 정보

 

·       Version : MySQL 5.7, MariaDB 10.0

 

비용기반 최적화에서 가장 중요한것은 통계 정보이다. 통계 정보가 정확하지 않다면, 옵티마이저는 엉뚱한 실행계획을 생성하기 때문이다. MySQL, MariaDB 통계 정보 또한 일반 다른 RDBMS 같이 비용기반 옵티마이저를 사용하지만 아직 상용 RDBMS 비해서는 다양하지 않다.

 

MariaDB 10.0 MySQL 5.6 기능을 포함하고 있기 때문에 MySQL 5.6 매우 유사하다. MySQL 5.6 부터는 InnoDB 스토리지 엔진을 사용하는 테이블에 대한 통계 정보를 영구적(Persistent)으로 관리할 있다. MySQL 5.5 버전 까지는 show index from 으로 인덱스 칼럼의 분포를 확인할 있었지만 MySQL 5.6 부터는 mysql 데이터베이스에서 innodb_index_stats 테이블과 innodb_table_stats  테이블에서도 인덱스를 조회할 수있다.

show index from nclick.nclick;

 

 

 

select * from mysql.innodb_index_stats;

 

 

 

select * from mysql.innodb_table_stats;

 

 

MySQL 5.6 부터는 테이블을 생성할 STATS_PERSISTENT 옵션을 사용하여 통계 정보를 영구보관할 있다.

·       0 : 통계 정보를 MySQL 5.5 이전의 방식으로 관리, 단기적으로 사용

·       1 : 통계 정보를 innodb_index_stats, innodb_table_stats  테이블에 저장하여 영구 사용

·       DEFAULT : 기본값 1 설정을 적용.

 

Innodb_stats_auto_recalc 시스템 설정 변수값을 OFF 설정해도 통계가 자동으로 수집되는것을 막을 있다.

·       1 : 통계를 자동으로 수집

·       0 : ANALYZE TABLE 명령이 있을때만 수집

·       DEFAULT : 기본값 0 설정을 적용

 

CREATE TABLE `t1` (

`id` int(8) NOT NULL auto_increment,

`data` varchar(255),

`date` datetime,

PRIMARY KEY  (`id`),

INDEX `DATE_IX` (`date`)

) ENGINE=InnoDB,

  STATS_PERSISTENT=1,

  STATS_AUTO_RECALC=1,

  STATS_SAMPLE_PAGES=25;

 

 

[참고자료]

·       Configuring Persistent Optimizer Statistics Parameters  : https://dev.mysql.com/doc/refman/5.7/en/innodb-persistent-stats.html

·       Configuring Non-Persistent Optimizer Statistics Parameters : https://dev.mysql.com/doc/refman/5.7/en/innodb-statistics-estimation.html

 

 

 

2019-09-11 / 강성욱 / http://sungwookkang.com

 

MySQL, MySQL STATS, innodb_index_stats, innodb_table_stats, MySQL 통계, 히스토 그램, 옵티마이저

삭제된 AD 그룹 계정으로 SQL Server 로그인 사례 (로그인 그룹 삭제 조치해야할 사항)

 

·       Version : SQL Server

 

도메인 [DOMAIN\group] 멤버 [DOMAIN\user] 있고 [DOMAIN\group] SQL Server 인스턴스에 대한 로그인 권한이 있는 그룹이 있다고 가정한다. “Drop Login [DOMAIN\group]” 실행하면 [DOMAIN\user] 사용자는 이상 SQL Server 액세스 없을 것으로 예상했다. 그러나 아래와 같은 결과가 나왔다.

·       [DOMAIN\user] 새로운 연결은 허용되지 않음

·       기존 연결된 사용자는 계속 작동함 (기존의 [DOMAIN\user] 연결에는 그룹 구성원 권한이 캐시되므로 해당 값을 새로 고칠때 까지 연결을 통해 쿼리를 계속 실행할 있다.)

 

“DROP LOGIN [DOMAIN\user]” 실행될 [DOMAIN\user] 로그인으로 추가되어있고 SQL Server 연결이 되어 있는 경우 다음과 같은 오류 메시지와 함께 명령이 실패 한다.

DROP LOGIN” command fails with error “Could not drop login 'DOMAIN\user' as the user is currently logged in.

 

 [DOMAIN\user] 연결이 해제되면  “DROP LOGIN [DOMAIN\user]” 성공하고 사용자는 이상 SQL Server 액세스할 없다.

[DOMAINO\group] 로그인으로 추가되고 “DROP LOGIN [DOMAINO\group]” 명령을 실행하면 [DOMAINO\user] 로그인 경우에도 “DROP LOGIN”명령이 성공한다. 그러나 [DOMAIN\ user] 여전히 로그인되어 있는지 확인하기 위해해서는 아래 스크립트를 실행하여 확인할 있다.

select login_name from sys.dm_exec_sessions where login_name = 'DOMAIN\user'

 

"DROP LOGIN <loginName>" 실행하면 SQL Server <loginName> 계정에 대한 활성 연결이 있는지 확인한다. 로그인에 대해 활성화 연결이 없으면 로그인이 제거되고 명령이 성공한다. 그러나 <loginName> AD 그룹 경우 SQL Server 그룹의 구성원 활성 로그인이 있는지 확인하지 않는다. [DOMAIN\ group] 삭제하면 [DOMAIN\user] 로그인되어 있고 [DOMAIN\ group] 구성원 경우에도 [DOMAIN\ group] 대한 활성 연결이 없기 때문에 명령이 성공한다. 실제로 [DOMAIN\ user] 권한있는 작업 ( : 로그인 생성) 수행하거나 연결을 재설정 ( : sp_reset_connection 로그 아웃 다시 로그인) 때까지 연결 상태를 유지한다. 이때 SQL Server [DOMAIN\ user] 권한을 확인하고 이상 유효한 로그인이 없는지 확인하고 연결을 끊는다. 이러한 연결을 강제로 재설정 있다. 그룹 로그인을 삭제 아래 스크립트를 실행한다.

SELECT session_id FROM sys.dm_exec_sessions WHERE login_name = 'DOMAIN\user'

 

스크립트를 실행하면 [DOMAIN\ user] 연결의 모든 세션 ID 보여준다. 이제 KILL <session_id>”를 실행하여 강제로 사용자 연결을 종료한다. [DOMAIN\user] 세션은 강제 종료된 상태이기 때문에 쿼리를 실행할 이상 유효한 로그인이 없는 상태여서 다시 연결을 해야한다. 이때 그룹이 삭제되어 있기 때문에 연결할 없게 된다.

연결 자체는 sp_reset_connection 호출하여 스레드가 로그 아웃했다가 SQL Server 다시 로그인하도록하여 권한 업데이트를 강제 수도 있다. 연결이 영구적이며 지속적으로 로그 아웃했다가 다시 로그인하여 권한 검사를 수행하지 않기 때문에 연결 풀링에 유용하다. 풀링 연결을 검색 sp_reset_connection 호출하면 로그인 권한이 취소 경우 연결이 실패된다.

 

그룹에 대한 작업 권한이 취소되면 구성원 사용자의 권한이 즉시 취소된다. 예를 들어 [DOMAIN\group] "foo"테이블에 대한 선택 권한이 있고 "REVOKE SELECT ON foo TO [DOMAIN\ group]" 실행 경우 [DOMAIN\user] 즉시 "foo" 대한 선택 권한을 잃게된다. 아래 스크립트를 사용하여  실습 가능하다.

# Login as an admin user to SQL Server and add [DOMAIN\group] as a login

#

CREATE LOGIN [DOMAIN\group] FROM WINDOWS

GO

 

# In another terminal, login to SQL Server as [DOMAIN\user] and run a query to show you have access

#

SELECT @@VERSION

GO

 

# Switch back to your admin terminal and drop the group login. It will succeed even though [DOMAIN\user] is connected.

#

DROP LOGIN [DOMAIN\group]

GO

 

# Switch back to your [DOMAIN\user] window and check you still have access

#

SELECT @@VERSION

GO

 

# Switch to the admin terminal and kill the connection

#

SELECT session_id FROM sys.dm_exec_sessions WHERE login_name = DOMAIN\user

GO

 

KILL <session_id from query above>

GO

 

# Switch to your [DOMAIN\user] window to see they no longer have access. This command should not return the version information.

#

SELECT @@VERSION

GO

 

 

[참고자료]

https://blogs.msdn.microsoft.com/bobsql/2018/08/03/sql-server-mysteries-the-case-of-the-dropped-ad-group-login/

 

 

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

 

 

 

SQL Server Login, SQL Server Account, Active Directory, AD, DROP LOGIN, CREATE LOGIN

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

ODBC 드라이버를 사용하여 SQL Server에서 Azure CosmosDB 쿼리 실행

 

·       Version : SQL Server, Azure CosmosDB

 

Azure CosmosDB 기존의  SQL Server 같은 클래식 데이터베이스에서 CosmosDB 컬렉션을 조회할 있는 ODBC 드라이버를 제공한다. 이번 포스트에서는 Transaction-SQL 사용하여 SQL Server에서 CosmosDB 컬렉션을 쿼리하는 방법을 설명한다.

 

SQL Server에서 CosmosDB 쿼리하는 이유는 무엇일까? CosmosDB 문서 기타 비관계형 데이터 유형을 저장 검색하고, 필터링하고 정렬할 있는 SQL / API 제공한다. 그러나 경우에 따라 GROUP BY, HAVING, 분석 기능이 있는 복잡한 쿼리를 실행하거나 CosmosDB 비관계형 데이터를  SQL Server 테이블에 저장하는 데이터와 조인해야 하는 경우가 있다. 경우 CosmosDB 데이터를 쿼리하기 위해 Transaction-SQL 모든 기능을 활용할 있다.

 

[CosmosDB 설정]

먼저 CosmosDB계정을 생성하고 컬렉션에 실습할 데이터를 추가 한다. 데이터베이스 WWI Orders 라는 콜렉션을 생성하고, 개의 문서를 추가한다.

 

실습 데이터 등록이 완료 되었으면, SQL API 사용하여 컬렉션에 액세스한다.

 

[드라이버 설정]

SQL Server 설치된 컴퓨터에 CosmosDB ODBC 드라이버를 설치해야한다. 드라이버를 설치하면 DSN에서 ODBC 소스를 설정하고 연결을 테스트해야한다.

·       ODBC 드라이버 다운로드 : https://aka.ms/cosmos-odbc-64x64

 

 

[CosmosDB 쿼리]

모든 설정 후에 기존 SQL Server에서 OPENROWSET 함수를 사용하여 CosmosDB DSN 지정하여 CosmosDB 데이터를 쿼리 있다.

 

실습 데이터의 결과를 보면 CosmosDB에서 3개의 문서를 나타내는 3개의 행을 얻게 된다. 누락된 필드는 NULL 반한된다. 또한 아래 스크립트처럼 필터를 사용할 수도 있다.

SELECT a.*

FROM OPENROWSET('MSDASQL',

'DSN=cosmosdb1',

'select * from Orders where billto_Name = ''John Smith''') as a

 

실습데이터의 JSON 형식을 보면 shipTo 또는 billTo 같이 복잡한 JSON 객체가 모두 동일한 ROW 표시되고 있는 것을 있다. , 모든 필드가 <object name>_ <field name> 형식으로 반환된다는 것이다. 하위 오프젝트가 있는 것으로 예상되는 경우 사용자는 이를 알고 있어야 한다. 또한 필자의 경우 태그와 같은 배열 속성이 매핑되거나 반환되지 않는다.

 

[결론]

CosmosDB ODBC 드라이버를 사용하면 CosmosDB 데이터에 대해 Transact-SQL 쿼리를 실행할 있다. 이는 CosmosDB 저장된 원격 데이터에 대해서 데이터 분석이 필요한 경우 유용햘 있다. 경우 결과를 필터링 하고 필요한 필드만 선택한 다음 전체 Transact-SQL 언어를 사용하여 SQL Server에서 다양한 분석을 수행하는 조건자를 사용하여 CosmosDB 보낼 있다.

( 글을 쓰는 시점에는) CosmosDB드라이버는 Azure SQL 설치되어 있지 않으며 자체 드라이버를 추가할 없기 때문에 이는 Azure SQL 데이터베이스가 아닌 SQL Server에서만 가능하다.

 

[참고자료]

https://blogs.msdn.microsoft.com/sqlserverstorageengine/2019/03/11/running-azure-cosmosdb-queries-from-sql-server-using-odbc-driver/

 

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

 

Azure CosmosDB, SQL Server에서 Azure CosmosDB 연결하기, CosmosDB ODBC

Azure SQL Managed Instance에서 로컬 스토리지 사용량 모니터링

 

·       Version : SQL Server, Azure SQL Managed Instance

 

Azure SQL Managed Instance 사용할때, 선택한 인스턴스의 vCore 예약 스토리지에 따라 사전에 정의된 스토리지 공간이 있다. 이번 포스트에서는 Managed Instance 스토리지 공간을 모니터링하는 방법에 대해서 알아본다.

 

Managed Instance에서는 아래와 같은 제약이 있다.

·       인스턴스의 스토리지 제한은 Azure Portal에서 선택할 있다. 범용은 8TB, 비즈니스 크리티컬은 4TB 보다 없다.

·       (범용 전용) 로컬 SSD 디스크 스토리지의 제한 – Managed Instance 경우  tempdb 24GB X vCore 공간만큼 로컬 SSD 배치된다. 배치된 로컬 SSD 한계에 도달하면 tempdb에서 임시 객체를 만들수 없다.

 

스토리지 리밋에 도달하면 스토리지 공간/ vCore 수를 늘리거나 일부 리소스를 비워야 한다. 스토리지 변경은 오래 걸릴수 있기 때문에 스토리지 한계에 도달하기 전에 스토리지를 추가하는 것이 중요하다. sys.dm_os_volume_stats Managed Instance 스토리지를 포함하여 볼륨에 대한 사용 정보를 제공한다. 아래 스크립트를 사용하여 스토리지의 사용량 정보를 확인 있다.

SELECT

       volume_mount_point,

       used_gb = CAST(MIN(total_bytes / 1024. / 1024 / 1024) AS NUMERIC(8,1)),

       available_gb = CAST(MIN(available_bytes / 1024. / 1024 / 1024) AS NUMERIC(8,1)),

       total_gb = CAST(MIN((total_bytes+available_bytes) / 1024. / 1024 / 1024) AS NUMERIC(8,1))

FROM sys.master_files AS f

       CROSS APPLY sys.dm_os_volume_stats(f.database_id, f.file_id)

GROUP BY volume_mount_point;

 

 

 

 

아래 그림에서 http:// 경우 원격 Azure Premium Disk 저장소를 사용하고 있는지 보여준다.

 

 

스크립트를 주기적으로 실행하여 available_gb 줄어드는 것을 확인하여 스토리지 공간이 부족할 경우 알림을 받을 있도록 한다.

 

[참고자료]

https://blogs.msdn.microsoft.com/sqlserverstorageengine/2019/03/08/monitor-storage-local-storage-usage-on-general-purpose-managed-instance/

 

 

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

 

Azure SQL Managed Instance, Azure Local Storage, SQL Azure, sys.dm_os_volume_stats, 로컬 스토리지

SQL Server Enterprise Edition 에서 CPU 40 Core 이상 사용하지 못하는 현상

 

·       Version : SQL Server

 

호스트의 서버의 CPU96 Core 장비에서 SQL Server 2016 Enterprise Edition 설치 사용하는데 CPU 40Core 이상을 사용하지 못하는 문제가 있었다. 처음에는 NUMA 불균형이 발생하지 않았는지 의심했었지만, 증상을 보면 0 코어부터 39 코어까지만 정확히 사용하는것을 확인할 있었다. 여러가지 원인을 조사 결과 해당 문제는 SQL Server 라이선스 업데이트로 해결 되었다. MS 라이선스 정책은 많이 어려운 편인데 (서비스를 제공하는 형태에 따라 다양한 라이선스가 있음, 라이선스의 자세한 내용은 여기서 다루지 않는다.) 일반적인 SQL Server Enterprise 에디션을 설치 할경우 40Core 이상 사용할 없다고 한다. 40Core 이상 사용하려면 Core 라이선스를 선택해서 설치해야 한다.

 

이미 SQL Server Enterprise Edition 설치되어 있는 경우는 어떻게 할까? 이런 경우 SQL Server 재설치는 필요없이 라이선스 업데이트가 가능하다. 우선 SQL Server Enterprise Core Edition 다운로드 받아서, 호스트 서버에서 마운트 한다. 그리고 Install과정을 진행한다. 설치 과정중 나타나는 라이선스 코드를 복사하여, 아래 스크립트에서 PID 부분에 복사한 라이선스 코드를 입력하고 실행한다.

Setup.exe /q /ACTION=editionupgrade /INSTANCENAME=MSSQLSERVER /PID=XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /IACCEPTSQLSERVERLICENSETERMS

 

라이선스 없데이트 과정은 수분의 시간이 필요하며, 과정중에 SQL Server 서비스가 중지되므로 반드시 점검때 하도록 한다.

 

 

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

 

SQL Server Enterprise Edition, SQL Server Core lincese, SQL 라이선스, SQL Server 40코어 이상 사용하기, SQL Server CPU Core

SQL Server Agent Job에서 sysploicy_purge_history  작업실패

 

·       Version : SQL Server

 

SQL Server 2008 이후로 SQL Server Agent Job에서는 syspolicy_purge_history라는 job 등록되어 있다. 해당 Job MSDB 쌓여 있는 히스토리를 정리하는 작업을 진행한다.  가끔 해당 Job 실행시 아래와 같은 오류가 발생할 있는데, 오류가 무엇인지 확인해보고 해결하는 방법에 대해서 살펴 본다.

 

Job 실패하였을때, 해당 로그를 살펴보면 아래와 같은 오류로그가 발생하였다.

Date                    7/29/2019 1:23:41 PM

Log                       Job History (syspolicy_purge_history)

 

Step ID                3

Server                

Job Name                         syspolicy_purge_history

Step Name                       Erase Phantom System Health Records.

Duration                           00:00:00

Sql Severity        0

Sql Message ID  0

Operator Emailed          

Operator Net sent         

Operator Paged

Retries Attempted          0

 

Message

Executed as user: NT Service\SQLSERVERAGENT. The job script encountered the following errors. These errors did not stop the script:  A job step received an error at line 1 in a PowerShell script. The corresponding line is 'import-module SQLPS'. Correct the script and reschedule the job. The error information returned by PowerShell is: 'The specified module 'SQLPS' was not loaded because no valid module file was found in any module directory.  '  A job step received an error at line 1 in a PowerShell script. The corresponding line is 'SQLSERVER:'. Correct the script and reschedule the job. The error information returned by PowerShell is: 'The term 'SQLSERVER:' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.  '.  Process Exit Code -1.  The step failed.

 

해당 Job 실행하는 명령을 직접 Powershell콘솔에서 실행하여도 아래와 같은 오류가 발생한다.

 

해당 오류는 명령이 참조하는 모듈의 PATH 설정이 누락되어 발생한 경우로, 시스템 변수에서 해당 변수값을 지정하면 해결이 가능하다. 모듈의 PATH 경로는 SQL 버전마다 조금씩 다르며 아래 경로를 참고할 있도록 한다.

C:\Program Files (x86)\Microsoft SQL Server\140\Tools\PowerShell\Modules

 

모듈이 위치한 경로를 확인하였으면,  [My Computer] – [right click] – [Properties]에서 [Advance] 탭을 선택하여 [Environmeont Variables] 클릭한다.  PSModulePath 이름으로 모듈이 위차한 PATH 등록(또는 수정)한다.

 

경로가 올바르게 수정되었으면, SQLPS 시작하여 정상적으로 PATH 설정이 완료되었는지 확인이 가능하다. 또는 SQL Agent에서 해당 Job 실행하여 정상적으로 실행이 되는지 확인할 있다.

 

 

[참고자료]

https://blog.sqlauthority.com/2016/03/08/sql-server-syspolicy_purge_history-job-failing-step-erase-phantom-system-health-records/

 

2019-08-07 / Sungwook Kang / http://sungwookkang.com

 

SQL Server, Agent job, sysploicy_purge_history , Agent 히스토리 삭제, PSModulePath, Erase Phantom System Health Records

MySQL/MariaDB 파일 읽기/쓰기시 발생할 있는 secure-file-priv 오류

 

·       Version : MySQL 5.7

 

MySQL에서 LOAD DATA SELECT.. INTO OUTFILE, LOAD_FILE() 함수를 사용할 경우, 아래와 같은 오류와 함께 실행이 실패되는 경우가 있다.

The MySQL server is running with the --secure-file-priv option so it cannot execute this statement

 

이러한 오류는 MySQL 시스템 설정 문제로, 보안과 관련이 있다. , MySQL 허용하는 경로의 위치에서만 파일을 읽고 있도록 지정된 것이며, 아래 스크립트를 통해서 현재 사용할 있는 경로를 확인할 있다.

SHOW VARIABLES LIKE "secure_file_priv"

 

결과가 NULL 경우 어떠한 경로도 지정되어 있지 않다는 뜻이며,  디렉터리 경로가 표시될 경우 해당 위치에서는 파일을 읽고 쓸수 있다는 뜻이다. 또한 아무 값이 표시되지 않으면, 어떠한 위치에서도 파일을 읽고 있다.

해당 값을 수정하기 위해서는 설정 파일에 아래 스크립트를 참고하며, 서비스 재시작이 필요하다. my.cnf 또는 my.ini mysqld 항목에 추가한다.

[mysqld]

secure-file-priv = ""

 

 

[참고자료]

https://dev.mysql.com/doc/refman/8.0/en/server-options.html#option_mysqld_secure-file-priv

 

 

2019-07-23 / 강성욱 / http://sungwookkang.com

 

MySQL, MySQL security, secure_file_priv, LOAD DATA, SELECT INTO OUTFILE, LOAD_FILE()

MySQL/MariaDB ROW Size Limit

 

·       Version : MySQL 5.7

 

SQL Server에서 사용하던 일부 데이터를 MySQL 서버로 마이그레이션 작업 진행중, 컬럼수가 많은 (또는 컬럼의 길이가 테이블) 테이블이 MySQL에서는 아래와 같은 오류와 함께 테이블이 생성되지 않는 문제가 발생하였다.

Error Code: 1118. Row size too large (> 1982). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline.

 

해당 원인을 찾아본 결과, SQL Server 경우 페이지의 크기가 8K 고정이 되어있고, Row 최대 사이즈는  8K 이다. 하지만  MySQL 경우 InnoDB 사용할 경우 페이지 사이즈를 사용자가 설정 있으며, 페이지에서 사용할 있는 최대 ROW크기는 페이지 크기의 절반보다 약간 작다. 예를들어 MySQL 기본 Page 크기는 16K 인데, 최대 크기는 8K 보다 약간 작다.

·       Limits on InnoDB Tables :  https://dev.mysql.com/doc/refman/8.0/en/innodb-restrictions.html

·       Limits on Table Column Count and Row Size : https://dev.mysql.com/doc/refman/5.7/en/column-count-limit.html

또한 BLOB이나 TEXT 경우 LOB 영역을 사용한다고 하더라도, 9~12바이트의 포인터 값을 가지고 있다.

최근 SSD 보급으로 SSD 최적화된 아키텍처를 제공하기 위해 일부 서비스에서는 페이지의 크기로 4K 할당하는 경우가 있다.   경우 로우에 저장할 있는 데이터의 크기가 작아지므로 미리 데이터를 설계할때 주의가 필요하다.

 

[참고자료]

·       Limits on InnoDB Tables :  https://dev.mysql.com/doc/refman/8.0/en/innodb-restrictions.html

·       Limits on Table Column Count and Row Size : https://dev.mysql.com/doc/refman/5.7/en/column-count-limit.html

 

 

 

2019-07-19 / 강성욱 / http://sungwookkang.com

 

MySQL, MySQL column limit, MySQL row size, MySQL Innodb, page size, Row size limit, MariaDB

+ Recent posts