SQL Server Performance & Troubleshooting – Where Milliseconds Matter 🚀

Ciao a tutti! Oggi si fa sul serio! Con l'articolo odierno vorrei mostrarvi come recuperare un errore forzando il puntamento delle pagine. Avremo così l'occasione di introdurre gli ultimi due comandi da tenere nella vostra cassetta degli attrezzi che sono il DBCC IND ed il DBCC WRITEPAGE Un Avvertimento però: mai provare su un database di cui non si abbia un backup, il rischio è di far danni seri! Buona lettura! Database corrotti e DBCC WRITEPAGES Supponete anche anche oggi vi siate trovati tra le mani un database corrotto. Subito vi siete collegati ed avete eseguito il comando DBCC CHECKDB . Il log vi mostra l'errore. La situazione che vi si presenta di fronte è questa: ... Per l'oggetto "sys.wpr_bucket_table"sono disponibili 0 righe in 0 pagine. Messaggio 8939, livello 16, stato 98, riga 28 Errore di tabella: ID di oggetto 581577110, ID di indice 1, ID di partizione 72057594043170816, ID di unità di allocazione 72057594049658880 (tip...

Ciao a tutti! Nell'articolo precedente abbiamo visto come controllare se un database è corrotto oppure no (fai click qui: La megaditta è ferma! ..DBCC CHECK fallito ) Il comando che avevamo utilizzato in precedenza è il comando DBCC CHECKDB . Oggi vi faccio vedere un modo diverso "ma molto furbo" per vedere quali tabelle si sono corrotte. Lo si può usare mentre il DBCC sta verificando i databases dacchè l'operazione richiede tempo in caso di database di dimensioni notevoli.Seguitemi, si parte! La tabella suspect_pages Diciamo subito che SQL Server quando trova degli errori se li memorizza un una tabella apposita. Questa tabella si chiama suspected_pages ed è contenuta nel database di sistema msdb .Aprite quindi la console del SQL Server Manager Studio scrivete: SELECT * FROM [msdb].[dbo].[suspect_pages] Eseguitela ed ecco qui il risultato: Anche questo comando ci dice che è presente la pagina 26094 che ha un problema. Ora che abbiamo il numero d...

Rieccoci! Prima di tutto, grazie delle tante visite, noi nonostante il caldo siamo ancora qui anche per farvi compagnia in questo assolato agosto. Avviso di servizio: tra una settimana ci prenderemo una breve pausa, se volete potrebbe essere l'occasione ideale per rileggere ciò che vi è scappato! L'articolo di oggi rappresenta il proseguo di quello di ieri ( Di database corrotti ed aziende bloccate ), una sorta di parte 2. L'argomento è vasto e così questa volta vedremo come controllare se un database è corrotto o meno . Vedremo che a volte sarà possibile individuare quali sono la tabelle rovinate e che non sono più leggibili. Stavolta non faremo nulla di pericoloso, percui provate e cercando di acquisire dimestichezza. Buona lettura! Riassunto della puntata precedente. Il vostro cliente più grosso nonchè titolare della megaditta vi ha telefonato perchè improvvisamente a due giorni dalla chiusura estiva improvvisamente nessuno riusciva più a lavorare con il ...