데이터베이스가 너무 커져 현재 몇 가지 성능 문제가 있습니다. 지난 10 년 동안 저장된 데이터가 있으며 2 년이 지난 데이터를 새 데이터와 동일한 테이블에 저장해야하는 이유는 알 수 없습니다.

데이터베이스 관리에 대한 심오한 경험이 없기 때문에 오래된 데이터를 보관하는 가장 좋은 방법을 찾고 있습니다.

정보

• 데이터베이스에는 총 310'000'000 개의 레코드가 있습니다.

• 데이터베이스는 하드 디스크에 250GB가 필요합니다.

• 서버 버전은 호환성 수준이 SQL Server 2005 (90) 인 SQL Server 2008이지만 곧 SQL Server 2012로 업그레이드 할 계획입니다.

두 가지 가능성에 대해 생각했습니다.

새로운 데이터베이스

프로덕션 서버의 데이터베이스와 유사한 데이터베이스를 작성하고 모든 이전 데이터를 새 데이터베이스에 삽입하십시오.

• 단점 : 우리 환경에서는 연결된 서버를 사용할 수 없으므로 필요한 경우 기존 데이터를 결합하기가 어렵습니다.

역사 스키마

프로덕션 데이터베이스에서와 동일한 테이블을 사용하여 새 스키마 fe [hist] 를 작성하십시오 . 이 새 테이블의 모든 이전 데이터를 새 스키마에 삽입하십시오.

• 장래에 오래된 데이터가 필요한 경우 쉽게 결합

• 다른 솔루션 중 하나를 선호합니까?
  • 왜?
• 더 나은 가능성이 있습니까?
• 이 작업을 쉽게 수행 할 수있는 기존 도구가 있습니까?
• 다른 생각?

미리 감사드립니다

편집하다

추가 질문 :

새로 생성 된 아카이브 테이블에도 기본 / 외래 키가 필요합니까?

아니면 열이 있어야하지만 키 / 제약 조건이 없어야합니까?

많은 질문에 대한 대답은 그것이 달려 있다고 생각합니다. 어떤 성능 문제가 있습니까? 데이터베이스 크기가 250GB로 증가하는 것만으로도 성능 문제가 발생하는 것은 드문 일입니다.

아마도 날짜 범위의 작은 부분 (예 : 작년) 만 필요한 경우에도 쿼리가 전체 팩트 테이블에서 테이블 스캔을 수행하고 있습니까? 최적화해야 할 특정 쿼리가있는 경우 스키마, 쿼리 및 실제 실행 계획을 다른 질문에 게시하여 최적화 할 수 있는지 확인하십시오.

다른 솔루션 중 하나를 선호합니까?

나는 일반적으로 히스토리 데이터베이스를 선호하며 Guy는 이에 대한 충분한 이유를 그의 응답으로 설명한다고 생각 합니다.

히스토리 데이터베이스의 주요 단점 (스키마가 아닌)은 더 이상 아카이브 테이블에 외래 키를 사용할 수 없다는 것입니다. 이것은 당신에게 좋을지 모르지만 알고 있어야 할 것입니다.

이 접근 방식에 대해 나열된 단점은 정확하지 않습니다. 동일한 서버의 여러 데이터베이스에서 쉽게 쿼리 할 수 ​​있으며 쿼리 최적화 프로그램은 일반적으로 데이터베이스 간 쿼리를 잘 처리합니다.

더 나은 가능성이 있습니까?

아카이브 데이터를 정기적으로 쿼리 해야하는 경우 날짜별로 테이블을 분할하는 것이 좋습니다. 그러나 이는 긍정적 (예 : 파티션 제거,보다 효율적인 데이터로드) 및 부정 (예 : 느린 싱글 톤 탐색, 병렬 쿼리에서 스레드 왜곡 가능성)과 같은 많은 성능 영향을 초래할 수있는 큰 변화입니다. 따라서 데이터베이스를 많이 사용한다면이 결정을 가볍게 내리지 않을 것입니다.

새로 생성 된 아카이브 테이블에도 기본 / 외래 키가 필요합니까? 아니면 열이 있어야하지만 키 / 제약 조건이 없어야합니까?

제공하는 데이터 무결성 이점을 얻을 수 있도록 최소한 기본 키와 고유 인덱스를 사용하는 것이 좋습니다. 예를 들어, 실수로 1 년 간의 데이터를 기록 테이블에 두 번 삽입하는 것을 방지 할 수 있습니다. 또한 부수적 인 이점으로 히스토리 테이블을 쿼리해야 할 경우 성능이 향상 될 수 있습니다.

다른 생각?

Enterprise Edition을 사용하고 SQL 2008+로 업그레이드 할 계획이므로이 테이블의 데이터 압축 을 고려할 수 있습니다 . 압축하면 디스크 공간이 확실히 줄어들지 만 서버의 디스크 및 CPU 리소스에 따라 디스크 I / O를 줄이고 메모리 사용률을 개선하여 읽기에 대한 쿼리 성능을 향상시킬 수 있습니다 (한 번에 더 많은 데이터를 캐시에 맞음).

나는 하루 종일 연결된 서버를 통해 히스토리 스키마 또는 두 번째 히스토리 데이터베이스를 선호합니다. 라이센스 비용을 절약하고 관리 및 쿼리하기가 더 쉽습니다. 그런 다음 더 간단한 스키마를 사용하고 일부 인덱스를 삭제하여 데이터베이스를 더 작게 만들 수도 있습니다.

