성능 모니터를 이용하여 SQL Server 의 Disk I/O 를 측정하여 Disk 병목 현상이 있는지 확인 후 디스크 증가 등의 성능 튜닝을 진행한다.

 

<성능 모니터 카운터>
Disk Reads/sec : 선택된 디스크 (또는 디스크 어레이) 에서 초당 수행된 읽기 작업 횟수
Disk Writes/sec : 선택된 디스크 (또는 디스크 어레이) 에서 초당 수행된 쓰기 작업 횟수
Avg. Disk Queue Length : 샘플 간격 동안 선택된 디스크에 대해 큐에 있는 읽기 및 쓰기 요청의 평균 수
Avg. Disk Sec/Read : 샘플 간격 동안 선택된 디스크에서 데이터 읽기에 소요된 평균 시간(초)
Avg. Disk Sec/Write : 샘플 간격 동안 선택된 디스크에서 데이터 쓰기에 소요된 평균 시간(초)

 

<임계값>

카운터

임계값

초당 디스크 당 I/O 수

100 이하

Disk Reads/sec

0.015 (15ms) 이하

Disk Writes/sec

0.015 (15ms) 이하

Avg. Disk Queue Length

2 이하

 

<I/O 계산>
디스크 당 I/O 수 = [읽기 + (2 * 쓰기)] / 디스크 수

 

#RAID 10 어레이로 구성된 8개 디스크 드라이브의 예

카운터

측정값

Disk Reads/sec

420

Disk Reads/sec

300

Avg. Disk Queue Length

43

Avg. Disk Sec/Read

0.032

Avg. Disk Sec/Read

0.025

 

[420 + (2 * 300)] / 8 = 127.5 디스크 당 물리적 I/O 수

결과값 127.5는 초당 100 I/O라는 한계값을 초과하므로, 이 경우 약간의 디스크 병목을 가지게 된다. 읽기 및 쓰기에 걸린 시간 값만을 조사하여도 병목이 발생함을 알 수 있다. 또, 평균 큐 길이가 43으로 I/O 요청이 큐에서 잠시 기다림으로 인해 긴 대기시간이 발생함을 의미한다.

 

<디스크 최소 개수>

[420 읽기 + (2 * 300 쓰기)] = 1020 I/O
1020 전체 I/O / 100 디스크 당 I/O = 10.2 필요한 디스크 수 
10.2 디스크는 가질 수 없으므로 12개의 디스크로 반올림 (RAID 10을 위해서는 짝수개의 디스크 필요)

 

 

출처 : SQL Server 2000 성능 튜닝 (하성희 역)
 
BCP 란.
대량의 데이터를 파일을 통하여 빠르게 처리하는 명령어( 유틸리티) 
특징 
1. 특징 콜솔상에서 명령어를 입력
2. 원격지에 있는 데이터도 추출 할 수 있다.
3. 추출한 데이터는 로컬에 쌓인다. 

명령어 예제. 
 CMD 상에서 아래 명령어를 입력 한다.
bcp CHACHACHAF_REPLICATION..TB_CAR out bcp_data_titles2.txt -c -q -T -S 127.0.0.1,5432 -U 아이디 -P 비번
bcp CHACHACHAF_REPLICATION..TB_PRESENT_TROPHY out bcp_data_TB_PRESENT_TROPHY2.txt -c -q -T -S 127.0.0.1,5432 -U 아이디 -P 비번
bcp CHACHACHA2_DDR..TB_DDR out bcp_data_TB_DDR.txt -c -q -S 175.207.8.112,1434 -U 아이디 -P 비번

쿼리로 가능  ?  (비권장)
쿼리로 CMD 명령어가 가능하지만 권한 문제로 할 수 없음 오픈해 주면 가능 하지만 보안 문제가 있다고한다. 하지만
웹서비스 풀 쿼리를 이용하는데서 발생 할 수 있는 문제인듯하다. 게임에서는 프로시저를 통하기 때문에 발생 하지 않을듯 하다. 

예제 
DECLARE @query VARCHAR (500)
SET @query = 'bcp CHACHACHAF_REPLICATION..TB_PRESENT_TROPHY out D:\MS_SQl_DB_FILE\bcp\bcp_data_TB_PRESENT_TROPHY2.txt -c -q -T -S 127.0.0.1,5432 -U 비번 -P 아이디
EXEC MASTER ..xp_cmdshell @query
  





SELECT * FROM TB_CAR
SELECT * FROM TB_PRESENT_TROPHY
/*

bcp CHACHACHAF_REPLICATION..TB_CAR out bcp_data_titles2.txt -c -q -T -S 127.0.0.1,5432 -U sa -P ab1020!!

bcp CHACHACHAF_REPLICATION..TB_PRESENT_TROPHY out bcp_data_TB_PRESENT_TROPHY2.txt -c -q -T -S 127.0.0.1,5432 -U sa -P ab1020!!

bcp CHACHACHA2_DDR..TB_DDR out bcp_data_TB_DDR.txt -c -q -S 175.207.8.112,1434 -U sa -P q1w2e3r4t5y6

*/

BULK INSERT CHACHACHAF_REPLICATION.dbo .TB_CAR FROM 'D:\MS_SQl_DB_FILE\bcp\bcp_data_titles2.txt'



