SQL Server의 데이터 압축(COMPRESSION). 쿼리 성능이 좋지 않습니다. Management Studio를 사용하여 데이터베이스 압축

많은 관리자 마이크로소프트 SQL서버는 데이터베이스 및 트랜잭션 로그 파일의 물리적 크기가 크게 증가했으며 물론 하드 디스크의 여유 공간 증가와 관련된 조치를 취하지 않기 위해 어떤 방식으로든 이 크기를 줄이고자 합니다. 데이터베이스 및 트랜잭션 로그 파일의 물리적 크기를 줄이는 방법 SQL 서버이다 - 이다 압축.

Microsoft SQL Server의 압축이란 무엇입니까?

압축데이터베이스 및 트랜잭션 로그 파일에서 사용하지 않는 공간을 제거하는 프로세스입니다.

데이터베이스 파일의 물리적 크기는 시간이 지남에 따라 증가하는데, 이는 데이터 추가로 인한 것이지만 삭제될 때 파일의 물리적 크기는 변경되지 않지만 이러한 파일에는 논리적으로 사용되지 않은 공간이 나타나며 삭제할 수 있습니다.

압축의 효과는 데이터베이스에서 테이블을 삭제하거나 테이블에서 데이터를 삭제하는 작업 후에 압축 작업을 수행할 때 이루어집니다.

트랜잭션 로그 축소와 트랜잭션 로그 잘라내기를 구분해야 합니다. 축소는 사용하지 않는 공간을 제거하여 물리적 로그 크기를 줄이는 것이고, 자르기는 논리 로그에서 재사용을 위해 공간을 확보하는 것입니다( 저것들. 사용하지 않는 공간이 생성됨) 실제 파일의 크기를 줄이지 않고 트랜잭션 로그.

트랜잭션 로그는 자동으로 잘립니다.

단순 복구 모델에서 - 도달 후 검문소예를 들어 다음과 같은 경우에 발생할 수 있습니다. 백업 생성 CHECKPOINT 문이 명시적으로 실행되거나 논리적 트랜잭션 로그의 크기가 70% 차면 이러한 모든 경우에 로그의 비활성 부분이 자동으로 지워집니다. 잘림;
모델에서 완전한 회복또는 대량 로그 복구 모델에서 마지막 로그 백업 이후 체크포인트에 도달한 경우 로그 백업 이후.

전체 복구 모델 또는 대량 로그 복구 모델을 사용 중이고 트랜잭션 로그 파일이 너무 큰 경우 오랫동안 BACKUP을 수행하지 않았을 가능성이 큽니다( 지원) 트랜잭션 로그. 안에 이 경우트랜잭션 로그를 먼저 백업한 다음 트랜잭션 로그를 압축해야 합니다. 이에 대해서는 아래에서 설명합니다.

트랜잭션 로그 파일이 너무 클 수도 있습니다( 단순 복구 모델과 전체 복구 모델 모두에서) 절단 절차의 지연으로 인해, 즉 로그의 크기는 주로 로그의 활성 부분으로 구성되며 활성 부분은 자를 수 없으므로 로그의 물리적 크기가 커집니다. 자르기 대기 시간은 활성 장기 실행 트랜잭션, 일부 미러 데이터베이스 및 트랜잭션 로그 매핑 시나리오, 일부 트랜잭션 및 트랜잭션 로그 복제 시나리오와 같은 요소의 영향을 받으며 작업 중에는 로그 자르기가 불가능합니다. 예약 사본및 데이터 복구. 이 경우 지연의 원인을 제거한 다음 잘라야 합니다( 저것들. 예를 들어 전체 로그 BACKUP 복구 모델의 경우), 그런 다음 허용 가능한 크기로 압축됩니다.

일반적으로 특정 빈도로 지속적으로 생성되는 경우 백업트랜잭션 로그 또는 데이터베이스( 간단한 복구 모델로), 트랜잭션 로그 파일이 커지지 않고 트랜잭션 로그 오버플로가 없습니다.

MS SQL Server에서 데이터베이스를 축소하는 방법은 무엇입니까?

다음을 사용하여 데이터베이스 및 트랜잭션 로그 파일을 압축할 수도 있습니다. GUI Management Studio 및 Transact-SQL 문 사용: DBCC 축소 데이터베이스그리고 DBCC 축소 파일. AUTO_SHRINK 데이터베이스 옵션을 ON으로 설정하여 데이터베이스가 자동으로 축소되도록 설정할 수도 있습니다.

메모! Microsoft SQL Server 2016 Express의 예를 사용하여 데이터베이스 압축을 고려하겠습니다..

Management Studio를 사용하여 데이터베이스 압축

Management Studio를 시작하고 개체 브라우저에서 " 데이터 베이스". 그런 다음 클릭합니다. 마우스 오른쪽 버튼으로 클릭압축해야 하는 데이터베이스에 마우스를 놓고 " 작업 -> 압축 -> 데이터베이스(또는 파일, 예를 들어 트랜잭션 로그만 압축하면 되는 경우)". 예를 들어 " 데이터 베이스».

결과적으로 창 " 데이터베이스 압축”, 그건 그렇고 데이터베이스의 크기와 사용 가능한 자유로운 장소, 제거할 수 있습니다( 저것들. 짜내다). 누르다 " 좋아요».

일정 시간이 지나면 데이터베이스 크기에 따라 압축이 완료됩니다.

SHRINKDATABASE 및 SHRINKFILE 명령을 사용하여 데이터베이스 축소

MS SQL Server에는 데이터베이스 및 트랜잭션 로그 파일의 압축을 수행하기 위한 두 가지 명령 SHRINKDATABASE 및 SHRINKFILE이 있습니다.

