보조 데이터 파일을 제거합니다. DBCC SHRINKFILE : 작업 테이블 페이지이므로 페이지를 이동할 수 없습니다.

에 대한 보조 데이터 파일 (.ndf)이 너무 많습니다 tempdb. 초과 파일을 제거하려면 파일을 비워야합니다 (콘텐츠가 다른 파일로 이동 됨).

DBCC SHRINKFILE('tempdbfile8', EMPTYFILE);

그런 다음 파일을 삭제하십시오.

ALTER DATABASE tempdb REMOVE FILE tempdbfile8;

그러나 EMPTYFILE명령은 오류를 반환합니다.

DBCC SHRINKFILE: Page 8:41920 could not be moved because it is a work table page.
Msg 2555, Level 16, State 1, Line 2
Cannot move all contents of file "tempdbfile8" to other places to complete the emptyfile operation.

걱정할 필요는 없습니다.이 페이지를 사용하여 무언가를 수행하는 객체를 찾아야합니다.

DBCC TRACEON (3604)
DBCC PAGE(2,8,41920) --dbid=2, fileid=8, pageid=41920

이 명령은 많은 정보 object_id를 반환합니다. 그러나:

Metadata: ObjectId = 0

나는 그것에 대해 어떻게해야할지 모른다. 어떤 고양이가이 페이지를 옮기지 못하게합니까? 해당 객체, 프로세스, 세션 또는 그 밖의 것을 찾는 방법은 무엇입니까? 도움을 주시면 모든 것을 그대로 두거나 다른 파일을 제거하는 것이이 문제에 대한 올바른 해결책이 아닙니다.

편집하다:

프로세서 코어 당 하나의 파일 (동일한 초기 크기, 동일한 성장률)을 만드는 "모범 사례"를 따르기 때문에 파일을 제거하고 있습니다. 그러나 내가 아는 한, 경합 문제가 발생할 때까지 동일한 장치에서 추가 tempdb 파일을 만들 필요는 없습니다. 우리의 경우 MPIO 가 켜져 있고 스토리지 장치가 4 개의 경로를 처리 할 수 있기 때문에 의미가 있습니다 . 그러나 실수가 있었고 6 코어 CPU로 총 5 개의 파일이 생겼습니다. MPIO 경로 이상이고 CPU 코어보다 적으며 짝수가 아닙니다. 문제를 일으키지 않을 수도 있지만 옳지 않은 것처럼 보입니다. :).

마지막으로 문제를 일으킬 것으로 의심되는 데이터베이스 중 하나를 단일 사용자 모드 (롤백 즉시)로 설정하여 서버를 다시 시작하지 않고도 파일을 비우고 제거 할 수있었습니다. 효과가 있었지만 운이 좋았습니다. 내가 정말로 원하는 것은 항상 페이지를 추적 할 수 있도록하는 것입니다 :).

— 아담 루니 에프 스키
소스

DBCC PAGE 명령이 올바르지 않습니다. dbcc page (2,41920,1)와 같아야합니다. 1,2,3은 출력에서 원하는 것에 달려 있습니다.

— Shanky

위의 방법으로 문제가 해결되지 않으면 파일을 제거한 다음 SQL Server를 다시 시작하여 하드웨어에서 삭제하지 않은 파일 만 사용하도록해야합니다. 이 링크를 참조 할 수 있습니까 daveturpin.com/2011/07/how-to-drop-a-tempdb-database-file

— Shanky

@Shanky 명령이 정확합니다. 0..3은 네 번째 매개 변수로 전달 될 수 있습니다. dbcc page ( {'dbname' | dbid}, filenum, pagenum [, printopt={0|1|2|3} ])솔루션 정보 : 작동하지만 인스턴스를 중단시키지 않고이 작업을 수행하고 싶습니다.

— Adam Luniewski

Ok .. 나는 당신에게 더 간단한 형태의 dbcc 페이지를 말하고있었습니다. 문서화되지 않은 명령입니다. 내가 게시 한 링크를 확인 했습니까

— Shanky

인스턴스를 다시 시작하지 않고이 문제를 해결하는 것이 가능하다고 생각하지 않습니다. 분명히이 작업 테이블이 무엇인지 (테이블을 소유 한 사람을 결정하는 데 도움이 됨) 추적하려고 시도했지만 실패했습니다. 당신이 다시 시작할 수있을 때까지 히트를하거나 여분의 파일로 라이브.

