본문 바로가기

SQL Server/SQL Server Tip & Tech

 (58)
SP, UDF, Trigger 문서 자동화 하기 Stored Procedure, User Defined Function, Trigger와 같이 Programmable한 DB Object의 Document 관리는 어떻게 해야 할까? 여러가지 방법이 있겠지만, 개인적으로는 소스 코드의 주석과 Extended Property를 활용하는 방법을 선호한다. 즉, DB로부터 SP 정보를 추출하여 문서화하자는 얘기. (UDF, Trigger도 마찮가지) 첨부 파일의 샘플 SP를 등록하고… 실행하면, 아래와 같은 문서를 얻을 수 있다. 만약, sp_helpmodule에 아무런 인자도 주지 않는다면, 해당 DB 컨텍스트의 모든 module에 대한 문서가 작성된다. EXEC sp_helpmodule 'P_AddExtraUser' 결과 === dbo.P_AddExtraU..
SQL Server Internals Viewer SQL 서버의 데이터의 저장 구조를 좀 더 쉽고 직관적으로 볼 수 없을까하는 바램이 있었다. 그 바램을 풀어줄 툴을 찾은듯 싶다 ㅎㅎ SQL Server Internals Viewer 다운로드는 여기서 -> http://internalsviewer.codeplex.com/ 위 사이트에서 업어온 퀵 스타트 동영상
varchar 타입으로 저장한 IP주소의 정렬 IP주소를 varchar 타입으로 저장하고 있다면, 지난 번 IP주소를 저장하는 방법에 대한 포스트에서 언급했듯이 정렬에 트릭이 필요하다. 즉, ORDER BY 절 만으로는 원하는 결과가 나오지 않는다는 뜻. 이미 널리 알려진 방법이긴 하지만... 몇 년전 SQL Server Magazine에 게재됐었고, 나름 유용하게 사용했었던 방법을 소개한다. 단, 이 방법 역시 인덱스를 활용하지 못하는 면에서 성능 상 문제를 야기할 수 있으니... 정렬할 대상이 되는 집합의 크기를 충분히 줄여준 상태에서 사용해야한다. CREATE TABLE dbo.IPAddresses (IPAddress varchar(15) NOT NULL); GO INSERT dbo.IPAddresses (IPAddress) SELECT '12..
제약 조건 Enable 할 때 주의할 점 - WITH CHECK 옵션 마이그레이션 등의 이유로 제약 조건을 Disable했다가, 다시 Enable하는 경우 ALTER TABLE ~ NOCHECK ~ / ALTER TABLE ~ CHECK ~ 구문을 사용할 수 있다. 그런데 ALTER TABLE ~ CHECK ~ 구문을 사용해 제약 조건을 다시 Enable하는 경우 WITH CHECK 옵션을 사용하지 않으면, 제약 조건이 Enable되기 전에 입력되어 있던 값을 DB엔진이 신뢰하지 않는데... 이 때문에 옵티마이저의 삽질(?)을 구경하게 될지 모른다는 문제가 있다. 결론은 제약 조건을 Enable하는 경우 반드시 WITH CHECK 옵션을 사용하자는 얘기다. -- 테이블생성 CREATE TABLE dbo.Employee ( employeeID int IDENTITY(1,1)..
IP주소를 저장하는 방법 몇 가지. - IPv4 IP주소를 저장하기 위해 사용하는 데이터 타입은 무엇이 적당할까? 1. 1개의 VARCHAR(15) 컬럼 A. 장점 i. 가독성이 높다. ii. 테이블 레이아웃이 간단하다. B. 단점 i. 저장 공간 비용이 높다. (7 ~ 15Byte) ii. 정렬 및 범위 검색이 어렵다. 2. 4개의 TINYINT 컬럼 A. 장점 i. 저장 공간을 줄일 수 있다. (4Byte) ii. 정렬 및 검색이 쉽다. iii. 가독성이 좋은 편이다. B. 단점 i. IP주소 문자열과의 변환 비용이 존재한다. ii. 테이블 레이아웃이 복잡해진다. 3. 1개의 INT 컬럼 A. 장점 i. 저장 공간을 줄일 수 있다. (4Byte) ii. 정렬 및 검색이 쉽다. iii. 테이블 레이아웃이 간단하다. B. 단점 i. 가독성이 매우 낮다..
윤년 판단하는 함수 컨셉 : 주어진 연도의 2월 28일에 하루를 더했을 때, 여전히 2월이면 윤년으로 판단한다. CREATE FUNCTION dbo.FN_IsLeapYear(@intYear int) RETURNS bit AS BEGIN RETURN ( SELECT CASE DATEPART(MM, CAST((CAST(@intYear AS char(4)) + '0228') AS datetime) + 1) WHEN 2 THEN 1 ELSE 0 END ) END GO
날짜와 복합키를 이룬 IDENTITY 컬럼의 값 순환시키기 날짜 기준으로 테이블을 범위 파티셔닝하는 대량 로그 테이블인 경우, 날짜 컬럼과 IDENTITY속성의 컬럼을 PRIMARY KEY로 설정하게된다. 문제는... IDENTITY속성 컬럼의 데이터 타입이... 보통은 int일텐데... int로 커버할 수 있는 약 21억건 - 양수만 따졌을 때 - 이 부족하다라고 주장하는 동료가 있을 수 있다는 점이다. (하긴... 하루 115만건의 레코드를 5년간 보관하면 21억건 정도가 되긴한다.) 우리가 해결해야 하는 문제는 대충 이렇다. 1. 날짜를 기준으로 테이블을 범위 파티셔닝하고, 슬라이딩 윈도우를 구현한다. 2. 모든 테이블은 식별자를 가진다. 단, 날짜만으로는 Primary Key가 될 수 없다. 3. 가능한한 Primary Key 사이즈가 작았으면 좋겠다. ..
diskpart.exe를 사용한 파티션 오프셋 설정으로 디스크 I/O 최적화 하기 MS SQL에서 데이터를 저장하는 최소 단위는 page이고 8개의 페이지가 1개의 extent를 이룬다. 여기서 page의 크기는 8KB이므로 1개의 extent는 64KB인데, extent는 디스크 I/O의 최소 단위가 된다. 즉, SQL서버의 세계에서 디스크를 통한 데이터 입출력은 64KB단위라는 것. 이와 관련하여 RAID 컨트롤러의 stripe block size, 파티션 시작 오프셋, 파티션 볼륨의 allocation unit size를 어떻게 셋팅할 것인가하는 문제가 생기는데... Default 설정 값으로는 SQL Server에 최적화되지 않기 때문이다. 일단 파티션 시작 오프셋값을 조정해야하는 이론적 근거는 다음과 같다. OS의 파티션 시작은 Default로 디스크의 64번째 섹터부터이다...

티스토리툴바