DBCC 축소 데이터베이스데이터베이스를 압축하는 명령입니다.
DBCC 축소 파일– 이 명령을 사용하여 일부 데이터베이스 파일을 압축할 수 있습니다( 예를 들어 트랜잭션 로그만).

데이터베이스를 압축하려면( 예: TestBase) 조금 전에 Management Studio에서 했던 것처럼 아래 지침을 따르십시오.

DBCC SHRINKDATABASE(N"TestBase")

SHRINKDATABASE에는 다음과 같은 옵션이 있습니다.

database_name 또는 database_id는 압축할 데이터베이스의 이름 또는 ID입니다. 값을 0으로 지정하면 현재 데이터베이스가 사용됩니다.
target_percent - 압축 후 데이터베이스에 남아 있어야 하는 여유 공간(백분율)입니다.
NOTRUNCATE 할당된 페이지를 파일 끝에서 파일 시작 부분의 할당되지 않은 페이지 위치로 이동하여 파일의 데이터를 압축합니다. 지정된 경우 주어진 매개변수, 파일의 실제 크기는 변경되지 않습니다.
TRUNCATEONLY - 파일 끝의 모든 여유 공간을 비웁니다. 운영 체제, 하지만 파일 내에서 페이지를 이동하지는 않습니다. 데이터 파일은 마지막으로 할당된 범위까지만 축소됩니다. 이 매개변수를 지정하면 target_percent 매개변수가 처리되지 않습니다.
WITH NO_INFOMSGS - 심각도 수준이 0에서 10인 모든 정보 메시지를 억제합니다.

SHRINKDATABASE 구문

DBCC SHRINKDATABASE (database_name | database_id | 0 [ , target_percent ] [ , ( NOTRUNCATE | TRUNCATEONLY ) ]) [ WITH NO_INFOMSGS ]

트랜잭션 로그만 압축하려면 다음을 사용할 수 있습니다. SHRINKFILE 명령어, 예를 들어.

DBCC 축소 파일(N"TestBase_log")

이 경우 로그 파일을 압축합니다( TestBase_log는 트랜잭션 로그 파일의 이름입니다.), 초기 값, 즉 기본값으로. 파일을 특정 크기로 압축하려면 두 번째 매개변수로 크기(MB)를 지정합니다. 예를 들어, 다음 명령트랜잭션 로그 파일의 크기를 5MB로 줄입니다.

DBCC SHRINKFILE(N"TestBase_log", 5)

파일에 데이터를 저장하는 데 필요한 크기보다 작은 크기를 지정하면 파일이 이 크기로 압축되지 않는다는 점도 유의해야 합니다. 예를 들어, 5MB를 지정하고 파일에 데이터를 저장하는 데 7MB가 필요한 경우 파일은 7MB로만 압축됩니다.

SHRINKFILE에는 NOTRUNCATE 및 TRUNCATEONLY 옵션도 있습니다.

SHRINKFILE 구문

DBCC SHRINKFILE (( file_name | file_id ) ( [ , EMPTYFILE ] | [ [ , target_size ] [ , ( NOTRUNCATE | TRUNCATEONLY ) ] ] )) [ WITH NO_INFOMSGS ]

데이터베이스 축소 작업으로 인해 인덱스 조각화가 발생하고 데이터베이스 속도가 느려질 수 있습니다. 따라서 데이터베이스를 너무 자주 압축하는 것은 권장되지 않습니다.
인덱스 재구축 작업 전에 데이터베이스를 압축하는 것이 좋습니다. 압축 후 인덱스 재구축 절차를 시작합니다.
AUTO_SHRINK 데이터베이스 옵션( 자동 압축) ON으로 설정하지 않고 기본적으로 그대로 두는 것이 좋습니다. 물론 이에 대한 충분한 이유가 없는 한 OFF에서;
SHRINKDATABASE 문은 데이터베이스 크기를 초기 크기보다 작은 크기로 줄이는 것을 허용하지 않습니다. 최저한의. 그러나 SHRINKFILE 명령어는 이 작업을 수행할 수 있습니다( 두 번째 매개변수에 최소 크기보다 작은 크기를 지정합니다.). 최소 데이터베이스 크기는 DBCC SHRINKFILE 또는 ALTER DATABASE와 같은 데이터베이스 크기 조정 작업을 통해 데이터베이스를 만들거나 명시적으로 설정할 때 지정된 크기입니다. 예를 들어 데이터베이스가 10MB 크기로 생성된 후 100MB로 증가한 경우 데이터베이스에서 모든 데이터가 삭제된 경우에도 SHRINKDATABASE를 사용하여 처음 10MB까지만 압축할 수 있습니다.
데이터베이스 및 트랜잭션 로그 파일이 백업되는 동안에는 압축할 수 없습니다. 반대로 데이터베이스와 트랜잭션 로그는 압축되는 동안 백업할 수 없습니다.
NOTRUNCATE 또는 TRUNCATEONLY 옵션을 지정하지 않고 DBCC SHRINKDATABASE를 실행하는 것은 TRUNCATEONLY 옵션을 사용하여 DBCC SHRINKDATABASE를 실행한 후 NOTRUNCATE 옵션을 사용하여 DBCC SHRINKDATABASE를 실행하는 것과 같습니다.
데이터베이스를 축소하는 과정에서 사용자는 데이터베이스에서 작업할 수 있습니다( 저것들. 데이터베이스를 단일 사용자 모드로 전환할 필요가 없습니다.);
완료된 모든 작업이 저장되는 동안 언제든지 SHRINKDATABASE 및 SHRINKFILE 작업을 수행하는 프로세스를 중단할 수 있습니다.
축소 절차를 시작하기 전에 데이터베이스 파일에 삭제할 여유 공간이 있는지 확인하십시오. 다음 쿼리를 실행하여 파일을 전혀 압축할 수 있습니까( 데이터베이스 파일을 얼마나 줄일 수 있는지 메가바이트 단위로 표시됩니다.).

