Maystyle :
Admin : New post
Guestbook
Local
media
Catergories
Recent Articles
Recent Comments
Recent Trackbacks
Calendar
Tag
Archive
Link
Search
 
해당되는 게시물 5건
  SQL Server CPU Performance Problem 01 
작성일시 : 2008.09.22 20:00 | 분류 : SQL Server/Administration | 태그 : CPU, cpu performance, performance problem, problem, SQL Server, SQL Server 2005

원문 : http://technet.microsoft.com/en-us/magazine/cc137784.aspx

- CPU 하이퍼 쓰래딩은 일반적으로 Disable 하는 것이 좋다.

- CPU 가 DB의 Page을 읽을 때 Access 속도는 Physical Memory (RAM) 의 경우 약 0.5ms 가 Disk 일 경우 2~4ms (최적의 경우) 에서 4~10ms가 소요 된다. 결과적으로 Physical Memory의 데이터를 읽는 것이 성능상 가장 큰 이점이 있다.
설명 : Physical Memory에서 page를 read 하는 것을 soft page fault 라 하고 Disk에서 page를 읽는 것을 hard page fault 라 한다.

하나! 작업 부하 증가

%Processor Time 이 80%가 지속적으로 상회하고 있으면 CPU에 성능 로드가 있다고 봐도 무방하다. 이와 동시에 System\Processor Queue Length 를 확인해야 한다. SQL Server 는 하나의 논리 CPU에 하나의 Thread를 할당한다. 일반적으로 5배가 넘을 경우 성능에 문제가 있는 것으로 볼 수 있으며, 2배가 되더라도 성능에 문제가 있을 수 있다.

다만 해당 서버가 DBMS 외 다른 Role을 추가로 가지고 있다면 Processor Time 및 Context Switches/sec를 동시에 검토하여 서버 분산 여부를 판별 할 수 있다. 즉 Processor Time이 높고 동시에 Context Switches가 많이 발생 하게 되면 Role들 사이에 CPU 자원에 대한 경합이 일어나는 것으로 볼 수 있다. 이러한 현상이 지속적으로 발생하고 있다면 Role 분산을 통해 문제 현상을 해결 할 수 있다. 특히 Exchange 서버 Role이 동시에 운영되게 된다면 각 Role은 Physical Memory를 쓰고자 하고 이로 인해 극심한 Context Switching 동시에 Memory의 Hard Page Fault가 발생하게 된다. Context Switching운 논리 CPU 당 5000번 이상 발생 할 경우 일경우 성능에 문제를 발생 시키는 것으로 볼 수 있다.

높은 CPU 사용률과 함께 대기중인 큐가 많은 경우 SQL Server:SQL Statistics 성능 개체에 있는 Compilations/sec와 Re-Compilations/sec 카운터를 검토하는 것이 좋다. 쿼리 계획 컴파일 및 재컴파일은 CPU 사용률을 높힌다. Re-Compilations 값은 0에 가까워야 하지만, 시스템의 추세를 주의 깊게 검토하여 서버의 일반적인 동작과 정상적인 컴파일 수를 판단하는 것이 좋다. SQL Server:SQL Statistics 성능 개체에 있는 Batch Requests/sec를 검토하여 실제로 요청되는 쿼리와 해당 쿼리가 재컴파일 되는 빈도를 비교할 수 있다.

둘 ! 메모리 부족

SQLServer:Buffer Manager\Buffer Cache Hit Ratio 가 97% 미만 인 경우 메모리가 부족을 의심 할 수 있다.
또한 PLE (SQLServer:Buffer Manager\Page Life Expectancy)가 300초 미만 일 경우 해당 데이터 페이지는 자주 플러쉬 되고 있는 것으로 볼 수 있다. 다만 Checkpoint가 발생한 경우에는 버퍼 케쉬를 정상적으로 디스크에 플러쉬 함에 따라 일시적으로 PLE 값이 감소 할 수 있다.

