Come annullare un'esecuzione di query in phpmyadmin

Question

Come annullare un'esecuzione di query in phpmyadmin.

Qualsiasi funzionalità di rollback è presente? qualsiasi corpo conosce la soluzione gentilmente aiutarmi?

Answer 1

Se la dichiarazione è ancora in esecuzione è possibile utilizzare KILL QUERY <thread_id>.

Se la dichiarazione è stata completata ma non è stata ancora eseguita la transazione, è possibile utilizzare ROLLBACK.

Se la dichiarazione è stata completata e la transazione è già stata eseguita (o non è stata avviata una transazione), ripristinare i dati dal backup più recente.

---

Qui ci sono anche alcuni consigli suggerimenti per evitare questo tipo di situazione accadendo in primo luogo:

• Quando si scrive un DELETE o UPDATE sempre scrivere la clausola WHERE prima in modo che don' lo dimentico
• Verificare la clausola WHERE in un'istruzione SELECT per assicurarsi di aggiornare le righe corrette.
• Se si sa che si dovrebbe aggiornare solo una riga, è possibile aggiungere LIMIT 1 alla propria istruzione UPDATE. Quindi, se nonostante si utilizzano le tecniche di cui sopra si ha ancora un errore, almeno una riga sarà interessata, non l'intero database.

Answer 2

Si può andare alla pagina 'processi' e premere 'kill'

Answer 3

se avete cancellato qualcosa, allora non penso la sua intenzione di tornare a meno che non si aveva un backup.I sapere in SQL a volte è possibile allontanarsi sarà la chiamata ROLLBACK prima di eseguire il commit a una serie di comandi SQL ma solo nelle transazioni, e devi averli prima avviati (che phpMyAdmin non usa).

Answer 4

Se hai già eseguito la transazione, non c'è modo di "annullarla", temo. Questo è uno dei principi fondamentali di ACID. Se non l'hai commesso: basta fare un rollback, e stai bene.

Avrete bisogno di ripristinare i dati da un backup - o se la query è in esecuzione, provare cosa suggeriva Mark Byers, utilizzando kill query.

Answer 5

Se è necessario ripristinare i dati precedenti prima di un aggiornamento eseguito, è possibile effettuare il refactoring del database utilizzando i trigger di aggiornamento ed eliminazione per archiviare i vecchi dati in una tabella di archivio con una data/ora corrente o (preferibilmente) un valore di identificazione della transazione (e assicurarsi che gli inserimenti memorizzino sempre una data/ora corrente o un valore di identificazione della transazione) ... mantenendo effettivamente un'intera cronologia di ogni modifica apportata al database. Attenzione, il tuo database crescerà a un ritmo incredibile ... questa è solo una soluzione per i dati mission-critical in cui la cronologia è essenziale, perché richiede molto sforzo per implementare e molto costoso spazio su disco da mantenere. Anche allora, può diventare molto complesso se ci sono stati successivi aggiornamenti ai dati interessati; e potrebbe essere necessario "perdere" quelli quando si ripristina una cronologia precedente.

Posso solo pensare a pochissimi sistemi che implementano questo tipo di manutenzione della cronologia ... ad esempio Oracle Financials o HR.

In alternativa, ci sono alcuni database (che ho utilizzato con il vecchio DEC RDBMS) che possono gestire i RUJ (Run Unit Journals) che possono quindi essere utilizzati per ripristinare da un backup e fino a un orario/transazione.Comunque MySQL non rientra in questa categoria. Anche in questo caso, richiede molto spazio su disco ed è pratico solo quando si eseguono backup regolari dei dati e il processo di recupero è più complesso. MySQL (per quanto ne so) non supporta questa funzione.

Per la maggior parte delle persone, l'approccio più pratico è un semplice ripristino dal backup, probabilmente seguito da una ricreazione manuale. Sfortunatamente, la maggior parte delle persone al giorno d'oggi non prende nemmeno i backup.