BULK INSERT CHACHACHAF_REPLICATION.dbo .TB_PRESENT_TROPHY FROM 'D:\MS_SQl_DB_FILE\bcp\bcp_data_TB_PRESENT_TROPHY2.txt'





DECLARE @query VARCHAR (500)
SET @query = 'bcp CHACHACHAF_REPLICATION..TB_PRESENT_TROPHY out D:\MS_SQl_DB_FILE\bcp\bcp_data_TB_PRESENT_TROPHY2.txt -c -q -T -S 127.0.0.1,5432 -U sa -P ab1020!!'
EXEC MASTER ..xp_cmdshell @query




bcp AdventureWorks2012.HumanResources.Department format nul -T -n -f Department-n.fmt

bcp AdventureWorks2012..MyTestFormatFiles format nul -c -t, -f myTestFormatFiles.Fmt -T


bcp AdventureWorks2012..MyTestFormatFiles format nul -c -t, -x -f myTestFormatFiles.Xml -T


  

  

 

java 에서 나온 타임스템프값 

 1459180800000
DB로 할대는 뒤 3자리 제거

 

select CONVERT (varchar ( 30), dateadd( second , 1459180800/*timestamp 값*/, cast( '1970-01-01 00:00:00.000' as datetime )) , 121 ) vtimestamp
go
select CONVERT (varchar ( 30), dateadd( second , 1459138500/*timestamp 값*/, cast( '1970-01-01 00:00:00.000' as datetime )) , 121 ) vtimestamp
 go

 

하나의 테이블에 모든 로우의 개수를 알고 싶을때 보통 아래와 같이 작성을 많이 한다.


SELECT COUNT(*) FROM TestTable;


뭐 저렇게 사용해도 상관은 없지만 속도측면에서 좀 더 나은 방법이 있어서 소개 한다.


SELECT rows FROM sysindexes WHERE id = OBJECT_ID('TestTable') AND indid < 2;


대충 보면 이해가 될 것이니 설명은 패스한다.


속도차이는 COUNT를 하려는 테이블의 총 로우 개수가 100개 미만이라면 COUNT가 더 빠르다.


100개 이상이라면 위에 적어놓은 쿼리가 훨씬 빠르다.


속도 차이가 나는 이유는 COUNT 키워드를 실행하게 되면 table scan을 하게되지만 


대체 쿼리에서는 해당 rows값을 가져오기 때문에 더 빠르다.


물론 내가 테스트해본거니 확인은 다들 해보고 적용하기 바란다.


* 해당 쿼리는 테이블의 전체 로우 개수를 가져올때만 유효하다.

▶ snapshot replication (원하는 테이블 컬럼 가져올 수 있음)

1. DB 인스턴스 2개 설정

    --> 게임DB
    --> 운영툴(구독 DB)
2. 게임 DB : snapshot 설정
     --> 배포 설정 
     --> 구독 설정 주기는 게임 환경에 맞게 설정 테이블 종류에 맞게 설정 (테이블, 프로시저, 뷰  가능 , 필드및 필더 가능 )
3. 운영툴(구독 DB ) 구독 설정 
     --> 구독 설정 
     --> 관련된 통계 프로시저 작성
     --> 잡설정
4. 단점 
     --> 한 스키마에서 다양한 게임 DB 정보를 취합하기 어려움...??

▶ DB snapshot (통자로 데이터 복사됨)

1. 특정 시간마다 스키마 snapshot를 생성 
     --> 게임DB 1,2 
2. 프로시저를 통하여 데이터 Select Insert 
    
3. view 제공

4. 단점 
     --> 작업 자동화 힘듬 DB 추가 될때마다 프로시저 수정 요지 있음.


▶ 직접 구현 
1.  본서버-> 통계서버로 테이블 복사 
2.  통계서버 -> 작업 진행 
3. 운영툴 제공 
 
4. 단점 
   --> 개발자 작업량



▶ 직접 구현 구상안 1
1. snapshot replication 데이터 복사
     --> 게임 DB (배포,계시), 1:1 구독 DB 구현 
2. 통계 테이블로 데이터 취합  ( 스케줄러 )
     --> 구독 DB 정보를  취합 ( 프로시저 작업 ) 
     --> 통계 정보 가공 ( 기본정보, 요구 사항 처리 ) 
3. view 제공
      --> 통계 정보 화면 표현 

▶ 직접 구현 구상안 2
1. BCP로 직접 데이터  추출 
     1) CMD 명령어 Batch 파일 마들어서 추출 
     2) 명령 프로그램 구현 
     3) SQL 스케줄러로 구현 ( 권한 필요함 ) -http://zaco.tistory.com/249
2. SQL 스케줄러로 테이블 입력 ( Bluk Insert  > BCP IN 보다 빠름) 
     1) bluk inser
     2) 통계 데이터 추출 

 




스키마 전체 스넵샵 설정

CREATE DATABASE CHACHACHAF_GAME_SHAPSHOT

ON (NAME = CHACHACHAF_GAME, FILENAME = 'D:\MS_SQl_DB_FILE\SNAPSHOT\CHACHACHAF_GAME_SHAPSHOT.mdf' )

as SNAPSHOT OF CHACHACHAF_GAME;



USE CHACHACHAF_GAME_SHAPSHOT