Microsoft SQL Server 2000용 모범 사례 분석 도구는 설계된 데이터베이스가 SQL Server 운영 및 관리에 대한 모범 사례 지침을 따르는지 여부를 감지할 수 있도록 Microsoft SQL Server 개발 팀에서 개발한 데이터베이스 관리 도구입니다. 이러한 지침은 데이터베이스 성능과 효율성을 개선하고 애플리케이션을 보다 쉽게 유지 관리하는 데 도움이 되는 것으로 인식됩니다.
2. SQL BPA 모범 사례 분석기 사용을 시작합니다.
설치가 완료되면 SQL Server 모범 사례 분석기 사용자 가이드의 Word 문서가 제공됩니다. 기본 단계는 다음과 같습니다
. in to SQL BPA
(2) 분석 추가/검색된 SQL Server 인스턴스
여기에 SQL Server 인스턴스 이름을 입력해야 합니다. 친숙한 이름은 나중에 생성된 모범 사례 그룹과 연결하는 데 사용됩니다(SQL Server 인스턴스 이름과 동일하게 유지하면 됩니다). ). 데이터베이스 목록의 기본값은 *입니다. 이는 현재 SQL Server 인스턴스의 모든 데이터베이스가 포함되어 있음을 의미합니다. 그러나 BPA는 'master', 'tempdb', 'msdb', 'pubs' 및 'northwind'와 같은 데이터베이스 검색을 건너뜁니다.
(3) 모범 사례 그룹을 관리하려면
먼저 모범 사례 그룹을 만들어야 합니다. 이 그룹은 실제로 일부 규칙을 결합하고 이를 앞서 입력한 SQL Server 인스턴스와 연결합니다.
(4) SQL Server 인스턴스를 분석하고
, 이전에 생성된 Best Practice Group을 실행할 Best Practice Groups 목록으로 이동하여 이전에 정의된 Rule에 따라 실행하고 Report를 생성하여 개선을 위한 제안 및 지침을 제공합니다.
3. SQL BPA v1.0에 포함된 규칙
이 핵심이라고 생각합니다. 왜냐하면 SQL Server 운영 및 관리에 대한 이러한 모범 사례 지침을 이해해야만 데이터베이스를 설계하고 T-SQL 스크립트를 작성할 때 이러한 규칙을 따를 수 있기 때문입니다. SQL Server 및 애플리케이션의 성능과 효율성을 향상시킵니다.
실제로 모든 규칙은 여기에 있습니다(영어 버전) file:///C:/Program%20Files/Microsoft%20SQL%20Server%20Best%20Practices%20Analyzer/html/RuleInformation.html#_Rule:_Explicit_Index_Creation . SQL BPA는 기본 경로에 설치됩니다. 설치 경로를 변경하면 여기에는 없습니다.
다음은 제가 관심을 갖고 있는 몇 가지 규칙입니다.
(1) 데이터베이스 설계
규칙: 기본 키 또는 고유 제약 조건이 없는 테이블
모든 테이블에 기본 키가 정의되어 있는지 또는 열에 고유 제약 조건이 정의되어 있는지 데이터베이스를 확인하세요.
규칙: 사용자 개체 이름 지정(사용자 개체 이름 지정)은
접두사 sp_, xp_ 또는 fn_로 명명된 사용자 개체를 검색하여 SQL Server의 기본 제공 개체와의 이름 지정 충돌을 방지합니다. SQL Server에서 저장 프로시저 앞에 sp_가 붙은 것을 발견하면 먼저 master 데이터베이스의 저장 프로시저를 쿼리하여 성능에 영향을 줍니다.
따라서 다음 지침을 따라야 합니다.
사용자 정의 저장 프로시저 이름에 sp_ 접두사를 사용하지 마십시오.
사용자 정의 확장 저장 프로시저 이름에 xp_ 접두사를 사용하지 마십시오
. .
실제로 usp_, uxp_, ufn_ 등의 접두사를 사용하여 이름을 지정할 수 있으며, u는 사용자 정의를 의미합니다.
(2) T-SQL
규칙: 커서 FOR UPDATE 열 목록은
저장 프로시저, 함수, 뷰 및 트리거에서 FOR UPDATE 절을 감지합니다. 커서가 FOR UPDATE 절을 정의하는 경우 명시적인 열 열을 제공하는 것이 좋습니다. FOR UPDATE는 커서에서 업데이트 가능한 열을 정의하는 데 사용됩니다. OF column_name이 제공되면 나열된 열만 수정할 수 있습니다. 열 목록을 지정하지 않으면 READ_ONLY 동시성 옵션을 지정하지 않는 한 모든 열을 업데이트할 수 있습니다. SQL Server는 지정된 열을 기반으로 작업을 최적화할 수 있습니다.
규칙: 커서 사용은
커서 업데이트 가능성이 저장 프로시저, 함수, 뷰 및 트리거에 올바르게 정의되어 있는지 확인합니다.
커서가 FOR UPDATE 절을 정의하지 않았지만 커서를 통해 업데이트된 경우,
커서가 FOR UPDATE 절을 정의했지만 커서를 통해 업데이트되지 않은 경우
실패가 보고됩니다
.
그러나 일반적으로 서버 쪽 커서는 서버 메모리 리소스를 차지하고 SQL Server 성능에 영향을 주기 때문에 사용을 피하려고 합니다. 커서 대신 중첩된 쿼리나 WHILE 문을 사용할 수 있습니다. 커서를 사용하더라도 FAST_FORWARD와 같은 커서의 일부 옵션을 정의하는 데 주의해야 합니다.
규칙: 명시적 인덱스 생성
인덱스를 명시적으로 생성하려면 CLUSTERED 또는 NONCLUSTERED를 사용하는 것이 좋습니다.
규칙: INSERT 열 목록에서는
INSERT를 사용할 때 코드의 유지 관리성을 향상시키기 위해 열 목록을 명시적으로 제공해야 합니다.
규칙: 중첩 트리거 구성은
중첩 트리거의 구성 문제로 인해 트리거되지 않는 트리거를 감지합니다. 이런건 비교적 드물어서 직접 올려봤습니다.
'nested Triggers' 구성 옵션이 0으로 설정되면 INSTEAD OF 트리거 내부에서 업데이트된 테이블/뷰에 정의된 AFTER 트리거가 실행되지 않습니다. 이 규칙:
1) 구성 옵션의 값을 확인하고 0이 아닌 경우 종료됩니다.
2) 모든 INSTEAD OF 트리거를 검색하고 트리거 내에서 DML 대상인 테이블/뷰 목록을 생성합니다.
3) 식별된 DML 대상에 AFTER 트리거가 정의되어 있는지 확인합니다.
4) 해당 항목에 대한 비준수를 보고합니다
.사례.
규칙: 트리거의 NOCOUNT 옵션은
트리거를 감지하고 SET NOCOUNT ON이 트리거 앞에 기록되도록 합니다.
SQL Server는 각 문이 실행된 후 '완료' 메시지를 보냅니다. 이 정보로 인해 트리거를 트리거하는 애플리케이션이 의도하지 않은 결과를 초래할 수 있습니다. 따라서 트리거 앞에 SET NOCOUNT ON을 추가하는 것이 좋은 디자인 습관입니다.
물론 저장 프로시저와 함수 앞에 SET NOCOUNT ON을 추가하는 것이 좋습니다. 이러한 방식으로 일련의 SQL 명령 실행으로 인해 영향을 받는 행 수가 클라이언트로 다시 전송되지 않으므로 네트워크 트래픽이 줄어들고 성능이 향상됩니다.
규칙: NULL 비교는
저장 프로시저, 함수, 뷰 및 트리거에서 NULL 상수와 관련된 동등 또는 불일치 비교를 감지합니다. ANSI_NULLS를 ON으로 설정하고 IS 키워드를 사용하여 NULL 상수를 비교하는 것이 좋습니다.
규칙: 트리거 결과는
트리거를 확인하여 트리거에 호출자에게 반환된 데이터가 없는지 확인합니다. 따라서 트리거에 다음 문을 사용하는 것은 권장되지 않습니다.
PRINT 문
SELECT(할당 또는 INTO 절 없음)
FETCH(할당 없음)
규칙: 트랜잭션 범위 지정은
저장 프로시저 및 트리거에서 트랜잭션 범위를 감지합니다. 트랜잭션의 시작과 끝은 동일한 T-SQL 구조 내에 있는 것이 좋습니다.
일반적으로 트랜잭션 범위를 최대한 좁혀 리소스를 많이 소모하고 SQL Server 성능에 영향을 주지 않도록 하십시오.
규칙: SELECT *는
저장 프로시저, 함수, 뷰 및 트리거에서 SELECT *의 사용을 감지합니다. SELECT *가 더 편리하기는 하지만 프로그램의 유지 관리 가능성이 떨어집니다. 테이블이나 뷰를 변경하면 오류나 성능 변경이 발생할 수 있습니다.
따라서 SELECT 문 뒤에 필드 목록을 명시적으로 지정하는 것이 좋습니다.
규칙: SET 옵션은
저장 프로시저 및 트리거에서 다음 SET 문의 사용을 감지합니다.
다음 옵션을 ON으로 설정하는 것이 좋습니다:
ANSI_NULLS
ANSI_PADDING
ANSI_경고
아리타보트
CONCAT_NULL_YIELDS_NULL
QUOTED_IDENTIFIER에서는
다음 옵션을 OFF로 설정할 것을 권장합니다.
NUMERIC_ROUNDABOUT
규칙: 임시 테이블 사용은
저장 프로시저 및 트리거에서 임시 테이블 사용을 감지합니다. 임시 테이블 생성 시 CREATE INDEX를 생성해야 하며, 사용이 완료된 후에는 임시 테이블을 해제해야 한다.
임시 테이블은 많은 수의 디스크 IO 작업을 생성하므로 임시 테이블 사용을 대체하려면 TABLE 변수를 사용하는 것이 좋습니다.
그러나 통계 정보의 동시 실행 및 유지에 한계가 있기 때문에 임시 테이블에 많은 양의 데이터를 삽입하는 경우에는 여전히 임시 테이블을 사용하는 것이 좋습니다.
규칙: ORDER BY가 없는 TOP은
저장 프로시저, 함수, 뷰 및 트리거에서 ORDER BY TOP 문이 없음을 감지합니다. TOP 문을 사용할 경우 정렬 조건을 지정하는 것이 좋습니다. 그렇지 않으면 생성된 결과가 SQL 실행 계획에 따라 달라지며 예기치 않은 동작이 발생하게 됩니다.
규칙: 스키마 한정 테이블/뷰를 사용하면
테이블과 뷰가 저장 프로시저, 함수, 뷰 및 트리거에서 참조될 때 소유자가 지정되었는지 여부를 감지합니다. 비록 SQL Server에서 특정 객체를 참조할 때 서버, 데이터베이스, 소유자(스키마)를 지정할 필요가 없기 때문에 server_name.database_name.owner_name.*** 등의 수고는 필요하지 않지만 SQL Server에서는 그렇게 하는 것을 권장합니다. 저장 프로시저나 함수에서 사용됩니다. 뷰나 트리거에서 테이블이나 뷰를 참조할 때는 테이블이나 뷰의 소유자를 지정하는 것이 가장 좋습니다.
SQL Server가 지정된 소유자 없이 테이블/뷰 개체를 쿼리하는 경우 먼저 기본 소유자를 쿼리한 다음 dbo를 쿼리합니다. 이로 인해 SQL Server 제품에 대한 추가 운영 비용이 발생합니다. 소유자를 지정하면 SQL Server의 성능을 향상시킬 수 있습니다. (처음으로 이 말을 들었습니다)
4. 참조 문서 및 관련 리소스
도구 다운로드 URL:
비디오 다운로드 URL: