Trovo le solite due o tre tabelle crashate, le riparo e il sistema torna a pieno regime; soltanto per fermarsi poco dopo per un altro problema.

Una tabella di log che normalmente è tenuta “a bada” da uno script di cron è arrivata a 14 milioni di righe. Niente di spaventoso, ma so già quello che mi aspetta.

Non la posso troncare, e una DELETE su una tabella del genere è la morte di qualsiasi database [segue aneddoto]. Mi faccio coraggio e lancio dunque la delete dopo aver disabilitato le scritture su quella tabellaccia.

Quarantacinque minuti dopo, terminata l’operazione, la tabella conta 5000 righe.

Tutto a posto, dunque? Manco per niente.

Riattivo il sistema e noto che le JOIN con quella tabella continuano a bloccare il sito. Allora mi ricordo che dopo una cancellazione così pesante è sempre bene eseguire anche una ANALYZE TABLE.

15 minuti dopo (su una tabella di 5000 righe?) i problemi persistono. OK, allora facciamo anche una REPAIR TABLE. Altri 15 minuti dopo, finalmente, il sistema è tornato nominal.

Aneddoto: qualche anno fa lavoravo su un database SQL Server. Era un venerdì sera (circa le 18), e non ricordo perché decido di fare un po’ di pulizia su una tabella con diversi milioni di righe (in produzione, che idiota). Dopo un paio d’ore di esecuzione, decido che la faccenda si sta facendo ridicola e voglio spostare il problema al lunedì. Dunque fermo la DELETE, ma non mi rendo conto che quella DELETE era sotto transazione. Risultato? Altre tre ore di ROLLBACK, e un venerdì buttato via.