SELECT 이름 AS 이름 파일, 크기/128.0 - CAST(FILEPROPERTY(이름, "SpaceUsed") AS INT)/128.0 AS AvailableSpaceInMB FROM sys.database_files;

데이터베이스 압축 절차를 수행하려면 sysadmin 서버 역할 그룹 또는 db_owner 데이터베이스 역할 그룹의 구성원이어야 합니다.

데이터베이스 및 트랜잭션 로그 파일을 압축하는 것은 다소 리소스를 많이 사용하는 프로세스입니다. 일정 금액시간 ( 파일 크기에 따라), 그래서 이 절차절대적으로 필요한 경우에만 계획하고 일반적으로 수행해야 합니다( 예를 들어, 데이터베이스 및 로그의 크기가 너무 커지고 단일 파일의 절반 이상이 사용되지 않는 공간을 차지합니다.).

그게 다야, 기사가 당신에게 도움이 되었기를 바랍니다. 행운을 빕니다!

이 기사의 목적은 1C의 클라이언트-서버 버전 사용자가 좀 더 "고급" 기술을 사용하여 데이터베이스 롤업을 수행하지 못하도록 "단념"시키는 것입니다.

1) 데이터베이스 크기 증가

2) 쿼리 성능 저하

3) 이용자의 업무를 방해하는 다량의 "불필요한 데이터"

II) 문제에 대한 "기술적" 솔루션

c) 데이터베이스 테이블 압축

d) 데이터베이스 테이블 분할

안에 현대적 조건때때로 "1C 데이터베이스를 축소해야 합니다. 볼륨이 50GB를 초과합니다"라는 말을 듣는 것은 매우 이상합니다. SAP R3 시스템이나 Oracle e Business Suite 또는 심지어 MS Dynamics Ax의 관리자가 이 작업을 수행했다면 아마 해고되었을 것입니다. 그러나 1C의 경우 이것은 "표준 관행"입니다.

파일 버전의 경우 이야기는 데이터베이스 크기가 2GB로 제한되는 버전 1C 7.7로 거슬러 올라갑니다. 이제 2GB 제한은 테이블 크기에만 해당되며 파일 크기는 이미 매우 작을 수 있습니다. 사실, 데이터베이스가 그러한 크기로 성장했다면 아마도 데이터가 거기에 적극적으로 입력되었을 것입니다. 클라이언트-서버에 대해 생각해야 할 수도 있습니까?

실제로 이 기사의 목적은 좀 더 "고급" 기술을 사용하여 1C 클라이언트-서버 버전 사용자가 데이터베이스 롤업을 수행하지 못하도록 "단념"시키는 것입니다.

I) DB 롤업으로 해결하려는 문제

1) 데이터베이스 크기 증가

실제로 주요 질문: 데이터베이스 크기를 줄이는 이유는 무엇입니까?

수학을 해봅시다:

섬기는 사람 HDD 500GB의 경우 약 10조입니다. 안정성을 위해 RAID 1에 결합하면 20조가 됩니다.

당연히 새로운 공간이 부족하다는 문제가있을 수 있습니다. 하드 디스크서버에서...

그리고 외부 디스크 어레이를 구입하는 것이 그리 저렴하지 않을 것입니다. 무엇을 해야 합니까?

예, 모든 것이 간단합니다. 데이터베이스 파일을 네트워크 드라이브, 그러나 ~함에 따라? 이 기사에 대해 자세히 알아보십시오.

데이터베이스에 대한 사용 가능 증가 디스크 공간비용은 20조입니다. + 전문 작업 10분. 데이터베이스 롤업에 필요한 전문가의 작업 시간은 몇 시간입니까? 얼마나 많은 다운타임이 발생할 수 있습니까? 가장 겸손한 추정치에 따르면 평균 오류 수가 60GB 인 SCP 컨볼 루션의 경우 컨볼 루션 결과를 확인하는 배치 회계는 동일한 배치 회계를 수정하는 데 30-40,000이 소요됩니다.

범용 처리는 특히 데이터베이스가 실제로 "멈추지 않는" 경우 모든 것을 한 번에 축소하지 않을 것입니다. 어쨌든 배치 회계를 수정하십시오. 일반적으로 많은 작업이 있습니다. 그리고 가장 중요한 것은 최종 확인이 매우 철저해야 하며 오류는 여전히 남아 있습니다...

또한 데이터베이스의 크기가 이미 60이 아니지만 예를 들어 120GB 인 경우 ... 컨볼 루션 중 1C 코드에서 가장 작은 오류가 있고 그게 다입니다 ... 절차가 성공적으로 종료되지 않습니다. 그리고 분명히 실수가있을 것입니다. TK로 작업할 때 "메모리 부족" 및 다음과 같은 오류

http://img180.imageshack.us/img180/656/1c3y.jpg

최종 수치는 구매의 경우 20-25에 대해 최소 30-40 톤입니다. 하드 드라이브, 500GB의 추가 공간을 받습니다.

따라서 http://infostart.ru:8080/public/78934/와 같은 제품이 있습니다.

아마도 좋은 제품이고 목표를 달성합니다. 플랫폼의 버전에 따라 테이블 구조가 변경될 뿐입니다. 1C 우리는 이것에 대해 두 번 이상 들었습니다. 14번째 릴리스에는 데이터 구분 기호가 있었고 그게 다입니다. 14번째 릴리스에 대한 이 처리는 더 이상 적합하지 않을 가능성이 큽니다. 예, 라이선스 계약 위반은 말할 것도없고 왠지 무섭습니다.

