2008-09-20 2 views
6

현재 MS SQL Server 2005를 사용하여 상당히 집중적 인 계산을 수행하는 제품을 개발 중입니다. 높은 수준에서 내 제품의 아키텍처는 "분석"을 할 때마다 저장되는 "실행"개념을 기반으로합니다. 일련의 실행 테이블 (실행 당 ~ 100 개의 테이블).여러 파일 그룹을 사용하면 데이터베이스 속도가 빨라 집니까?

문제가 발생하는 이유는 실행 횟수가 몇 달 후에 1,000에 가까워 질수록 데이터베이스 성능이 떨어지는 것처럼 보일뿐 아니라 테이블 존재 여부를 확인하는 것과 같은 간단한 쿼리가 필요하다는 것입니다. 또는보기를 만드는 데는 최대 2 초에서 2 시간이 걸릴 수 있습니다.

저는 현재하고 있지 않은 여러 파일 그룹을 사용하는 것이 도움이된다고 들었습니다. 이것이 사실입니까, 그렇다면 왜/어떻게 도움이 될까요? 또한, 다른 제안이 있다면, 심지어 테이블을 더 적게 사용하는 것처럼, 나는 그들에게 개방되어 있습니다. 데이터베이스 속도를 높이고 규모가 확대 될 수있는 상태가되도록 노력하겠습니다.

답변

3

성능 측면에서 보면 파일/파일 그룹을 별도로 사용하면 큰 물리량으로 데이터를 여러 실제 디스크에 분산시킬 수 있습니다. 이는 여러 디스크에서 여러 데이터 요청을 동시에 처리 할 수 ​​있기 때문에 유용합니다 (일반적으로 병렬보다 병렬이 빠름). 다른 모든 사항이 동일하면 성능에 도움이되는 경향이 있지만 특정 데이터 세트와 실행중인 쿼리에 따라 달라집니다.

설명에서 느린 작업은 테이블을 만들고 테이블이 있는지 확인하는 것입니다. 실행 당 100 개의 테이블을 생성하는 경우 1000 개의 실행 후 100,000 개의 테이블이 있습니다. 단일 데이터베이스에서 많은 테이블을 작성하는 데 많은 경험이 없지만 데이터베이스 스키마를 추적하는 시스템 테이블의 한계를 압박하고있을 수 있습니다. 이 경우 둘 이상의 데이터베이스에 테이블을 분산 시키면 이점을 볼 수 있습니다 (이 데이터베이스는 모두 동일한 SQL Server 인스턴스 내에있을 수 있습니다).

일반적으로 SQL 프로파일 러 도구는 느린 쿼리를 찾는 가장 좋은 시작점입니다.각 SQL 배치의 CPU 및 IO 비용을 나타내는 데이터 열이 있습니다.이 열은 최악의 범죄자를 가리켜 야합니다. 문제 쿼리를 찾았 으면 쿼리 분석기를 사용하여 각 쿼리에 대한 쿼리 계획을 생성하고 느리게 만드는 것을 알 수 있는지 확인하십시오. 질의 창을 열고, 질의를 입력하고, Ctrl + L을 눌러이 작업을 수행하십시오. 느려질 수있는 것에 대한 완전한 논의는 전체 책을 채울 것이지만 찾을 수있는 좋은 점은 테이블 스캔 (대형 테이블의 경우 매우 느림)과 비효율적 인 조인입니다.

결국 쿼리를 다시 작성하여 간단하게 향상 시키거나 테이블 스키마를보다 광범위하게 변경해야 할 수도 있습니다. 예를 들어, 1000 개가 아닌 실행 당 하나 또는 몇 개의 테이블 만 생성하는 방법이있을 수 있습니다. 특정 설정에 대한 자세한 내용은보다 자세한 답변을 제공하는 데 도움이됩니다. 당신이 실제로 당신이 새로운 SQL 테이블을 만드는 것을 의미합니까,

http://www.sql-server-performance.com/

0

논리적이지만 물리적 인 드라이브가 아닌 별도의 드라이브에 배치하면 IO가 너무 느려지지 않습니다.

0

다른 물리적 드라이브에있는 파일 그룹이 가장 큰 성능 향상을 제공하며 인덱스 쓰기 위치를 분할하여 테이블 쓰기 및 색인 액세스가 다른 디스크에 적용되도록 할 수 있습니다. 파티셔닝으로 할 수있는 일은 많지만, 일반적인 개념은 속도에 가장 큰 영향을주는 부분입니다.

