FACHWISSEN · TECHNIK & SICHERHEIT

Datenbankschema ändern: Warum die alte Anwendung nach einem Rollback neue Probleme haben kann

Eine neue Anwendungsversion wird zurückgenommen. Die vorherige Fassung startet wieder, aber die Datenbankstruktur wurde inzwischen verändert. Ein Rollback der Programmdateien setzt diese Änderungen nicht automatisch zurück. Die Rückkehrfähigkeit muss deshalb Anwendung, Schema und bereits geschriebene Daten gemeinsam berücksichtigen.

Versionen als Kombination betrachten

Eine Anwendung erwartet bestimmte Tabellen, Felder und Bedeutungen. Ein neues Schema kann Erwartungen einer älteren Fassung verletzen, auch wenn die Datenbank selbst fehlerfrei arbeitet. Die Kompatibilitätsprüfung betrachtet deshalb die Kombinationen, die während Einführung und möglicher Rückkehr tatsächlich auftreten können. Ein isolierter Test nur der neuesten Fassung deckt diese Übergänge nicht ab.

Erweiterung und Entfernung zeitlich trennen

Ein mögliches Vorgehen ergänzt zunächst eine Struktur, ohne die alte sofort zu entfernen. Anwendungen werden anschließend kontrolliert umgestellt. Nicht mehr benötigte Elemente werden erst später bereinigt, wenn die vereinbarten Abhängigkeiten entfallen sind. Das ist kein allgemeines Rezept für jede Datenbankänderung. Zusätzliche Schreiblogik und zeitweise doppelte Daten brauchen eine klar definierte Konsistenzregel.

Ein fiktives Feldbeispiel durchspielen

Ein Team ersetzt ein bisheriges Statusfeld durch eine differenziertere Struktur. Es prüft, ob die ältere Anwendung während einer Rückkehr noch sinnvoll lesen und schreiben könnte. Neue Statuswerte könnten sich möglicherweise nicht verlustfrei in das alte Modell übersetzen lassen. Diese Grenze muss vor der Veröffentlichung sichtbar sein, statt erst während einer Störung entdeckt zu werden.

Den Rückkehrpunkt vorab nachweisen

Vor einem produktiven Wechsel werden zulässige Rückkehrkombinationen, Sicherung und Wiederherstellungsweg festgelegt. Auch Sperrzeiten und Laufzeit der Schemaänderung können relevant sein. Ein geeigneter Test verwendet einen realistischen Datenstand und prüft fachliche Ergebnisse nach der Rückkehr. Eine gespeicherte ältere Programmversion allein belegt weder eine rückgängig gemachte Datenänderung noch eine konsistente Fortsetzung des Betriebs.

Una nuova versione dell’applicazione viene ritirata. La versione precedente riparte, ma nel frattempo la struttura del database è cambiata. Il rollback dei file del programma non annulla automaticamente queste modifiche. La possibilità di ripristino deve quindi considerare insieme applicazione, schema e dati già scritti.

Considerare le combinazioni di versioni

Un’applicazione si aspetta determinate tabelle, campi e significati. Un nuovo schema può violare le ipotesi di una versione precedente anche quando il database funziona correttamente. Le prove di compatibilità devono quindi considerare le combinazioni che possono effettivamente verificarsi durante l’introduzione e un eventuale ripristino. Testare isolatamente soltanto l’ultima versione non copre queste transizioni né dimostra che la precedente continui a funzionare.

Separare nel tempo l’estensione dalla rimozione

Un possibile approccio aggiunge prima una struttura senza rimuovere subito quella precedente. Le applicazioni vengono poi migrate in modo controllato. Gli elementi obsoleti vengono eliminati solo più tardi, quando le dipendenze concordate sono cessate. Non è una ricetta universale per ogni modifica al database. La logica di scrittura aggiuntiva e i dati temporaneamente duplicati richiedono regole di coerenza esplicite.

Simulare una modifica ipotetica a un campo

Un team sostituisce un campo di stato con una struttura più articolata. Verifica se, dopo un ritorno alla versione precedente, la vecchia applicazione potrebbe ancora leggere e scrivere in modo sensato. I nuovi stati potrebbero non essere traducibili nel vecchio modello senza perdita di informazioni. Questo limite deve essere noto prima del rilascio, anziché essere scoperto durante un guasto e sotto pressione.

Verificare in anticipo il punto di ritorno

Prima della modifica in produzione si definiscono le combinazioni di ripristino ammesse, il backup e la procedura di ripristino. Possono essere rilevanti anche i periodi di blocco e la durata della migrazione dello schema. Un test adeguato usa dati realistici e verifica i risultati operativi dopo il ritorno. Conservare una vecchia versione del programma, da solo, non dimostra né che le modifiche ai dati siano state annullate né che l’esercizio possa proseguire in modo coerente.

Se revierte una nueva versión de la aplicación. La versión anterior vuelve a arrancar, pero la estructura de la base de datos ha cambiado entretanto. Revertir los archivos del programa no deshace automáticamente esos cambios. Por tanto, la capacidad de recuperación debe considerar conjuntamente la aplicación, el esquema y los datos que ya se han escrito.

Considerar las combinaciones de versiones

Una aplicación espera determinadas tablas, campos y significados. Un esquema nuevo puede contradecir las expectativas de una versión anterior aunque la base de datos funcione correctamente. Las pruebas de compatibilidad deben considerar las combinaciones que pueden producirse realmente durante el despliegue y una posible reversión. Probar únicamente la última versión de forma aislada no cubre esas transiciones ni demuestra que la anterior siga funcionando.

Separar la ampliación de la eliminación

Una posible estrategia añade primero una estructura sin eliminar inmediatamente la anterior. Después se migran las aplicaciones de forma controlada. Los elementos obsoletos se eliminan más adelante, cuando dejan de existir las dependencias acordadas. No es una receta universal para cualquier cambio de esquema. La lógica adicional de escritura y los datos duplicados temporalmente necesitan reglas de consistencia explícitas.

Simular un cambio hipotético de campo

Un equipo sustituye un campo de estado por una estructura más detallada. Comprueba si la aplicación anterior aún podría leer y escribir con sentido tras una reversión. Puede que los estados nuevos no se traduzcan al modelo antiguo sin perder información. Esta limitación debe conocerse antes del lanzamiento, en lugar de descubrirse durante una incidencia bajo presión.

Demostrar de antemano el punto de retorno

Antes de modificar producción deben definirse las combinaciones de recuperación permitidas, la copia de seguridad y el procedimiento de restauración. También pueden importar los periodos de bloqueo y la duración de la migración del esquema. Una prueba adecuada utiliza datos realistas y comprueba los resultados de negocio después del retorno. Conservar una versión anterior del programa no demuestra por sí solo que se hayan revertido los cambios en los datos ni que la operación pueda continuar de forma consistente.