그리고 그 이후에도 삭제된 데이터가 "갑자기 필요"한 사용자, 폐쇄된 기간의 문서에서 "순서에 영향을 미치지 않는" 숫자를 "정정하고 싶었던" 사용자가 있을 것입니다. 그리고 누군가가 자신에게만 알려진 목적을 위해 이러한 문서를 지속적으로 보았다는 것이 밝혀지면 더 나쁩니다. 물론 이것들은 모두 작업 방식의 오류에 불과하지만 그럼에도 불구하고 사용자는 불만을 가질 것입니다.

2) 쿼리 성능 저하

글쎄, 누가 "적을수록 빠르다"고 말했습니까? 올바르게 설계된 IS의 경우 이 진술은 사실이 아닙니다.

아래 그림은 간략하게 "새의 언어로" 주소 테이블에 있는 항목의 B-Tree 유형 인덱스에 의한 선택의 가장 간단한 예를 보여줍니다.

특히 모든 것이 다소 복잡하기 때문에 인덱스 주제를 탐구하고 싶지 않습니다. 가장 중요한 것은 검색이 테이블을 통해 "수평"으로 이동하는 것이 아니라 인덱스의 "수준"을 통해 "수직으로" 이동한다는 것입니다.

비유 - 공책: 각 페이지는 고유한 문자로 시작하지만 각 페이지에는 단어의 두 번째 문자를 선택할 수 있는 동일한 노트북도 있으며 하나 이상의 항목이 있는 페이지를 만날 때까지 계속됩니다. 편안한? 물론 연락처가 수백 개 이상이면 편리합니다. 10개만 있다면? 그냥 눈으로 볼 수 있는 종이 한 장에 적어두는 게 쉽지 않나요? 인덱스도 마찬가지입니다. 테이블에 수천 개의 레코드가 있으면 효과적이지만 하나만 있으면 그다지 많지 않습니다. 다행스럽게도 DBMS는 "쿼리 계획"을 독립적으로 선택하고 특정 인덱스를 사용할지 여부를 결정하는 방법을 배웠습니다. 그러나 인덱스 없이 테이블의 모든 행을 "열거"하는 경우 DBMS는 매우 자주 전체 테이블을 잠그고 IB 롤업 후 "잠금이 어디에서 왔는지 명확하지 않음"을 관찰합니다.

우리는 일반적으로 잔차 테이블을 축소합니다. 잔차 테이블에서 모든 인덱스의 첫 번째 필드는 기간입니다. 즉, 인덱스의 최상위 수준에 있는 쿼리의 경우 필요한 기간 동안 계산된 잔액이 이미 선택됩니다. 따라서 데이터베이스 폴딩은 유해에 대한 쿼리에 최소한의 영향을 미칩니다. 적절한 조직시스템.

3) 이용자의 업무를 방해하는 다량의 "불필요한 데이터"

이에 대해 먼저 사용자에게 뉴스레터를 만듭니다. 또한 "데이터가 불필요하지 않다"는 메시지를 많이 받습니다. 그럼에도 불구하고 많은 사람들이 "과거 기간의 문서보기"와 "보관 된 데이터"를 좋아하지 않으며 동의하지 않을 수 없습니다. 그러나 화해가 이러한 문제를 해결합니까? 명명법 참고서에서 불필요한 명명법을 제거합니까? 더 이상 함께 일하지 않을 상대방? 실습에서 알 수 있듯이 대부분의 문제는 정확히 여기에 있습니다. II) 문제에 대한 "기술적" 솔루션

a) 데이터베이스를 파일 그룹으로 나누기

데이터베이스 목록에서 Management Studio를 열고 필요한 데이터베이스를 선택한 다음 해당 속성을 엽니다.

그림과 같이 "Filegroups" 탭으로 이동하여 다른 파일 그룹을 추가합니다(예제에서는 SECONDARY라고 함).

"파일" 탭으로 이동하여 생성된 파일 그룹을 선택하는 새 파일을 추가합니다. 이 파일은 다른 디스크에 있을 수 있습니다.

이제 예를 들어 처리를 사용하여: http://infostart.ru/public/78049/ 우리는 느린 테이블에 안전하게 "기부"할 수 있는 테이블을 결정합니다. 하나) 미디어. 80/20 규칙이 여기에 적용됩니다. 80%의 작업은 20%의 데이터로 이루어지므로 어떤 플레이트가 급히 필요하고 어떤 플레이트가 덜 필요한지 생각해 보십시오. "추가 정보 저장", 초기 잔액을 입력하기 위한 문서, 더 이상 사용하지 않는 문서는 "느린" 파일 그룹으로 전송할 수 있는 문서로 즉시 정의됩니다.

테이블 인덱스도 이 파일 그룹으로 전송됩니다.

디스크 어레이 전체에 테이블을 배포하기 위한 상당히 편리한 메커니즘 다른 속도. 라이센스 계약이것은 모순되지 않기 때문에 솔루션에서는 데이터 액세스를 사용하지 않으며 정보 베이스 1C 플랫폼 이외의 수단으로. 우리는 이 데이터의 저장을 편리한 방식으로만 구성합니다.

b) 데이터베이스 또는 그 일부를 네트워크 드라이브에 배치

DBCC 추적(1807)

우리는 쓴다 주어진 명령 Management Studio에서는 네트워크를 통해 데이터베이스를 실행하고 성공적으로 생성할 수 있습니다. 물론 이 경우 인스턴스는 SQL 서버도메인을 대신하여 실행해야 합니다. 계정, 이 항목에는 필요한 네트워크 폴더에 대한 권한이 있어야 합니다.