그러나 Enterprise Edition이 있으므로 테이블 을 분할 하는 세 번째 옵션이 있습니다.이 옵션을 사용하면 데이터를 쉽게 보관하고 이전 데이터를 쿼리하는 것이 사용자에게 투명하므로 응용 프로그램을 변경할 필요가 없습니다. .

내 경험상 두 번째 데이터베이스가 두 가지 이유로 선호되는 선택입니다.

1. 기록 백업에서 데이터를 복원 한 다음 필요하지 않은 테이블과 인덱스를 삭제할 수 있습니다.
2. 보고 목적으로이 서버를 다른 서버로 옮길 수 있습니다. 이는 기본 서버의 리소스를 사용하지 않는 이점이 있습니다

여전히 기본 데이터베이스에서 모든 히스토리 데이터를 삭제해야하지만이를 예약 할 수 있습니다.

내가 시간을 보내는 곳이 아니기 때문에 지금 라이센스를 무시합니다.

IMHO, 아카이브 데이터베이스 는 구현 및 유지 관리 가 가장 간단 합니다. 그것들은 별개로 느슨하게 연결된 실체입니다. 데이터 이동 및로드 / 리소스 제어에는 명확한 경계가 있습니다. 더 나은 성능 관리를 위해 다른 인스턴스 또는 서버로 쉽게 이동할 수 있으며 비용은 큰 문제가 아닙니다. 가장 간단한! = 가장 저렴하거나 최소한의 노력입니다. 실제로 상당히 많은 작업이 있지만 두 가지 중요한 예외가있는 간단한 작업입니다.

1. 제약 조건 적용-SQL Server의 데이터베이스 간 제약 조건과 같은 것은 없으므로 거래 차단기인지 결정해야합니다.
2. 데이터베이스 간 쿼리는 더 이상 사용되지 않는 OLEDB에 여전히 의존하는 분산 쿼리를 사용합니다. 즉, 새로운 데이터 유형에 문제가있을 수 있으며 성능 문제가 발생하면 문제가 해결되지 않을 수 있습니다.

아카이브 스키마 또는 단지 아카이브 테이블 은 구현하기가 다소 복잡하지만 사용하기가 훨씬 쉽습니다. 동일한 데이터베이스에있는 모든 개체는 액세스 제어를 복제하고 유지 관리 할 필요가 없음을 의미합니다. 더 쉬운 성능 조정, 모니터링, 문제 해결 등을위한 교차 데이터베이스 쿼리가 없습니다.

테이블 파티셔닝 은 훌륭한 솔루션이며 아카이브 테이블 / 스키마의 많은 이점을 제공하지만 사용자 / 쿼리에 투명성을 제공합니다. 즉, 구현하기가 가장 복잡하고 초보자에게는 쉽지 않은 지속적인 치료가 필요합니다.

몇 가지 중요한 고려 사항 :

• 쿼리가 기록 / 콜드 데이터를 정기적으로 반환합니까? 콜드 데이터에 자주 액세스하지 않습니까?
• 히스토리 데이터가 변경 불가능합니까, 아니면 정기적으로 업데이트 / 삭제됩니까?
• 310m 행은 행 크기에 따라 "중간"입니다 (1 개의 테이블에서 모두 가정). 행 크기 데이터가 있습니까? 그 310m 행은 몇 GB입니까?
• 그 테이블의 성장률은 얼마입니까?
• 애플리케이션 코드 및 해당 SQL 쿼리를 수정할 수 있습니까?

이들은 선택한 솔루션에 상당한 영향을 미치거나 특정 솔루션을 허용하지 않을 수도 있으므로 고려해야 할 중요한 사항입니다. 예를 들어, 내역 데이터가 정기적으로 (일주일에 한 번 이상) 수정 / 업데이트되는 경우 별도의 데이터베이스를 사용하면 해당 쿼리에 DTC를 사용하거나 트랜잭션 안전성을 수동으로 관리해야합니다 (항상 정확한 것은 아닙니다). 변경 불가능한 과거 데이터보다 비용이 훨씬 높습니다.

또한 업그레이드를 생각하고 있다면 2016 및 새로운 스트레치 데이터베이스 기능 ( https://msdn.microsoft.com/en-us/library/dn935011.aspx)을 고려 하십시오.

다음과 같은 이유로 데이터베이스를 별도의 논리 데이터베이스로 분할하는 것이 좋습니다.

1. 자원 요구 사항

이것을 별도의 데이터베이스로 분리하여 다른 드라이브에 저장하고 주 생산 데이터와 다른 속도로 모니터링 할 수 있습니다.

2. 성능

데이터를 별도의 데이터베이스로 분할하면 기본 프로덕션 데이터베이스의 크기가 줄어들어 전반적인 성능을 향상시킵니다.

3. 간단한 백업

아카이브 된 데이터 백업은 기본 SQL 데이터베이스의 '실시간 / 현재'레코드만큼 필수적인 것으로 간주되지 않을 수 있습니다. 이는 보관 된 데이터가 덜 자주 백업 될 수 있음을 의미 할 수 있습니다. 또한 아카이브 된 데이터가 기록되는 방식의 순차적 특성으로 인해 아카이브 된 데이터베이스의 섹션을 한 번 백업 한 다음 다시는 백업하지 않을 수 있습니다. 예를 들어 아카이브 데이터가 2014 년 변경 아카이브 데이터베이스에 작성된 후에는 해당 데이터가 다시 변경되지 않습니다.

참고 : 귀하의 많은 질문에 대한 답변은 모두 귀하의 상황, 데이터의 성격 및 발생한 성능 문제에 달려 있다고 생각합니다.