Physical Memory (RAM)이 부족할 경우 버퍼 캐시 및 프로시저 캐시를 디스크로 플러시 해서 부족한 메모리를 확보해야 한다. 리소스 모니터는 플러쉬할 페이지를 결정하는 SQL Server 프로세스로써, RAM 부족할 경우 빈번하게 발생하게 된다. SQL Server: Buffer Manager\Lazy Writes/sec 카운터를 통해 확인 할 수 있다.

셋! 쿼리 성능

SQL Server로 새 쿼리가 제출될 때 쿼리 계획이 평가, 최적화 및 컴파일되어 프로시저 캐시에 저장된다. 서버로 쿼리가 제출될 때마다 요청과 일치하는 쿼리 계획이 있는지 확인하기 위해 프로시저 캐시가 검토된다. 일치하는 쿼리 계획이 없으면 SQL Server에서 새 쿼리 계획을 만들게 되는데 이 경우 비용이 들 수 있다.
SQLServer:Plan Cache\Cache Hit Ratio: SQL Plans 가 70% 미만인 경우 쿼리에 문제 있는 것으로 대략적인 판별은 가능하다.

신고
  replication 을 완전히 삭제하고 싶다면... 
작성일시 : 2008.05.29 18:17 | 분류 : SQL Server/Administration | 태그 : Delete, is_dts_replicated, is_merge_published, is_replicated, Replication, sql DAC 모드, SQL Server 2005, sys.columns

이전에 지웠다고 다 지운 리플리케이션 정보 중 일부가 sys.columns 에 아직도 남아 있어 삭제하는 일을 했습니다.
혼자 기억하기는 아쉬워서 남겨 봅니다.

[현상]
컬럼의 길이 등을 변경하거나, sp_rename 을 실행할 때 아래와 같은 메시지가 뜨면서 변경에 실패한다.
Msg 4928, Level 16, State 1, Procedure sp_rename, Line 520
Cannot alter column '<column-name>' because it is 'REPLICATED'.

[원인]
Replication 또는 이전에 설정해 놓은 Replication 설정이 남아 있어 발생한다.
아래와 같이 sys.columns의 is_replicated 및 is_merge_published is_dts_replicated의 칼럼값을 확인 하여 설정 여부를 확인 할 수 있습니다. 제가 경험했던 케이스의 경우에는  is_non_sql_subscribed 칼럼이 1로 설정이 되어 해당 컬럼에 대한 변경이 불가능했었습니다.

[Action Item]
아래 3가지 쿼리를 통해 replication의 설정 여부를 확인 할 수 있습니다.
DB replication 설정 여부 확인 : select is_published, * from sys.databases
Table의 게시 여부 여부 확인 : select is_published, * from sys.objects where is_published=1
Column의 게시 여부 확인 : select * from sys.columns where object_id = object_id('Table 명')

replication이 걸려 있음을 확인 했다면 해당 설정을 삭제 해 줍니다.
sp_msunmarkreplinfo 을 통해 특정 테이블에 대한 게시 정보를 삭제를 할 수 있습니다.
하지만 쉽지 않더군요...

제가 이전에 사용했던 방법은 sp_removedbreplication  인데, 실제로 데드락으로 인해 실패하는 경우가 많아 모든 정보를 지우는데 실패한 경험이 있습니다. 해당 프로시저에 대해서는 이전 포스트(http://maystyle.tistory.com/348)를 참조하시면 됩니다.

마지막으로 제가 선택한 방법은 sp_MSarticlecol 였습니다. 해당 내용은 SSIS, DTS 쪽 블로그를 통해서 확인 할 수 있습니다.

먼저 더미 replication을 만듭니다.
다음으로 게시 정보의 ID를 확인 합니다.
exec sp_helparticle 'replication 이름'

그런 다음 cmd 창을 열어 sql DAC 모드로 연결 합니다.
C:>sqlcmd -A -S'서버명'

마지막으로 is_non_sql_subscribed 의 값을 0으로 설정하기 위해 다음 쿼리를 수행 합니다.
1) EXEC sys.sp_MSarticlecol @artid='위에서 확인한 리플리케이션의 article id', @colid=NULL, @type='nonsqlsub', @operation='drop';
2) go