그러나 데이터베이스 작업 중에 네트워크가 끊어지면 이 명령을 사용할 때 매우 주의하십시오. 네트워크가 없는 동안 전체 데이터베이스를 사용할 수 없습니다. 마이크로소프트는 고의로 대량 사용을 위해 이 기회를 마감했습니다. 일반적으로 이 기능은 NAS 스토리지에 데이터베이스를 생성하는 것으로 간주되며 강력하게 권장합니다. 안정적이고 신뢰할 수 있는 것으로 적합 파일 서버, MS SQL DBMS를 실행하는 서버에 직접 연결됩니다.

http://msdn.microsoft.com/en-us/lipary/ms188396.aspx 문서에서 다른 추적 플래그에 대한 자세한 내용을 읽을 수 있습니다.

c) 데이터베이스 테이블 압축

EXEC sp_MSforeachtable "ALTER INDEX ALL ON ? REBUILD WITH (DATA_COMPRESSION = PAGE)" GO

이 코드를 실행하면 데이터베이스의 모든 테이블이 압축됩니다. 물론 테이블을 개별적으로 압축할 수도 있습니다. 그것은 여러분에게 달려 있습니다. 압축을 제공하는 것은 무엇입니까?

디스크 공간 절약

디스크 하위 시스템의 로드 감소

무엇을 소비하고 있습니까? - 프로세서 시간.

따라서 프로세서가 항상 70% 이상 로드되면 압축을 사용할 수 없습니다. CPU 부하가 20-30%이고 디스크 대기열이 3-4로 증가하면 테이블 압축이 "치료제"일 뿐입니다. 데이터베이스 테이블 압축에 대해 자세히 알아보기 - http://msdn.microsoft.com/ru-ru/lipary/cc280449(v=sql.100).aspx

테이블 압축 기능은 SQL Server의 엔터프라이즈 에디션 소유자만 사용할 수 있습니다.

d) 데이터베이스 테이블 분할

물론 테이블을 다른 파일 그룹으로 나누는 것은 괜찮습니다... 하지만 여기에 두 개의 테이블이 있다고 말할 것입니다... 2005년부터 진행되어 왔으며... 이미 12GB를 차지하고 있습니다. 모든 데이터가 있었습니다. 예 별도의 디스크넣어 현재를 둡니다.

당신은 믿지 않을 것이지만 이것은 매우 간단하지는 않지만 가능합니다.

날짜별로 분할 함수를 만듭니다. 파티션 함수 생성 YearSection(datetime)

values("20110101")에 대한 범위 오른쪽으로;

2011년 이전의 모든 것은 한 섹션으로, 그 이후의 모든 것은 다른 섹션으로 분류됩니다.

파티셔닝 스키마 생성

파티션 구성표 YearScheme 생성

(SECONDARY, PRIMARY)에 대한 파티션 YearSection으로;

이를 통해 11년까지의 모든 데이터는 "Secondary" 파일 그룹에 속하고 이후에는 "Primary"에 속한다고 말합니다.

그림에서 선택할 수 없음을 알 수 있습니다. 모든 것이 정확합니다. 테이블 파티셔닝은 MS SQL Server의 Enterprise 에디션에서만 가능합니다.. 클러스터 인덱스는 구분하기 쉽습니다 - 괄호가 있는 그림입니다. 발사체 및 모든 1C 객체의 경우 생성됩니다. PH의 경우 기간별로 클러스터링된 인덱스가 항상 있습니다. 문서 및 디렉토리의 경우 섹션 분할에 대한 세부 정보를 포함하는 다른 파일을 만드는 것이 좋을 것입니다. 그러나 이것은 이미 라이센스 계약을 위반하는 것입니다.

2) 쿼리 성능 저하 문제

위에서 설명한 모든 작업은 기본 쿼리 속도에 영향을 미치지 않아야 합니다. 게다가, 사용 파일 그룹테이블 섹션을 사용하면 가장 자주 사용되는 데이터를 빠른 디스크 어레이에 배치하고 디스크 어레이의 구성을 변경하고 작은 I/O 가속기를 사용할 수 있습니다. 따라서 쿼리 실행 속도는 증가할 뿐입니다. 그리고 테이블 압축을 사용하면 디스크 하위 시스템이 병목 상태인 경우 추가로 오프로드할 수 있습니다. 일반적으로 쿼리 실행 속도에 대해 이야기하면 실행 계획 분석, 유능한 인덱스 사용을위한 쿼리 최적화는 MS SQL 수준의 모든 "트릭"보다 훨씬 더 중요한 성능 향상을 제공합니다.

3) 문제 대용량사용자 경험을 방해하는 "정크 데이터"

그러나이를 위해 받침대를 접을 필요는 없지만 다음을 수행하십시오.

a) 모든 사람에게 선택 사용 방법, 저장 방법, 로그 간격 사용 방법, 저장 방법을 설명하십시오.

b) 의미론적 부하(많이 작업하지 않는 계약자 및 명명법)가 없는 경우 불필요한 데이터를 삭제하도록 표시합니다. 이렇게 하면 컨볼루션보다 사용자에게 더 많은 이점이 있습니다. 리소스가 있는 경우 사용하지 않는 개체 삭제를 위한 자동 표시를 설정하고 기본적으로 표시되지 않도록 프로그램 코드에서 기본 선택을 합니다. 사용자가 필요로 하는객체 - 삭제 표시됨

c) 다른 유용한 "기본 선택"을 설정합니다. 예를 들어 각 관리자는 기본적으로 자신의 문서만 볼 수 있습니다. 그리고 그가 "동지"의 문서를보고 싶다면 선택을 해제해야합니다.

선택과 관련된 모든 세부 사항에 대해 "추가 주문이 있는 인덱스" 플래그를 설정하는 것을 잊지 마십시오. 그러면 이러한 "편의성"이 시스템 성능에 영향을 미치지 않습니다.

