Datenbank auf einen anderen Server und eine neuere SQL Server Version umziehen

[stefannsv 0]

Hallo zusammen,

wir haben eine Anwendung (kompiliertes Frontend), die uns von einigen Jahren eine externe Firma erstellt hat.

Die Datenbank "OAS" zur Anwendung liegt auf einer VM namens "sql1-vm". Dort läuft ein SQL Server 2008 Express. Die Datenbank läuft unter dem Kombatibilitätsgrad 80. 

"OAS_Admin" ist eine Gruppe in unserem AD.

 

Für die Anwendung sind folgende Registryeinträge unter HKCU\VB and VBA Program Settings\OASServer\Default hinterlegt:

SQL-Servername->REG_SZ->"sql1-vm"
OhneDomäne->REG_SZ->"-1"
GruppeOhneDomäne->REG_SZ->"OAS_Admin"
DB-Name->REG_SZ->"OAS"

 

Jetzt möchten wir diese Datenbank auf einen anderen Server (2019) mit SQL Server 2014 umziehen.

Dazu haben wir das Backup der "alten" Datenbank, auf dem neuen Server "wiederhergestellt".

Der neue Server heißt "DWH2" und die SQL Server Instanz dazu "Allgemein".

Hab den Regeintrag wie folgt geändert:

SQL-Servername->REG_SZ->"DWH2\Allgemein"
OhneDomäne->REG_SZ->"-1"
GruppeOhneDomäne->REG_SZ->"OAS_Admin"
DB-Name->REG_SZ->"OAS"

 

Wenn ich jetzt aber die Anwendung starte, kommt folgende Meldung:

Die globalen NT-Gruppen konnten für den angemeldeten User nicht ausgelesen werden.
Überprüfen sie ihre NT-Gruppen bzw. stellen sie sicher, dass der PDC einwandfrei läuft.
Order by-elemente müssen in der Auswahlliste angezeigt werden, wenn die anweisung einen union-, intersect- oder except-Operator enthält.
Benutzergruppen: 'OAS-Admin'

 

Kann mir hier vielleicht jemand weiterhelfen?

 

Vielen Dank im Voraus :)

[NilsK 2.785]

Moin,

 

dann macht die Applikation irgendwas auf einem recht ... individuellen Weg und nicht so, wie es vom Betriebssystem gedacht ist. Am schnellsten wird sich das lösen lassen, wenn der Hersteller dieser Applikation sich dazu äußert.

 

Mal ins Blaue geschossen: Vielleicht kommt die Applikation nicht mit dem Zugriff auf eine Named Instance des SQL Servers klar. Ich würde es mal mit der Standardinstanz versuchen. (Ohnehin ist von separaten Instanzen in den allermeisten Fällen abzuraten.)

 

Gruß, Nils

 

[stefannsv 0]

Hallo Nils,

 

vielen Dank für deine schnelle Antwort.

Den Hersteller der Anwendung kann ich leider nicht mehr greifen. Das war im Jahr 2007 und die Firma macht in diese Richtung nicht mehr weiter.

 

Wir haben auf dem neuen Server "DWH2" nur Instanzen. Ohne Instanzen wäre das ein zu großer Wust.

Ich könnte evtl. eine neue VM mit einer neueren Express Version installieren und es da versuchen. Dann wäre zumindest das mit der Instanz weg.

 

VG Stefan

 

[NilsK 2.785]

Moin,

 

vor 24 Minuten schrieb stefannsv:

Wir haben auf dem neuen Server "DWH2" nur Instanzen. Ohne Instanzen wäre das ein zu großer Wust.

dieses Konzept solltet ihr überdenken. SQL Server ist von der Architektur her dafür vorgesehen, mehrere - auch viele - Datenbanken innerhalb derselben (Standard-) Instanz zu betreiben. Dann läuft er effizient. Die Option, separate Instanzen zu betreiben, ist eher als Notlösung für wenige Situationen gedacht.

 

Es ist nur ein Schuss ins Blaue, aber so, wie du es beschreibst, kann ich mir gut vorstellen, dass die Instanz hier das Problem ist. Ich würde es also zumindest mal mit einer Standardinstanz versuchen, ob es dann läuft.

 