0

성능에 도움이 될 수 있습니다. 특정 테이블/요소를 디스크의 개별 파일 영역/부분으로 이동합니다. 이것은 어느 정도까지 다맥에 영향을 미치는 외부 단편화의 양을 줄일 수 있습니다.

또한 쿼리가 왜 느려지는지 확인하기 위해 tracesql과 같은 다른 요소를 살펴볼 것입니다. 쿼리 통계, SP 재 컴파일 등의 다른 요인이있을 수 있으며 수정하기가 쉽고 성능이 향상 될 수 있습니다.

1

약 1000 개 정도? 단일 행 쓰기? 여러 행 트랜잭션? 삭제 하시겠습니까?

일반적인 팁은 별도의 물리적 드라이브에 데이터 파일과 로그 파일을 배치하는 것입니다. SQL Server는 로그에 대한 모든 기록을 추적하므로 다른 드라이브에있는 사용자가 전반적인 성능을 향상시켜야합니다.

그러나 SQL Server 튜닝은 응용 프로그램이 실제로 수행하는 작업에 따라 달라집니다. 일반적인 팁이 있지만 자신의 취향을 측정해야합니다.

1

당신이 실행 당 약 100 테이블을 이야기 할 때 :

또한 빠르게 일을하는 방법에 대한 도움말을 많이이 웹 사이트를 추천합니다 ? 그렇다면 응용 프로그램의 아키텍처가 문제가 될 수 있다고 생각합니다. 동일한 수의 테이블을 여러 번 재사용하고 단순히 열 또는 두 개를 추가하여 실행을 구분하는 것과 달리 많은 새 테이블이 필요한 상황을 상상할 수 없습니다.

이미 동일한 테이블 그룹을 다시 사용하고 있고 새로운 실행이 이러한 테이블의 추가 행을 의미하는 경우 새로운 데이터가 시간 경과에 따라 여러 가지 방법 중 하나를 사용하여 성능이 저하되는 것일 수 있습니다. 예를 들면 다음과 같습니다.

  1. 테이블/인덱스는 잠시 후 조각화 될 수 있습니다. 모든 테이블에 클러스터형 인덱스가 있는지 확인하십시오. sys.DM_DB_INDEX_PHYSICAL_STATS를 사용하여 조각화를 확인하고 조각 모음을 수행해야하는 경우 REBUILD 옵션을 사용하여 ALTER INDEX를 실행합니다.
  2. 테이블이 너무 커서 테이블에 작은 테이블이 비효율적이 될 수 있습니다. 성능을 향상 시키려면 테이블에 적절한 인덱스를 조사하십시오.
  3. SQL Server는 쿼리 계획 (특히 저장 프로 시저)을 캐시하지만 쿼리 계획이 더 이상 적절하지 않을 수있는 시간이 지남에 따라 테이블의 데이터가 크게 변경되는 경우. 저장 프로 시저가 필요한지 보려면 sp_recompile을 살펴보십시오.

# 2는 현실 세계에서 가장 자주 볼 수있는 범인입니다. 개발자는 작은 테스트 데이터 세트 만 사용하여 개발하는 경향이 있으며 적절한 인덱싱을 간과하는 경향이 있습니다. 20 행의 테이블로 거의 모든 것을 수행 할 수 있기 때문에 빠른 속도로 보입니다.

희망이

0

분할에게 별도의 물리적 드라이브에 걸쳐 테이블을하는 데 도움이됩니다. 디스크 IO가 많다면 괜찮은 IO 솔루션이 필요합니다. Raid 10, 빠른 디스크, 로그 및 DB를 별도의 드라이브로 분할합니다.

아키텍처를 다시 검사하십시오. 여러 데이터베이스를 사용할 수 있습니까? 이동 중에 테이블을 1000 개 작성하면 이전에는 처리하지 못한 몇 가지 흥미로운 병목 현상이 발생합니다. 여러 DB가이를 해결해야합니다. 모든 주요 메타 데이터를 포함하는 "제어"데이터베이스 하나와 실제 데이터가 포함 된 위성 DB를 생각해보십시오.

서버 사양에 대해서는 언급하지 않았지만 8GB에서 20GB RAM으로 갈 때 성능이 크게 향상되었습니다.

관련 문제