현대적인 상황에서 때때로 "1C 데이터베이스를 축소해야 합니다. 볼륨이 50GB를 초과합니다."라는 말을 듣는 것은 매우 이상합니다. SAP R3 시스템이나 Oracle e Business Suite 또는 심지어 MS Dynamics Ax의 관리자가 이 작업을 수행했다면 아마 해고되었을 것입니다. 그러나 1C의 경우 이것은 "표준 관행"입니다.

하드 드라이브를 구입하고 500GB의 추가 공간을 확보하면 최종 수치는 20-25에 대해 적어도 30-40톤으로 밝혀졌습니다.

그래서 이런 제품들이 있습니다
아마도 좋은 제품이고 목표를 달성합니다. 플랫폼의 버전에 따라 테이블 구조가 변경될 뿐입니다. 1C 우리는 이것에 대해 두 번 이상 들었습니다. 14번째 릴리스에는 데이터 구분 기호가 있었고 그게 다입니다. 14번째 릴리스에 대한 이 처리는 더 이상 적합하지 않을 가능성이 큽니다. 예, 라이선스 계약 위반은 말할 것도없고 왠지 무섭습니다.

- 데이터베이스 목록에서 Management Studio를 열고 필요한 데이터베이스를 선택한 다음 해당 속성을 엽니다.
- 그림과 같이 "Filegroups" 탭으로 이동하여 다른 파일 그룹을 추가합니다(예제에서는 SECONDARY라고 함).

- "파일" 탭으로 이동하여 생성된 파일 그룹을 선택하는 새 파일을 추가합니다. 이 파일 다른 디스크에 있을 수 있음

- 예를 들어 이제 처리를 사용하여 더 느린 미디어에 안전하게 "기부"할 수 있는 테이블을 결정합니다(물론 모든 것을 느린 미디어에, 나머지는 더 빠른 미디어에). 80/20 규칙이 여기에 적용됩니다. 80%의 작업은 20%의 데이터로 이루어지므로 어떤 플레이트가 급히 필요하고 어떤 플레이트가 덜 필요한지 생각해 보십시오. "추가 정보 저장", 초기 잔액을 입력하기 위한 문서, 더 이상 사용하지 않는 문서는 "느린" 파일 그룹으로 전송할 수 있는 것으로 즉시 정의됩니다.

다른 파일 그룹으로 이동해야 하는 테이블을 선택합니다. 테이블(프로젝트) 변경 메뉴를 선택하고 속성에서 파일 그룹을 변경합니다.

테이블 인덱스도 이 파일 그룹으로 전송됩니다.
서로 다른 속도의 디스크 배열에 테이블을 배포하는 매우 편리한 메커니즘입니다. 이것은 라이센스 계약에 위배되지 않습니다. 솔루션에서 우리는 1C 플랫폼 이외의 수단으로 데이터 및 정보 기반에 대한 액세스를 사용하지 않습니다. 우리는 이 데이터의 저장을 편리한 방식으로만 구성합니다.

DBCC 추적(1807)

Management Studio에서 이 명령을 작성하고 실행하면 네트워크를 통해 데이터베이스를 성공적으로 만들 수 있습니다. 물론 이 경우 도메인 계정을 대신하여 SQL Server 인스턴스를 시작해야 하며 이 계정에는 원하는 네트워크 폴더에 대한 권한이 있어야 합니다.
그러나 데이터베이스 작업 중에 네트워크가 끊어지면 이 명령을 사용할 때 매우 주의하십시오. 네트워크가 없는 동안 전체 데이터베이스를 사용할 수 없습니다. 마이크로소프트는 고의로 대량 사용을 위해 이 기회를 마감했습니다. 일반적으로 이 기능은 NAS 스토리지에 데이터베이스를 생성하는 것으로 간주되며 강력하게 권장합니다. MS SQL DBMS를 실행하는 서버에 직접 연결되는 안정적이고 신뢰할 수 있는 파일 서버도 적합합니다.
http://msdn.microsoft.com/en-us/library/ms188396.aspx 문서에서 다른 추적 플래그에 대한 자세한 내용을 읽을 수 있습니다.
저것들. 파일 그룹의 일부는 일반적으로 네트워크에 저장할 수 있으며 거기에서도 디스크 공간이 문제 없이 확장됩니다.

물론 테이블을 다른 파일 그룹으로 나누는 것은 괜찮습니다... 하지만 여기에 두 개의 테이블이 있다고 말할 것입니다... 2005년부터 진행되어 왔으며... 이미 약 12기가바이트를 차지하고 있습니다. 모든 데이터와 별도의 디스크가 있고 현재 상태로 둡니다.
당신은 믿지 않을 것이지만 이것은 매우 간단하지는 않지만 가능합니다.

날짜별로 분할 함수를 만듭니다.

파티션 함수 생성 YearSection(datetime)
values("20110101")에 대한 범위 오른쪽으로;

2011년 이전의 모든 것은 한 섹션으로, 그 이후의 모든 것은 다른 섹션으로 분류됩니다.

파티셔닝 스키마 생성

파티션 구성표 YearScheme 생성
(SECONDARY, PRIMARY)에 대한 파티션 YearSection으로;

이를 통해 11년까지의 모든 데이터는 "Secondary" 파일 그룹에 속하고 이후에는 "Primary"에 속한다고 말합니다.

이제 섹션으로 나누어 테이블을 다시 작성해야 합니다. 이를 위해 프로세스가 간단하지 않기 때문에 가장 쉬운 방법은 관리 스튜디오를 사용하는 것입니다. 인덱스용으로 만든 파티셔닝 구성표를 사용하여 테이블(기본적으로 테이블 자체)에서 클러스터형 인덱스를 다시 빌드해야 합니다.