Meine Spekulation: Die Fehlermeldung ist irreführend und wird dadurch ausgelöst, dass die Applikation die Datenbank gar nicht erst ansprechen kann. Sie meldet zwar Authentisierungsprobleme, aber da ihr vermutlich an der Domäne überhaupt nichts geändert habt, dürfte die Fehlermeldung "falsch" sein. Darüber hinaus deutet der Verweis auf einen PDC (den es seit Windows 2000 nicht mehr gibt) darauf hin, dass der Hersteller sein Handwerk nicht gut beherrschte.

 

Gruß, Nils

[t-sql 17]

Am besten machst Du erstmal folgenden Versuch:

Kannst Du dich mit einem Mitglied der Gruppe "OAS_Admin" per SSMS an dem SQL Server anmelden? Wenn ja gibts kein Problem mit dem Datenbankserver -> Applikationsproblem. 

[stefannsv 0]

vor 10 Stunden schrieb t-sql:

Am besten machst Du erstmal folgenden Versuch:

Kannst Du dich mit einem Mitglied der Gruppe "OAS_Admin" per SSMS an dem SQL Server anmelden? Wenn ja gibts kein Problem mit dem Datenbankserver -> Applikationsproblem. 

Moin zusammen,

den Test hab ich gerade erfolgreich gemacht. Also liegt es nicht am SQL Server selbst.

 

Werd jetzt wie bereits gesagt, nen VM mit Server 19 und SQL Express 19 hochziehen und das testen

 

VG Stefan

[stefannsv 0]

So hab die Datenbank jetzt auf einen Server 2019 mit SQL Express 2019 importiert (BAK wiederhergestellt).
Zugriff über SSMS mit User in der "OAS_Admin" Gruppe getestet. Läuft.
Zugriff über das Frontend Fehlanzeige. Die Fehlermeldung ist immer noch die selbe:
Die globalen NT-Gruppen konnten für den angemeldeten User nicht ausgelesen werden.
Überprüfen sied ihre NT-Gruppen bzw. stellen sie sicher, dass der PDC einwandfrei läuft.
Order by-elemente müssen in der Auswahlliste angezeigt werden, wenn die anweisung einen union-, intersect- oder except-Operator enthält.
Benutzergruppen: 'OAS-Admin'
Der Regeintrag sieht jetzt wie im Anhang aus. Der funktioniernde siehr genauso aus, nur das bei SQL-Servername "SQL1-VM" steht.
 

bearbeitet 30. August 2023 von stefannsv

[NilsK 2.785]

Moin,

 

dann liegt es also auch nicht daran, dass die Applikation mit einer Named Instance nicht klarkäme, sondern sie macht irgendwas anderes falsch oder zumindest sehr speziell. Da kann man jetzt einen Zufallstreffer landen oder sehr viel Aufwand investieren. Nur sicherheitshalber: an der Domäne oder anderen Komponenten der Umgebung habt ihr nichts geändert?

 

Geht es denn weiterhin in der alten Mimik? Dann könnte es eine Option sein, die als Insel weiter laufen zu lassen und sich parallel um eine neue Lösung der Business-Anforderungen zu kümmern.

 

Gruß, Nils

 

[q617 1]

Der Test  mit dem SSMS war auf dem Server direkt, oder?

 

Die "neueren" SQL-Server machen standardmässig Verschlüsselung (glaub ich), hast du testweise mal SQL 2012 express probiert?

 

Vielleicht brauchts aufm dem Client eine neue ODBC-Bibliothek oder so.

[stefannsv 0]

Nein an der Domäne wurde nichts geändert. Was sich geändert hat war:
Alt    

Server 2012R2

 

Neu

Server 2019

 

ODBC
Alt

Microsoft SQL Server ODBC-Treiber Version 10.00.19041

Datenquellenname: OAS
Datenquellenbeschreibung: OAS Datenquelle
Server: SQL1-VM
Datenbank: OAS
Sprache: (Default)
Zeichen konvertieren: Yes
Abfragen mit langer Laufzeit protokollieren: No
Protokolltreiberstatistik: No
Ländereinstellungen verwenden: No
Option für vorbereitete Anweisungen: Temporäre Prozeduren beim Trennen löschen
Failover-Server verwenden: No
ANSI-Anführungszeichen verwenden: Yes
ANSI-Nullen, -Leerzeichen und -Warnungen verwenden: Yes
Datenverschlüsselung: No

####

Test OK

####

Neu
Microsoft SQL Server ODBC-Treiber Version 10.00.19041