[기타 정보 확인을 위해 사용 했던 쿼리]
sp_help, select * from sys.objects where type='u'

[출처]
Microsoft 기술 지원 엔지니어 분 및 SSIS 팀 블로그
http://blogs.msdn.com/mangeshd/archive/2008/05/22/altering-properties-of-a-column-fails-with-cannot-alter-column-column-name-because-it-is-replicated.aspx

신고
  System View (SQL 2000의 System Table) 
작성일시 : 2008.05.19 13:48 | 분류 : SQL Server/Kernel | 태그 : SQL Server 2000, SQL Server 2005, system table, system view

목차
Database 기본기 다지기
1. 선언적 데이터 무결성(Declarative Data Integrity)
2. 트랜잭션 프로세싱

트랜잭션 로그와 데이터 복원
1. 데이터 파일 쓰기
2. 로그 파일 쓰기
3. 트랜잭션 로그를 통한 데이터 복구

트랜잭션 로그 파일과 데이터 파일
1. 트랜잭션 로그 파일
2. 데이터 파일

내부 저장소
1. 데이터 형식 이해하기 (일반 데이터 형식 생략)
2. System View (SQL 2000의 System Table)

System View (SQL 2000의 System Table)
SQL Server 2005 에서는 System Table이 System View로 변경되어 직접 수정이 불가능하게 돼었다.
이중 sysobjects와 sysindexes 를 보도록하겠다.

•Sysobjects
 
–DB Object들 (Table, 시스템 Table 등)의 Name, ObjectID 등을 포함하는 정보 저장

•Sysindexes
 
–각 칼럼에 대한 한 개 행 및 칼럼에 대한 정보 저장

신고
  백업의 종류 복구 모델 너 뭐니? 
작성일시 : 2008.01.21 16:11 | 분류 : SQL Server/Administration | 태그 : SQL Server 2005, 백업 종류, 복구 모델

참고 :
Inside Microsoft SQL Server 2000,
전문가로 가는 지름길 SQL Server 2000/2005,
포켓 컨설턴트 SQL 2005
http://sqlworld.pe.kr
MOC 및 MSDN 자료들....

제 글의 메인은 Inside Microsoft SQL Server 2000를 기반으로 작성되고 있습니다...
거의 copy 하는 수준으로...^^;; Windows internals에 비해 참 읽기 편합니다.