— Aaron Bertrand

답변:

서버를 다시 시작하면 충분합니다. 해당 작업 테이블을 지워야합니다. 그러나 파일을 성공적으로 제거하기 전에 다른 프로세스가 작업 테이블을 생성하지 못하게하기 위해 단일 사용자 모드 (-m) 로 시작 했을 것입니다 . 그런 다음 필요한 파일을 다시 정의하십시오 tempdb. 또한 불필요한 파일 삭제, 크기 변경 등도 가능합니다. 파일의 개수가 짝수인지, 모두 같은 크기로 설정되어 있고 모두 동일한 자동 증가 설정 (%가 아닌 MB)을 가지고 있는지 확인해야합니다. 그리고 TF 1117과 TF 1118도 고려하는 것이 좋습니다 ( 시작점 ).

SQL Server를 다시 시작하기 전에 파일 시스템에서 파일을 삭제하라는 제안에 매우주의를 기울였습니다. 전혀 시작되지 않을 수 있습니다.

(그러나 실제 문제가 무엇인지 궁금합니다. 파일이 너무 많더라도 실제로 문제가되지 않습니다.)

— 애런 버트 랜드
소스

@@ Aaron 물론 제거 할 때는주의해야합니다. 비어 있어야하지만 여기에는 msdn.microsoft.com/en-gb/library/ms175574.aspx에 설명되어 있습니다 . 그것을 시도하고 SQl 서버 tempdb가 온라인 상태가됩니다.

— Shanky

@Shanky 나는 한 시간에 138 마일을 한 번 운전하려고했지만 풀리지 않았다. 그것은 내가 계속해야한다는 것을 의미합니까, 내일 당장 당할 확률이 없습니까? 위험한 방법을 제안하기 전에 올바른 방법을 먼저 시도하는 것이 훨씬 안전합니다 . 이모. 특히 그는 지금 파일을 비울 수 없으므로 오류 메시지가 불평하는 작업 테이블 외에 다른 파일이있을 가능성이 있다고 생각하십니까? 이 오류는 모든 객체의 전체 목록을 생성하지는 않으며 첫 번째 객체 만 출력 합니다.

— Aaron Bertrand

실제로 tempdb를 사용하는 것이 있으므로 추측하기 어려운 파일을 비울 수 없습니다. 정렬 연산자를 사용했을 때 여전히 tempdb가 필요한 쿼리입니다. DMV는 sys.dm_db_task_space_usage를 찾는 데 도움을 줄 수 있습니다. sys.dm_db_session_space_usage sys.dm_db_file_space_usage

— Shanky

다시 시작은 옵션이지만 파일을 비우지 않고 tempdb 파일을 삭제하려고해도 tempdb 파일을 삭제할 수는 없지만 시스템 카탈로그가 업데이트되는 동시에 다시 시작한 후에는 파일이 사라집니다. 이것은 tempdb의 기본 동작을 추측하므로 데이터 파일을 제거해도 유용하다고 생각합니다. 내가 두 번째 의견에 게시 한 링크에도 동일합니다.

— Shanky

@ DMK는 문제의 파일과 관련이없는 모든 종류의 항목에 대해 수천 행을 반환 할 수 있습니다. 그래서 어떻게 좁힐 계획입니까? 또한 방법을 사용하면 다시 시작해야하므로 간단한 방법을 먼저 시도해보십시오. 나는 "어려운 길"이 첫 번째 제안이되어야한다는 것에 동의하지 않습니다. 죄송합니다.

— Aaron Bertrand

https://social.msdn.microsoft.com/Forums/en-US/2a00c314-f35e-4900-babb-f42dcde1944b/dbcc-shrinkfile-page-411283400-could-not-be-moved-because-it-is- 작업 테이블 페이지? 포럼 = sqldatabaseengine

msdn forum에서 Mike가 제안한대로 작업 테이블은 대부분 계획 캐시와 연관되어 있습니다. 그것들을 지우면 작업 테이블도 제거되고 Tempdb가 줄어들 수 있습니다. 이것은 나를 위해 일했습니다. 그리고 이것은 서버 재시작을 줄여줍니다. SQL Server가 실행 계획을 다시 작성해야하기 때문에 약간의 오버 헤드가 있습니다.

— 사제 쉬
소스