Datenquellenname: OAS
Datenquellenbeschreibung: OAS Datenquelle
Server: SQL1VM
Datenbank: OAS
Sprache: (Default)
Zeichen konvertieren: Yes
Abfragen mit langer Laufzeit protokollieren: No
Protokolltreiberstatistik: No
Ländereinstellungen verwenden: No
Option für vorbereitete Anweisungen: Temporäre Prozeduren beim Trennen löschen
Failover-Server verwenden: No
ANSI-Anführungszeichen verwenden: Yes
ANSI-Nullen, -Leerzeichen und -Warnungen verwenden: Yes
Datenverschlüsselung: No

####

Test OK

[testperson 1.534]

Hi,

 

ggfs. die VM kopieren und einen Versuch per In-Place Upgrade starten sofern es da supportete Pfade (erst SQL dann OS oder andersrum) gibt?

 

Gruß

Jan

[stefannsv 0]

OK also VM clonen in neue VM dann InplaceUpgrade SQL Express. Geht das überhaupt?, Zuletzt InPlace Upgrade OS.

 

VG Stefan 

vor 2 Stunden schrieb NilsK:

Moin,

 

dann liegt es also auch nicht daran, dass die Applikation mit einer Named Instance nicht klarkäme, sondern sie macht irgendwas anderes falsch oder zumindest sehr speziell. Da kann man jetzt einen Zufallstreffer landen oder sehr viel Aufwand investieren. Nur sicherheitshalber: an der Domäne oder anderen Komponenten der Umgebung habt ihr nichts geändert?

 

Geht es denn weiterhin in der alten Mimik? Dann könnte es eine Option sein, die als Insel weiter laufen zu lassen und sich parallel um eine neue Lösung der Business-Anforderungen zu kümmern.

 

Gruß, Nils

 

Der Server ist von extern nicht erreichbar, insofern ist es nicht ganz so tragisch ihn auf Server 12R2 und SQL Express 2008 laufen zu lassen.
Aber ein langfriste Lösung suchen wir natürlich schon.

vor 1 Stunde schrieb q617:

Der Test  mit dem SSMS war auf dem Server direkt, oder?

 

Die "neueren" SQL-Server machen standardmässig Verschlüsselung (glaub ich), hast du testweise mal SQL 2012 express probiert?

 

Vielleicht brauchts aufm dem Client eine neue ODBC-Bibliothek oder so.

Der Test war auf einem Terminalserver mit SSMS.

[testperson 1.534]

vor 1 Stunde schrieb stefannsv:

OK also VM clonen in neue VM dann InplaceUpgrade SQL Express. Geht das überhaupt?, Zuletzt InPlace Upgrade OS.

Die Frage wäre, was die Applikation letztlich alles braucht. Im Idealfall orginal VM herunterfahren, Disk wegkopieren, dann eine neue VM mit der kopierten Disk ohne Netzwerk / in einem getrennten Netzwerk bereitstellen und dann mit dem Testen beginnen.

 

Nach Supported version and edition upgrades (SQL Server 2017) - SQL Server | Microsoft Learn und Upgrade: Installation Wizard (Setup) - SQL Server | Microsoft Learn sollte ein Upgrade von SQL 2008 zu SQL 2017 auf Windows Server 2012 R2 machbar sein.

 

[NilsK 2.785]

Moin,

 

vor 2 Stunden schrieb stefannsv:

Aber ein langfriste Lösung suchen wir natürlich schon.

 

dann solltet ihr erwägen, sie neu bauen zu lassen. Egal mit welchen Tricks ihr die Applikation vielleicht zum Laufen bekommt - sie ist 16 Jahre alt, nicht supportet und offenkundig schlecht gebaut.

 

Gruß, Nils

 

[zahni 521]

Wir sollten hier mal klären:

 

Wie meldet sich die Anwendung beim SQL an? Üblich ist SQL-Authentifizierung und seltener  integrierte Windows Authentifizierung. 

 Integrierte Windows Authentifizierung erfordert eine korrekte Kerberos-Konfiguration (SPNs setzen, etc). Der Client (in dem Fall die Anwendung) muss dann unter einem Domänen-Konto laufen, dass die entsprechenden Rechte auf der DB hat. U.U. ist dies auch das Computer-Konto.  Da das selten einfach ist, wird häufig die andere Option genutzt. Was "GruppeOhneDomäne" damit zu tun haben soll, keine Ahnung. Muss irgendwas internes der Applikation sein.

 

Ist den Instanz ein TCP-Port zugewiesen?