목차------------------------------------------------------------------------
DB 공부하기 1번째 : 선언적 데이터 무결성(Declarative Data Integrity) (http://maystyle.tistory.com/218)
DB 공부하기 2번째 : 트랜잭션 프로세싱 (http://maystyle.tistory.com/219)
DB 공부하기 3번째 : 데이터 파일과 트랜젝션 로그 파일
1. 왜 DB의 단편화가 일어나는 걸까? (http://maystyle.tistory.com/220)
2. 데이터 파일은 어떻게 쓰여질까? (Checkpoint) (http://maystyle.tistory.com/221)
3. 로그는 어떻게 쓰여질까? (http://maystyle.tistory.com/223)
4. 트랜잭션 로그의 기록과 복구 (http://maystyle.tistory.com/225)
5. 데이터 파일이 커질 때는 무슨일이 일어날까? (http://maystyle.tistory.com/231)
6. 데이터 파일은 어떻게 생겼을까? (http://maystyle.tistory.com/233)
7. 실제 Data 및 Log 파일 뜯어 보기 (예정 중)
DB 공부하기 4번째 : Backup 과 Restore
1. 무엇을 Backup 받아야 하나 (시스템 데이터베이스 소개)? (http://maystyle.tistory.com/236)
2. 백업의 종류 복구 모델 너 뭐니?

백업의 종류

- 전체 백업 (Full Backup)
데이터베이스 전체를 통째로 백업받는 것을 말한다. 만일 운영중인 데이터베이스가 그리 크지 않다면 전체 백업이 유용할 것이다. 하지만 운영중인 데이터베이스가 엄청난 사이즈라면 전체 백업을 받는 경우 너무 많은 시간이 소요되므로 그리 바람직하지 않다. 하지만 앞으로 살펴볼 다른 백업 방법을 사용한다 하더라도 처음에 한번은 전체 백업을 받아야 한다는 한다. 전체 백업은 다른 백업의 기초가 되게 된다.
- 차등 백업 (Differentiall Backup)
차등 백업이란 전체 백업을 받은 후 변경된 데이터만 백업 받는 방법이다. 전체 백업 이후 변경된 부분에 대한 백업을 받는 것으로써 전체 백업본이 복원된 이후에만 사용될 수 있다. (DCM 페이지에서 대응되는 값이 1인 페이지만 백업 받는다. 전체 백업을 받게 되면 해당 익스탠트에 대한 비트가 0으로 바뀌고 데이터가 변경되면 이 비트가 1로 바뀐다.)
- 트랜잭션 로그 백업 (Transaction Log Backup)
종종 차등 백업과 트랜잭션 로그 백업은 꽤 햇갈리기 좋다. 둘의 차이점을 말하자면 차등 백업은 데이터 즉 mdf, ndf를 트랜잭션 로그 백업은 로그 즉 ldf 백업 받는 것이다. 또한 복원 시 차등 백업은 딱 백업 받은 시점의 데이터만 복구가 가능하나 트랜잭션 로그 백업본의 경우 차등 백업 및 전체 백업 이후 트랜잭션 로그 백업을 받은 시점까지 1분 단위(설정 가능 기본 설정은 1분)로 복원이 가능하다. 트랜잭션 로그 백업은 복구 모델에 따라 달라진다.

복구 모델
문재 발생시 복원의 범위 및 트랜잭션 로그의 증가와 관련 SQL Server의 데이터베이스는 3가지 복구 모델을 가지고 있다.

- Full 복구 모델
데이터베이스 손상시 데이터 손실 위험을 최소로 줄여준다.
데이터베이스의 모든 동작이 로그에 완전하게 기록된다. 만약 Bulk insert 동작을 진행 된다면 삽입된 모든 행들이 완벽하게 기록된다. 단 로그를 백업 받고 shrink 하지 않는다면, 로그의 크기는 지속적으로 증가할 것이다. (인덱스 관련 작업도 트랜잭션 로그에 기록된다.) 물론 현재 로그가 살아 있다면 저장점을 이용하여, 가장 최근 지점으로 복구가 가능하다. (직접 해본적은 없다.)
방법 : SAVE TRAN 문을 통해 저장, Rollback Tran 문을 통해 Rollback
- BULK_LOGGED 복구 모델
별로 권하고 싶지 않다. Bulk한 작업이 있을 경우 해당 작업이 있었다는 최소의 데이터만 기록하게 된다. 모든 데이터 파일들은 BCM 페이지라 불리는 할당 페이지를 추가로 갖고 있는데, BCM 페이지의 각 비트들은 익스텐트를 나타낸다. 비트 값 1은 마지막 전체 데이터베이스 백업 이후에 최소한으로 로그에 기록된 벌크 동작에 의해 이 익스텐트가 변경되었다는 것을 의미한다. Bulk_logged 복구 모델은 트랜잭션 로그는 작겠지만 BCM 페이지를 스켄하고 트랜잭션 로그 자체와 함께 변경된 익스탠트까지 백업하기 때문에 백업본이 훨씬 커질 수 있다. 또한 Bulk 작업 도중 해당 트랜잭션이 중지되게 될 경우 변경된 부분까지만 적용되게 되고 전체 Rollback이 되지 않음으로 실질적으로 데이터에 문제가 발생할 수 있다.
단 시스템의 상태가 완벽하고 데이터에 대한 Bulk 작업이 필요할 경우 일시적으로 Full 모드에서 Bulk 모드로 변경하여, Disk에 대한 I/O를 획기적으로 줄인 Bulk 작업이 가능하다.
- SIMPLE 복구 모델
전체 백업과 차등 백업만 허용한다.

신고
  무엇을 Backup 받아야 하나 (시스템 데이터베이스 소개)? 
작성일시 : 2008.01.21 13:51 | 분류 : SQL Server/Administration | 태그 : master, model, msdb, SQL Server 2005, system database, tempdb

<참고 서적 :
Inside Microsoft SQL Server 2000,
전문가로 가는 지름길 SQL Server 2000/2005,
포켓 컨설턴트 SQL 2005
MOC 및 MSDN 자료들....
>
제 글의 메인은 Inside Microsoft SQL Server 2000를 기반으로 작성되고 있습니다...
거의 copy 하는 수준으로...^^;;
목차
DB 공부하기 1번째 : 선언적 데이터 무결성(Declarative Data Integrity) (http://maystyle.tistory.com/218)
DB 공부하기 2번째 : 트랜잭션 프로세싱 (http://maystyle.tistory.com/219)
DB 공부하기 3번째 : 데이터 파일과 트랜젝션 로그 파일
1. 왜 DB의 단편화가 일어나는 걸까? (http://maystyle.tistory.com/220)
2. 데이터 파일은 어떻게 쓰여질까? (Checkpoint) (http://maystyle.tistory.com/221)
3. 로그는 어떻게 쓰여질까? (http://maystyle.tistory.com/223)
4. 트랜잭션 로그의 기록과 복구 (http://maystyle.tistory.com/225)
5. 데이터 파일이 커질 때는 무슨일이 일어날까? (http://maystyle.tistory.com/231)
6. 데이터 파일은 어떻게 생겼을까? (http://maystyle.tistory.com/233)
7. 실제 Data 및 Log 파일 뜯어 보기 (예정 중)
DB 공부하기 4번째 : Backup 과 Restore
1. 무엇을 Backup 받아야 하나 (시스템 데이터베이스 소개)?

SQL Server를 설치하게 되면 사용자가 사용하는 DB (user data가 저장됨 아래 그림에서 userDB) 외에도 master, model, tempdb, msdb 등이 자동으로 생성된다. 물론 당연히 userDB는 백업 받아야 한다. 그럼 시스템 데이이터베이스는 어떻게 해야 할까?
 
이를 시스템 데이터베이스라 한다. 다음은 각 시스템 데이터베이스에 대한 설명이다.
master : 데이터베이스의 구성정보를 가지고 있다. 만약 사용자 추가 및 기타 데이터베이스의 추가 삭제 등의 데이터베이스에대한 변경작업이 있을 경우 항상 백업 받아야 한다.
model : model 데이터베이스는 새로운 데이터베이스를 만들기 위한 템플릿이다. 데이터베이스의 템플릿 변경이 없을 경우 굳이 백업 받을 필요성은 없다.
msdb : 데이터베이스에서 사용하는 예약 작업을 위해 SQL Server 에이전트 서비스에 의해 사용된다. 보통 '관리' 밑에서 만들어진 작업 등이 저장된다. 만약 해당 작업에 대한 변경이 발생한 경우 백업 받아야 한다.

tempdb : 사용자가 명시적으로 만든 임시테이블 혹은 SQL Server 내부에서 만들어진 중간 결과들을 보관하는 등을 위하여 사용된다. 시스템 재 시작시 삭제 되는 데이터 임으로 백업 받을 필요 없다.

신고
 Prev   1   Next 

티스토리 툴바