전문가 과정 1일차

1장

시나리오1 : 트랜잭션백업 필요 없음.. 주기적으로 중간중간 differential 백업을 받는다,

트랜잭션백업은 하지 않기 때문에 복구모드는 simple 모드로 간다.

시나리오2 :

1)로그쉬핑 :

기본 메커니즘 - 트랜잭션 로그 백업 (프라이머리에서 주기적으로 받아서)

secondary 인스턴스(?파일그룹?DB?)에서 주기적으로 copy해서 restore함.

그렇게 많이 쓰이진 않음.

단위 - database

2)replication :

단위 - object (테이블, 프로시저 등)

서버 A -> B로 트랜잭션 복제 구성한다고 하면

A에서 트랜잭션로그를 읽어서 distribution db에 쏴준다.

그러면 B는 그 distribution db를 가져와서 자기 db에 기록한다.

예전에는 많이 썼으나 관리가 힘들다.

3)failover 클러스터 (auto failover 지원)

단위 - 인스턴스

db하나에

4) DB -AG (auto failover 지원)

단위 - DB Group

로그인 정보는 복제가 안됨(위에 db단위이기 때문)

----------------------------------------------------------------------------------------------------

FULL백업

Mdf가 100G라고 해서 백업파일이 100GB는 아니다.

사용량만 받고 + transaction 백업량

 

 

복원

예약된 공간만큼 복원됨.

 

Mdf 쉬링크시

Extent 정보 보는 걸 확인해서, 파일 뒤에 익스텐트 가 어느정도 있는지 확인은 가능하다.

그게 시간이 어느 정도 걸릴거다 이렇게 산정할 수는 없다.

 

 

내부적으로 인덱스 단편화가 발생한다(b-tree)

500mb ~ 1GB (성능은 급격하게 떨어질 수 있다.)

물리적으로 링크드 리스트에 대한 체인이 틀어짐.

Shrink에 대해 클러스터형 인덱스/비클러스터형 인덱스 신경 안 쓴다.

 

 

2장

worker라는 thread가 할당되고 그 worker가 일함

heavy한 쿼리에 대해서는 여러 개의 thread가 붙어서 동시에 진행될 수 있다->병렬쿼리

사용자가 많은 OLTP성에서는 한 놈이 쓰레드 다 써버리면 나머지가 못 쓰는 단점이 있다…

쿼리별로 max worker threads를 줄 수 있다.

 

8개의 cpu에서 round robin 돌면서 쓰레드를 할당받는다.

Max degree를 예를 들어 4로 설정하면 4개만 돌면서 할당 받는다. -> 특정 쿼리가 cpu를 선점하는 것을 방지한다.

8이상 주면 안 좋다. 쓰레드 간 동기화 이슈도 있기 때문에

 

Priority Boost

• 권고하지 않는다. (특히 클러스터 환경에서는)

• Mssql의 쓰레드의 권한을 높인다. Os는 mssql을 우선적으로 처리한다.

• 허나 이걸 설정해도 성능적인 향상은 기대하기 어렵고 오히려 side effect만 크다.

 

Recovery interval

• Checkpoint가 얼마나 자주 일어나느냐

• 굳이 손대지 않는 게 좋다.

• 트랜잭션 수에 의해 컨트롤된다.

• 일반적으로는 60초에 한번씩 된다고 보면 된다.

• Indirect checkpoint는 redo양에 의해 컨트롤된다.

 

Optimize for ad-hoc workloads

• 컴파일할때 mssql은 stored 프로시저를 권고한다(플랜 재사용 때문에)

• Where colum1=a / colum2=b 이렇게 다른 애라서 파라미터에 따라 재사용에 따라 잘 안되는 경우

• 처음에 ad-hoc이 컴파일될 경우 두번째 사용될 때 완전체로 만들어준다…?

• 무슨말이지…..-_-;;;;

 

Database settings ( p.32)

 

p.35 데이터베이스 상태

recovery pending : 서버 재시작때.. 리커버리가 어떤 이유에 의해서 실행되지 못할 때

suspect : 주의대상. 장애…ㅋㅋ 어떤 경우에 주로 생기냐면, 예를 들어서 db내리고 다시 올리는데 파일 하나가 깨졌다거나, 트랜잭션로그가 없다거나…

emergency : db손실을 감수하고서라도 db올리고 싶을 때. -> 트랜잭션 로그 날라감

롤백 안 된 애들은 다 날라감.? 커밋 안된애들이 날라가는거 아님?=_= 일반적으로는 안 씀.

 

Lock pages in memory 를 해버리면 os의 작업관리자 상에서 sqlserver가 사용하는 메모리가 적어보인다. -> sqlserver가 락을 걸어버려서 os는 그걸 모른다.

아하! 그래서 sqlserver가 적게 사용하는 것처럼 보였구나!!

 

인덱스 (p.48)

Index reorg

인덱스의 마지막 페이지만 해주고 (leaf level)

중단시키면 중단시킨 곳에서만 멈춘다.

통계업데이트가 안된다.

 

Index rebuild

All or nothing (중단시키면 다시 롤백해야한다.)

통계업데이트가 된다.

 

 

Smart scripting (p.49)

조각화 정도에 따라서 job을 수행할 때 reorg를 할지 rebuild를 할지 정해라

• 스키마 shared

  •  

• 스키마 modified

  • 머양…먼지 모르겠어…..

 

 

통계 (p.50)

최적화된 쿼리플랜을 짜기 위해 사용되는 데이터.

Trace flag를 주면 update threshold 20%(20%가 바뀌어야 자동으로 통계업데이트를 한다) 너무 크니까 주요 테이블에 대해서는 threshold를 변경해서 관리를 해 준다…

 

 

Resource governor benefits (p.53~56)

OLTP성과 DW성 쿼리를 분리하고 싶다~

p.53 각 리소스에 대해 분배를 시켜버려

줄 수 있는 리소스는.. cpu, memory, iops

• Iops를 제한시키면 메모리에 게속 상주되어서 딜레이되니까 메모리 부족으로 죽을때도 있어….하ㅜ

• Cap_cpu_percent : 다른 애들이 안 쓰더래도 cap을 씌워버려~

 

 

3장 SECURITY

MSA : 30일만에 바뀌고 자동으로 암호가 리프레쉬 됨.

DC에서 정책만 지정하면 30일마다 자동으로 바뀜.

계정이 포함하고 있는 컴퓨터객체에 대해 자동으로 refresh

담당자도 몰라 접속하려면…

클러스터에서는 안되고 ad에 조인된 단독서버만 가능하다.

해당 계정이 포함된 개체들에 대해서는 자동적으로 배포한다 dc에서.

(sql 2012 이후 가능)

관리되는 그룹을 나눠서… 100대 동시에 하면 부하가 생기니…

그렇게 하래ㅋㅋㅋ

근데 애초에 관리자 계정은 또 따로 별도로 있는건데 무슨 의미가 있냐 이게

ㅋㅋㅋㅋㅋㅋ ㅎ ㅏ