Migration von SQL-Datenbanken

ELO Installationen verbinden sich in der Regel mit einem nativen SQL-Benutzer mit dem Namen „elodb“, bei ORACLE Installationen ist hier auch der Name „eloadmin“ geläufig. Je nach Installation und Vorgaben der IT kann dieser allerdings vom Namen her divergieren. Wenn Sie hier den Namen ermitteln wollen, dann lässt sich dieser mittels einem Blick in die Konfigurationsdateien der Servlets ermitteln. Im Normalfall befinden sich diese unter „C:/ELOprofessional|ELOenterprise/config/ix-[ArchivName]“. Bei früheren Installationen können Sie hier die Daten mittels der WebApps „am/dm“ ermitteln, bei aktuellen Installationen geht immer nur „ix“. Hier finden sich dann in der „config.xml“ die Verbindungsdaten zum Archiv unter „ud-config.xml“ die Verbindungsdaten zu der AccessManager Datenbank. Hier lässt sich dann auch ermitteln zu welchem Server die Servlets eine Verbindung aufbauen, resp. Um welchen Datenbanktyp es sich hier handelt.

Bei SQL-Server Installationen hat der SQL-Datenbank Benutzer die Rollen „dbuser“ sowie „dbcreator“ inne. Das ermöglicht dem Serversetup von ELO neue Datenbanken anzulegen. Nach der Anlage habe die Datenbanken dann immer den Owner des anlegenden SQL-Benutzers, in dem Fall also die Kennung des ELO-Datenbankbenutzers. Will man die Berechtigungen anders abbilden als im Standard so ist es empfehlenswert, den Datenbankbenutzerwahlweise als:

• Benutzer mit Zuordnung zur Datenbank anzulegen
  • entweder die Rolle „dbo“ zuzuordnen
  • oder aber „datareader“, „datawriter“ so wie „ddladmin“
  • Wichtig ist hier immer, dass Daten gelesen/geschrieben werden können (SELECT, UPDATE, INSERT, DELETE) sowie Datentabellen und Indizes von dem Datenbankbenutzer angepasst werden können.
  • Je granularer Sie hier die Regeln halten, desto genauer müssen Sie hier beim Lesen des IX-Logs sein und desto schwieriger kann sich hier ein Systemupdate verhalten. Vor allem werden Sie hier von ELO keinen Support mehr erhalten, wenn Sie die Rechte zu sehr einschränken.

• Bei einer Wiederherstellung ohne Transaktionslog führen Sie hier die Reparatur der Datenbank auf SQL Server Ebene aus (DBCC CHECKDB). Beachten Sie hier, dass Sie hier möglicherweise Inkonsistenzen erfahren können. Es kann hier einfach sein, dass vor dem Herunterfahren der Datenbank noch kürzlich verarbeitete Transaktionen noch nicht in die Datenbank geschrieben worden sind und Sie hier einen Datenverlust erfahren können. Hier ist es wesentlich die max. Dokument-ID (select max(docid) from elodmdocs) mit dem Filesystem zu vergleichen. Weicht diese vom FileSystem ab (Doc-Ids im Hexadezimalformat), dann hat die Datenbank zu wenig Dokumenteinträge. Bemängelt hier das DBCC CHECKDB hingegen Workflow-Tabellen, dann ist wahrscheinlich, dass hier in Verbindung mit den Workflows ein Schiefstand besteht. Sofern Sie hier aber keine „Mission critical“ Prozesse hinterlegt haben, ist das meist eher ein geringeres Problem. Wenn hier aber Rechnungsverarbeitungen angebunden sind, dann müssen Sie hier immer bewerten, ob es nicht hier zu Doppelzahlungen oder Zahlungsverzügen kommen kann.
• Bei sämtlichen Arten von Wiederherstellungen findet hier die Zuweisung des DBO-Users der Datenbank auf Basis der aktuellen Anmeldung statt. Dies ist im Normalfall der Systembenutzer oder ein administrativer Benutzer. Hier muss im Management Studio dann der Benutzer neu zugewiesen werden (Eigenschaften der Datenbank, Reiter „Dateien“, Besitzer). Das passende T-SQL Kommando hierzu ist sp_changedbowner @loginame = ‚elodb‘
• Wird eine neue Master-Datenbank verwendet (bspw. Komplette Neuinstallation des SQL Servers ohne Wiederherstellung der alten Master-Datenbank), dann muss der SQL-Benutzer erneut in der Master-Datenbank angelegt werden.
• Wird der Benutzer mittels Zuordnung / Rolle zugewiesen, dann ist bei neuer Master-Datenbank mit sp_autofixusers sicherzustellen, dass die Zuordnung nach der Wiederherstellung nach wie vor intakt ist. Das Kommando gibt normalerweise eine Information zurück wie viele Benutzer mittels „Namensgleichtheit“ wiederhergestellt worden sind (repaired orphaned Users / verwaiste User). Hier wird dann der native SQL-Benutzername mit der SID aus Master-Datenbank und der Archivdatenbank abgeglichen und repariert.