그러나이를 위해 받침대를 접을 필요는 없지만 다음을 수행하십시오.
a) 모든 사람에게 선택 사용 방법, 저장 방법, 로그 간격 사용 방법, 저장 방법을 설명하십시오.
b) 의미론적 부하(많이 작업하지 않는 계약자 및 명명법)가 없는 경우 불필요한 데이터를 삭제하도록 표시합니다. 이렇게 하면 컨볼루션보다 사용자에게 더 많은 이점이 있습니다. 리소스를 사용할 수 있는 경우 사용하지 않는 개체 삭제를 위한 자동 표시를 설정하고 프로그램 코드에서 기본 선택을 지정하여 사용자에게 필요하지 않은 개체가 기본적으로 표시되지 않도록 합니다(삭제 표시됨).
c) 다른 유용한 "기본 선택"을 설정합니다. 예를 들어 각 관리자는 기본적으로 자신의 문서만 볼 수 있습니다. 그리고 그가 "동지"의 문서를보고 싶다면 선택을 해제해야합니다.

I) DB 롤업으로 해결하려는 문제
1) 데이터베이스 크기 증가
2) 쿼리 성능 저하
3) 이용자의 업무를 방해하는 다량의 "불필요한 데이터"

a) 데이터베이스를 파일 그룹으로 나누기
b) 데이터베이스 또는 그 일부를 네트워크 드라이브에 배치
c) 데이터베이스 테이블 압축
d) 데이터베이스 테이블 분할
2) 쿼리 성능 저하 문제
3) 사용자의 업무를 방해하는 대량의 "불필요한 데이터" 문제

I) DB 롤업으로 해결하려는 문제

1) 데이터베이스 크기 증가

실제로 주요 질문: 데이터베이스 크기를 줄이는 이유는 무엇입니까?
수학을 해봅시다:
500GB 서버 하드 드라이브 비용은 약 10조입니다. 안정성을 위해 RAID 1에 결합하면 20조가 됩니다.
당연히 서버 자체에 새 하드 드라이브를 위한 공간이 부족하다는 문제가 있을 수 있습니다...
그리고 외부 디스크 어레이를 구입하는 것이 그리 저렴하지 않을 것입니다. 무엇을 해야 합니까?
예, 모든 것이 간단합니다. 데이터베이스 파일을 네트워크 드라이브에 배치하지만 어떻게? 이 기사에 대해 자세히 알아보십시오.

데이터베이스에 사용할 수 있는 디스크 공간을 늘리면 20조의 비용이 듭니다. + 전문 작업 10분. 데이터베이스 롤업에 필요한 전문가의 작업 시간은 몇 시간입니까? 얼마나 많은 다운타임이 발생할 수 있습니까? 가장 겸손한 추정치에 따르면 평균 오류 수가 60GB 인 SCP 컨볼 루션의 경우 컨볼 루션 결과를 확인하는 배치 회계는 동일한 배치 회계를 수정하는 데 30-40,000이 소요됩니다.
범용 처리는 특히 데이터베이스가 실제로 "멈추지 않는" 경우 모든 것을 한 번에 축소하지 않을 것입니다. 어쨌든 배치 회계를 수정하십시오. 일반적으로 많은 작업이 있습니다. 그리고 가장 중요한 것은 최종 확인이 매우 철저해야 하며 오류는 여전히 남아 있습니다...

하드 드라이브를 구입하고 500GB의 추가 공간을 확보하면 최종 수치는 20-25에 대해 적어도 30-40톤으로 밝혀졌습니다.

따라서 [이 링크를 보려면 등록해야 합니다]와 같은 제품이 있습니다.

2) 쿼리 성능 저하

글쎄, 누가 "적을수록 빠르다"고 말했습니까? 올바르게 설계된 IS의 경우 이 진술은 사실이 아닙니다.
아래 그림은 간략하게 "새의 언어로" 주소 테이블에 있는 항목의 B-Tree 유형 인덱스에 의한 선택의 가장 간단한 예를 보여줍니다.

유추 - 공책: 각 페이지는 자체 문자로 시작하지만 각 페이지에는 단어의 두 번째 문자를 선택할 수 있는 동일한 공책이 있으며 하나 이상의 기록이 포함된 페이지를 만날 때까지 계속됩니다. 편안한? 물론 연락처가 수백 개 이상이면 편리합니다. 10개만 있다면? 그냥 눈으로 볼 수 있는 종이 한 장에 적어두는 게 쉽지 않나요? 인덱스도 마찬가지입니다. 테이블에 수천 개의 레코드가 있으면 효과적이지만 하나만 있으면 그다지 많지 않습니다. 다행스럽게도 DBMS는 "쿼리 계획"을 독립적으로 선택하고 특정 인덱스를 사용할지 여부를 결정하는 방법을 배웠습니다. 그러나 인덱스 없이 테이블의 모든 행을 "열거"하는 경우 DBMS는 매우 자주 전체 테이블을 잠그고 IB 롤업 후 "잠금이 어디에서 왔는지 명확하지 않음"을 관찰합니다.

우리는 일반적으로 잔차 테이블을 축소합니다. 잔차 테이블에서 모든 인덱스의 첫 번째 필드는 기간입니다. 즉, 인덱스의 최상위 수준에 있는 쿼리의 경우 필요한 기간 동안 계산된 잔액이 이미 선택됩니다. 따라서 데이터베이스 폴딩은 시스템의 올바른 구성으로 유골에 대한 쿼리에 최소한의 영향을 미칩니다.

II) 문제에 대한 "기술적" 솔루션

1) 데이터베이스 크기 증가 문제
a) 데이터베이스를 파일 그룹으로 나눕니다.

데이터베이스 목록에서 Management Studio를 열고 필요한 데이터베이스를 선택한 다음 해당 속성을 엽니다.
- 그림과 같이 "Filegroups" 탭으로 이동하여 다른 파일 그룹을 추가합니다(이 예에서는 SECONDARY라고 함).

