많은 수의 행을 삭제 한 후에 SQL Server 데이터베이스 크기가 줄어들지 않았습니다.

SQL에 능숙하지 않지만 유지 관리 할 데이터베이스가 있습니다.

남아있는 곳이 거의 없으므로 2008 년이라고 가정 해 보겠습니다. delete query (만 10 만 행 삭제) 및 트랜잭션 로그 정리를 실행 한 후 작업은 데이터베이스 크기에 영향을 미치지 않았습니다. 내가해야 할 다른 일이 있습니까?

수축은 실제로 여기에 언급 된 이유로 위험합니다. Jimbo의 답변과 John의 답변 사이에는 행복한 매체가 있습니다. 데이터베이스를 축소 할 것인지 항상 신중하게 고려해야합니다.

이상적인 세계에서는 충분한 여유 공간이있는 DB를 만들어 성장할 수 있습니다. 이 데이터베이스를 "Right Sizing"이라고합니다. 이 여유 공간을 확보하고 다시 사용하지 않고 전체 크기를 사용 된 크기로 유지하려고하지 않습니다. 왜 그렇습니까? 데이터베이스가 결국 다시 커지기 때문입니다. 그러면 다시 축소됩니다. 그리고 당신은 쓸모없는 축소 패턴과 그 이후의 성장에 갇히게 될 것입니다. 인덱스 조각화 증가

나는 사람들에게 " 축소 버튼을 만지지 마십시오! " 라고 조언하는 곳에서 블로그 를 작성했습니다. 큰 데이터베이스가 있고 상당한 공간을 확보하고 다시 성장할 것으로 기대하지 않는 경우 나중에 다시 작성을 통해 인덱스 조각화를 처리 할 수있는 한 한 번만 축소하면됩니다. 그들. 수축 작업은 시간이 많이 걸리므로 수축 실행 가격을 지불 할 수있는 시간을 계획하고 싶을 것입니다. 빈 DB를 만들고 데이터를 복사하는 방법은 효과적이지만 더 큰 데이터베이스와 많은 양의 데이터에서는 매우 어려울 수 있습니다.

미래의 정상적인 사용 및 성장 패턴을 통해 해당 공간을 DB에 다시 추가하려는 경우 공간을 남겨 두는 것이 좋습니다.

또한 당신은 당신이 당신의 거래 기록을 "삭제"했다. 나는 당신이 이것을 어떻게했는지 알고 싶습니다.하지만 당신이 공유 한 게시물과 시리즈의 다른 사람들을 읽으면 트랜잭션 로그 관리에 대한 팁을 볼 수 있습니다. 그러나 간단히 말해서 전체 복구 모드 인 경우 정기적으로 로그 백업을 수행하여 로그 자체를 재사용해야합니다. 그렇지 않으면-전체 모드에서 로그 백업을하지 않고도 로그 파일은 계속 커지고 커지고 커지며 항상 SQL에 응급 복구를 위해 로그를 유지하고 싶지는 않지만 복구 목적으로 트랜잭션 / 실행 취소 트랜잭션을 재생하여 특정 시점으로 복구하기위한 수동 백업 ... 단순하고 로그가 지나치게 커지는 경우,BEGIN TRAN ... do work.... COMMIT TRAN또는 하나의 큰 DELETE문을 발행 하고 하나의 암시 적 트랜잭션에서 전체 데이터 엉망을 삭제 했는지 여부 )

또한 파일 시스템 에서이 여유 공간을 찾고 있다고 가정합니다. SQL과 큰 파일 내에서 파일을 찾고 있다면 작업 직후에 찾으면 고스트 정리가 완료되기를 기다리는 것일 수 있습니다. 고스트 정리에 관한 Paul Randal 블로그 .

데이터베이스에서 행을 삭제해도 실제 데이터베이스 파일 크기는 줄어들지 않습니다.

행 삭제 후 데이터베이스를 압축해야합니다.

SQL Server 2005 DBCC SHRINKDATABASE (Transact-SQL)

이를 실행 한 후에 인덱스를 다시 작성해야합니다. 축소하면 일반적으로 인덱스 조각화가 발생하며 이는 상당한 성능 비용이 될 수 있습니다.

또한 축소 한 후 여유 공간이 확보되도록 파일을 다시 늘리는 것이 좋습니다. 이렇게하면 새 행이 들어 오면 자동 증가를 트리거하지 않습니다. 자동 증가에는 성능 비용이 있으며 가능할 때마다 (적절한 데이터베이스 크기 조정을 통해) 피하고 싶은 것입니다.

데이터베이스를 축소하지 마십시오!

"이러한 이유는 무엇입니까? 데이터 파일 축소 작업은 한 번에 하나의 파일에서 작동하며 GAM 비트 맵을 사용합니다 (스토리지 엔진 내부 : GAM, SGAM, PFS 및 기타 할당 맵 참조). 그런 다음 파일 앞쪽으로 최대한 이동합니다. 위의 경우 클러스터 된 인덱스의 순서를 완전히 바꾸어 조각 모음에서 조각 모음을 완전히 수행합니다. "

http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files.aspx

"수축 데이터베이스의 아이러니를 보라. 한 사람이 공간을 확보하기 위해 데이터베이스를 축소하고 (성능에 도움이된다고 생각), 조각화가 증가하고 (성능 감소) 조각화를 줄이려면 인덱스를 다시 작성하여 크기를 조정한다. "축소 전) 데이터베이스의 원래 크기보다 더 많이 증가하는 데이터베이스입니다. 수축으로 인해 일반적으로 원하는 것을 얻지 못했습니다."

http://blog.sqlauthority.com/2011/01/19/sql-server-shrinking-database-is-bad-increases-fragmentation-reduces-performance/

데이터를 삭제하면 SQL Server는 나중에 새 데이터를 삽입하는 데 사용할 공간을 확보합니다. 데이터베이스를 축소해야합니다. 자세한 내용은 여기를 참조 하십시오 .

내 데이터베이스가 "최대 값을 초과"하여 방금 백업 테이블을 여러 개 삭제했기 때문에 이것을 발견했습니다. "크기"속성을 계속 보면서 왜 이것이 작아지지 않을까 생각했습니다 . . 이것을 읽은 후에는 데이터베이스를 축소하고 싶지 않습니다. 내가하고 싶은 것은 방금 삭제 한 정크의 공간을 "다시 찾는 것"입니다. 내가보고 싶었던 것은 "Space Available"이었습니다. 다른 사람도 그 점을보고있을 필요가 있다고 생각합니다. *

테이블에 인덱스가있는 경우 대량의 데이터를 삭제 한 후 조각화가 발생할 수 있습니다. 나는 오늘 약 70GB의 레코드가 약 13GB를 차지하는 테이블을 가지고있었습니다. 1639 레코드로 정리했지만 나머지는 단일 버그로 생성되었지만 테이블은 여전히 ​​약 4.5GB를 차지했습니다. 테이블의 모든 인덱스를 다시 작성한 후 85 페이지 (680kb) 만 사용했습니다. 그 후, 증가 축소 파일을 사용하여 공간을 되찾았습니다 (반복을 방지하기 위해 시스템의 버그를 수정했습니다).