새로운 데이터베이스를 설계 할 때 모범 사례를 따랐다 고 가정하면 데이터베이스가 적절한 성능 표준을 충족시키는 능력을 향상시킬 수있는 방법으로 데이터베이스를 테스트하고 어떻게 제안 할 것인가? 데이터베이스 구조가 필요할 경우 성능 향상 기능을 조정할 수 있습니까?성능 테스트 Greenfield 데이터베이스
테스트 데이터가 필요합니까? 데이터베이스에 대한 사용 패턴이 아직 설정되지 않은 경우 어떻게됩니까?
참고 : 블로그 게시물 및 도서 제목과 같은 자료는 환영합니다.
1)은 DB 및 시험 하중 (부하 테스트)에 대한 사용자/응용 프로그램 연결을 시뮬레이션 :
RedGate's Data Generator과 같은 도구를 사용하면 테스트 데이터가로드되어로드시 스키마가 수행되는 방식을 확인할 수 있습니다. 당신은 사용 패턴을 모른 채 완전한 테스트 계획을 짜기가 어렵지만, 당신은 그것에 대해 실행될 쿼리의 종류에 대해 대략적인 아이디어를 가지고 있어야한다고 생각합니다.
데이터베이스를 소비 할 특정 클라이언트 응용 프로그램에 따라 적절한 성능 표준이 실제로 정의됩니다. 응용 프로그램이 데이터베이스에 도달하는 동안 SQL 프로파일 러 추적을 가져오고 더 최적화해야하는 문제 영역을 신속하게 발견 할 수 있어야합니다 (심지어 경우에 따라 비 정규화).
나는 몇 일을 할 것입니다. 실제로 시스템을 사용할 것으로 예상되는 것보다 많은 사용자와 연결하는 것이 좋습니다. 모든 사용자가 로그인하거나 많은 사용자가 로그인 할 수있는 제 3 자 소프트웨어를 선택하여 시스템에 대한 적절한 테스트라고 생각되는 정의 된 기능을 수행 할 수 있습니다.
2) 많은 수의 (수백만 개)의 테스트 레코드를 삽입하고 테스트를 다시로드하십시오 (확장 성 테스트). 테이블이 커질수록 이전에 가지고 있지 않은 인덱스가 필요할 수도 있습니다. 또는 시스템 외부에서 사용 된 VIEW 또는 조인에 문제가있을 수 있습니다.
3) 데이터베이스를 분석하십시오. 나는 표를 분석하는 방법을 언급하고있다. Here은 그것이 무엇인지 설명하는 지루한 페이지입니다. 또한 here은 오라클 데이터베이스 튜닝에 관한 훌륭한 기사에 대한 링크입니다. 어떤 것은 당신이하는 일과 관련이 있습니다.
4) 응용 프로그램/사용자가 생성 한 조회를 실행하고 이에 대한 Explain 플랜을 실행하십시오. 예를 들어 전체 테이블 스캔이있는 경우이를 알려줍니다. 많은 문제를 해결하는 데 도움이됩니다.
5)이 백업에서 백업 및 다시로드하여이 백업에 대한 신뢰도를 나타낼 수도 있습니다.
+1 birdlips는 제안 사항에 동의합니다. 그러나 데이터베이스로드 테스트는 매우 까다로운 작업 일 수 있습니다. 첫 번째 단계와 중요한 단계는 실제 세계에서 발생할 수있는 데이터 패턴을 가능한 한 정확하게 예측하기위한 것입니다. 따라서 이 가장 좋습니다. 이 작업은 최소한 하나의 도메인 전문가와 함께 수행하는 것이 가장 좋습니다. 시스템 전문가가 아닌 기능적 측면과 관련이 있기 때문입니다.
모델링 데이터 패턴은 대부분의 SQL 실행 계획이 현대 RDBMS에서 최적의 쿼리 실행 계획을 계산하는 데 사용되는 테이블 통계 (예 : 개수 및 비율)를 기반으로하므로 매우 중요합니다. 어떤 사람들은 소위 "query optimizers"으로 책을 썼습니다. Cost Based Oracle Fundamentals 및 내부 문제의 해결 방법에 대한 문서가 부족하기 때문에 이러한 문제를 해결하는 것이 종종 어려움 (종종 RDBMS 공급 업체가 세부 정보를 너무 많이 공개하지 않으려 고 의도적 인 경우가 많음).위로 질문에
, 나는 다음과 같이 제안한다행운
내가 여기 (SQL Server 2008을 사용) 내 접근 방식, 지금 같은 상황에있어 :
샘플 수백만 개의 데이터 행과 별도의 "숫자"테이블을 만듭니다. 테이블에 임의의 문자열, GUID, 숫자 값 등이있을 수 있습니다. 스키마에 샘플 데이터를 삽입하는 절차를 작성하십시오. 다른 사용자 ID 등을 시뮬레이트하기 위해 숫자 열의 모듈러스 (%)를 사용하십시오.
첫 번째 표와 유사한 다른 "NewData"표를 작성하십시오. 이것은 추가되는 새로운 레코드를 시뮬레이트하는 데 사용될 수 있습니다.
테스트 쿼리의 행 개수, 시작 시간 및 종료 시간을 기록 할 수있는 "TestLog"테이블을 만듭니다.
새 레코드 또는 기존 레코드를 적절하게 사용하여 응용 프로그램이 수행 할 것으로 예상되는 워크 플로를 시뮬레이트하는 저장 프로 시저를 작성하십시오.
성능이 빠른 것처럼 보이는 경우 캐시가 누락 될 확률을 고려하십시오! 예를 들어 프로덕션 서버의 RAM이 32GB이고 테이블 크기가 128GB 일 것으로 예상되는 경우 임의의 행 조회는 버퍼 캐시에서 75 % 이상 찾을 수 없습니다.
하면이를 시뮬레이션하기 위해, 당신은 당신의 쿼리를 실행하기 전에 캐시를 지울 수 있습니다 :
DBCC DROPCLEANBUFFERS을; (Oracle : ALTER SYSTEM FLUSH SHARED POOL 인 경우)
인덱스 및 데이터 페이지가 디스크에서로드되어야하므로 성능이 100 배 저하 될 수 있습니다.
실행 SET STATISTICS IO ON; 쿼리 통계를 수집합니다. 쿼리의 논리적 읽기 수가 매우 높음 (> 1000) 경우를 찾습니다. 이것은 대개 전체 테이블 스캔의 표시입니다.
쿼리 접근 패턴 (검색 vs. 탐색)을 이해하고 성능을 조정하려면 표준 기술을 사용하십시오.
는 실제 실행 계획을 포함, SQL Server 프로파일 러
각 점에 관해서는 좀 더 구체적으로 할 수 있습니까? 예를 들어, Analyze the Database는 "스키마를 봐라."라는 의미 일 수 있습니다. –
귀하의 의견에 근거하여 더 많은 정보를 추가했습니다. – northpole