"파일" 탭으로 이동하여 생성된 파일 그룹을 선택하는 새 파일을 추가합니다. 이 파일 다른 디스크에 있을 수 있음

다른 파일 그룹으로 이동해야 하는 테이블을 선택합니다. 테이블(프로젝트) 변경 메뉴를 선택하고 속성에서 파일 그룹을 변경합니다.

테이블 인덱스도 이 파일 그룹으로 전송됩니다.
서로 다른 속도의 디스크 배열에 테이블을 배포하는 매우 편리한 메커니즘입니다. 이것은 라이센스 계약에 위배되지 않습니다. 솔루션에서 우리는 1C 플랫폼 이외의 수단으로 데이터 및 정보 기반에 대한 액세스를 사용하지 않습니다. 우리는 이 데이터의 저장을 편리한 방식으로만 구성합니다.

b) 네트워크 드라이브에 데이터베이스 저장

DBCC 추적(1807)

Management Studio에서 이 명령을 작성하고 실행하면 네트워크를 통해 데이터베이스를 성공적으로 만들 수 있습니다. 물론 이 경우 도메인 계정을 대신하여 SQL Server 인스턴스를 시작해야 하며 이 계정에는 원하는 네트워크 폴더에 대한 권한이 있어야 합니다.
그러나 데이터베이스 작업 중에 네트워크가 끊어지면 이 명령을 사용할 때 매우 주의하십시오. 네트워크가 없는 동안 전체 데이터베이스를 사용할 수 없습니다. 마이크로소프트는 고의로 대량 사용을 위해 이 기회를 마감했습니다. 일반적으로 이 기능은 NAS 스토리지에 데이터베이스를 생성하는 것으로 간주되며 강력하게 권장합니다. MS SQL DBMS를 실행하는 서버에 직접 연결되는 안정적이고 신뢰할 수 있는 파일 서버도 적합합니다.
[이 링크를 보려면 등록해야 함] 문서에서 다른 추적 플래그에 대해 자세히 알아볼 수 있습니다.
저것들. 파일 그룹의 일부는 일반적으로 네트워크에 저장할 수 있으며 거기에서도 디스크 공간이 문제 없이 확장됩니다.

c) 데이터베이스 테이블 압축

EXEC sp_MSforeachtable "ALTER INDEX ALL ON ? REBUILD WITH (DATA_COMPRESSION = PAGE)" GO

이 코드를 실행하면 데이터베이스의 모든 테이블이 압축됩니다. 물론 테이블을 개별적으로 압축할 수도 있습니다. 그것은 여러분에게 달려 있습니다. 압축을 제공하는 것은 무엇입니까?
- 디스크 공간 절약
- 디스크 서브시스템의 부하 감소
무엇을 소비하고 있습니까? - 프로세서 시간.
따라서 프로세서가 항상 70% 이상 로드되면 압축을 사용할 수 없습니다. CPU 부하가 20-30%이고 디스크 대기열이 3-4로 증가하면 테이블 압축이 "치료제"일 뿐입니다. 데이터베이스 테이블 압축에 대해 자세히 알아보기 - [이 링크를 보려면 등록해야 합니다.]
중요 참고 사항 - 테이블 압축 기능은 Enterprise SQL Server 버전 소유자만 사용할 수 있습니다.

d) 데이터베이스 테이블 분할

날짜별로 분할 함수를 만듭니다.

파티션 함수 생성 YearSection(datetime)
values("20110101")에 대한 범위 오른쪽으로;

2011년 이전의 모든 것은 한 섹션으로, 그 이후의 모든 것은 다른 섹션으로 분류됩니다.
- 파티셔닝 스키마 생성

파티션 구성표 YearScheme 생성
(SECONDARY, PRIMARY)에 대한 파티션 YearSection으로;

이를 통해 11년까지의 모든 데이터는 "Secondary" 파일 그룹에 속하고 이후에는 "Primary"에 속한다고 말합니다.

그림에서 선택할 수 없음을 알 수 있습니다. 모든 것이 정확하며 Enterprise MS SQL Server 버전에서만 테이블 파티셔닝이 가능합니다. 클러스터 인덱스는 구분하기 쉽습니다 - 괄호가 있는 그림입니다. 발사체 및 모든 1C 객체의 경우 생성됩니다. PH의 경우 기간별로 클러스터링된 인덱스가 항상 있습니다. 문서 및 디렉토리의 경우 섹션 분할에 대한 세부 정보를 포함하는 다른 파일을 만드는 것이 좋을 것입니다. 그러나 이것은 이미 라이센스 계약을 위반하는 것입니다.

2) 쿼리 성능이 좋지 않습니다.

위에서 설명한 모든 작업은 기본 쿼리 속도에 영향을 미치지 않아야 합니다. 또한 파일 그룹 및 테이블 파티션을 사용하면 가장 자주 사용되는 데이터를 빠른 디스크 어레이에 배치하고 디스크 어레이의 구성을 변경하고 작은 I/O 가속기를 사용할 수 있습니다. 따라서 쿼리 실행 속도는 증가할 뿐입니다. 그리고 테이블 압축을 사용하면 디스크 하위 시스템이 병목 상태인 경우 추가로 오프로드할 수 있습니다. 일반적으로 쿼리 실행 속도에 대해 이야기하면 실행 계획 분석, 유능한 인덱스 사용을위한 쿼리 최적화는 MS SQL 수준의 모든 "트릭"보다 훨씬 더 중요한 성능 향상을 제공합니다.

3) 이용자의 업무를 방해하는 다량의 "불필요한 데이터"

태그: 1C, 1C 최적화, SQL, 관리 1C, 교육, 프로그래밍, 기술

[링크를 보려면 등록해야 합니다]