Rimozione di file di dati secondari. DBCC SHRINKFILE: impossibile spostare la pagina perché è una pagina della tabella di lavoro

Ho creato troppi file di dati secondari (.ndf) per tempdb. Per rimuovere i file in eccesso, devo svuotare il file (il contenuto verrà spostato in altri file):

DBCC SHRINKFILE('tempdbfile8', EMPTYFILE);

e quindi eliminare il file:

ALTER DATABASE tempdb REMOVE FILE tempdbfile8;

Ma il EMPTYFILEcomando restituisce l'errore:

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.

Non preoccuparti, devo solo individuare l'oggetto che utilizza questa pagina per fare qualcosa al riguardo:

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

Il comando restituisce molte informazioni, tra cui object_id. Ma:

Metadata: ObjectId = 0

Non ho idea di cosa fare al riguardo. Quale gatto impedisce a questa pagina di essere spostata? Come individuare quell'oggetto, processo, sessione o qualunque cosa sia? Qualsiasi aiuto sarà apprezzato, ma tieni presente che lasciare tutto così com'è o rimuovere altri file invece non è una soluzione valida a questo problema;).

MODIFICARE:

Sto rimuovendo i file, perché seguivamo le "migliori pratiche" per creare un file per core del processore (stessa dimensione iniziale, stesso tasso di crescita). Ma per quanto ne so, fino a quando non si incontrano problemi di contesa, non ha senso creare file tempdb aggiuntivi sullo stesso dispositivo. Nel nostro caso ha senso, perché MPIO è attivo e il dispositivo di archiviazione può gestire 4 percorsi. Ma c'è stato un errore e siamo finiti con un totale di 5 file con CPU a 6 core. È più dei percorsi MPIO, meno dei core della CPU e non è un numero pari. Potrebbe non causare problemi, ma non sembra giusto :).

Sono stato finalmente in grado di svuotare e rimuovere il file senza riavviare il server impostando uno dei database (che sospettavo di causare il problema) in modalità utente singolo (rollback immediato). Ha funzionato, ma sono stato fortunato. Quello che voglio davvero è essere sempre in grado di rintracciare la pagina in basso :).

— Adam Luniewski
fonte

Il comando PAGINA DBCC non è corretto, dovrebbe essere come la pagina dbcc (2.41920,1). 1,2,3 dipende da cosa si desidera in output.

— Shanky,

Se sopra non funziona, potrebbe essere necessario farlo nell'hardware rimuovendo i file e quindi riavviando il server sql in modo da utilizzare solo i file che non sono stati eliminati. Puoi fare riferimento a questo link daveturpin.com/2011/07/how-to-drop-a-tempdb-database-file

— Shanky

@Shanky Il comando è corretto. 0..3 può essere passato come quarto parametro: dbcc page ( {'dbname' | dbid}, filenum, pagenum [, printopt={0|1|2|3} ])Informazioni sulla tua soluzione: funzionerebbe, ma mi piacerebbe davvero farlo senza far cadere l'istanza.

— Adam Luniewski,

Ok..ti stavo dicendo una forma più semplice di pagina di dbcc. Si noti che è un comando non documentato. Hai controllato il link che ho pubblicato

— Shanky,

Non credo sia possibile risolvere questo problema senza riavviare l'istanza. Ovviamente hai provato a rintracciare cos'è questo worktable (che contribuirebbe a determinare chi lo possiede) e che ha fallito. Prendi il colpo o vivi con i file extra fino a quando non puoi riavviare.

— Aaron Bertrand

Risposte:

Il riavvio del server dovrebbe essere sufficiente: tali piani di lavoro dovrebbero essere eliminati. Ma probabilmente lo avvierei in modalità utente singolo (-m) per impedire ad altri processi di creare tabelle di lavoro prima di rimuovere con successo quei file. Quindi ridefinire i file richiesti per tempdb; forse eliminando file non necessari, cambiando dimensioni, ecc. Dovresti anche assicurarti di avere un numero pari di file, che siano tutti impostati sulla stessa dimensione e che abbiano tutti le stesse impostazioni di crescita automatica (in MB, non%). E potrebbe essere un buon momento per considerare anche TF 1117 e TF 1118 ( punto di partenza ).

Sarei molto cauto sul suggerimento di eliminare i file dal file system prima di riavviare SQL Server: potrebbe non avviarsi affatto.

(Sarei anche curioso di sapere qual è il vero problema, però. Avere troppi file non ti fa male, davvero.)

— Aaron Bertrand
fonte

@@ Aaron ovviamente devi essere cauto sulla rimozione deve essere vuoto, ma questo è documentato qui msdn.microsoft.com/en-gb/library/ms175574.aspx . L'ho provato e SQl Server tempdb è online.

— Shanky,

@Grazie, ho provato a guidare 138 miglia all'ora una volta e non mi sono fermato. Significa che dovrei continuare a farlo, e che non c'è alcuna possibilità che mi venga fermato domani? Molto più sicuro provare prima nel modo giusto , prima di suggerire un modo più rischioso. A PARER MIO. Soprattutto dal momento che non può svuotare il file ora - pensi sia possibile che ci sia qualcos'altro al di fuori del piano di lavoro di cui si lamenta il messaggio di errore? L'errore non produce un elenco esaustivo di tutti gli oggetti, ma genera solo il primo oggetto.

— Aaron Bertrand

C'è qualcosa che sta effettivamente usando tempdb, quindi non gli consente di svuotare il file è difficile da indovinare. Possa usare l'operatore di ordinamento è una query che necessita ancora di tempdb. DMV può aiutarlo a trovare sys.dm_db_task_space_usage sys.dm_db_session_space_usage sys.dm_db_file_space_usage

— Shanky,

Il riavvio è un'opzione qui, ma anche se non svuota il file e prova a rilasciare il file tempdb, direbbe che il file tempdb non può essere eliminato, ma allo stesso tempo il catalogo di sistema viene aggiornato e dopo il riavvio il file sparirebbe. Suppongo che questo sia il comportamento predefinito con tempdb, quindi ho suggerito e continuo a pensare che la rimozione del file di dati funzionerebbe anche se viene utilizzata. Lo stesso è presente nel link che ho pubblicato nel mio secondo commento.

— Shanky,

@Shanky quei DMV potrebbero restituire migliaia di righe per tutti i tipi di cose che non hanno nulla a che fare con il file in questione - quindi come pensi di restringerlo? Inoltre, poiché con il tuo metodo devi anche riavviare, perché non provare prima il modo più semplice? Semplicemente non sono d'accordo con te sul fatto che "il modo più duro" dovrebbe essere il primo suggerimento, scusa.

— 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- a-tavolo da lavoro-page? forum = sqldatabaseengine

Come proposto da Mike nel forum msdn, le tabelle di lavoro sono principalmente associate alla cache del piano. La loro cancellazione rimuove anche il tavolo di lavoro e quindi è possibile ridurre Tempdb. Questo ha funzionato per me. E questo ti consente anche di riavviare il server. Ci sarà un certo sovraccarico poiché SQL Server dovrà ricreare nuovamente i piani di esecuzione.

— sajeesh
fonte