Datenbank Kopie SQL Express
Hallo in die Runde,
Problem :
eine Datenbank Warenwirtschaft, auf einen 2003 Server mit SQL Express Version 8.000, soll auf einen neuen Windows 2022 Std ebenso SQL Express aktuelle Version 15.00 umziehen . Beides VM auf unterschiedlichen Exsi Host.
Unterschiedlich weil, ein Blech wegkommt und neues hingestellt wurde
SQL Server rentiert sich nicht, da DB nur 3 GB hat.
Bisher:
Datenbank gesichert auf Server old, dann über Netzwerk auf Server neu in Ordner SQL Server Backup Ordner kopiert.
Das Sichern der DB auf alt funktioniert auch das restore im Test, aber Wiederherstellen auf neu schlägt fehl.
Weil alte Version SQL und neue inkompatibel sind.
Was kann man da als Lösung nutzen?
Da gibts schon Beitrag aber , das Problem gelöst schein da nicht zu sein
SQL-2017: Datei oder Assembly "Microsoft.SqlServer.SmoExtended, Version 11" nicht gefunden
Danke schon mal.
Problem :
eine Datenbank Warenwirtschaft, auf einen 2003 Server mit SQL Express Version 8.000, soll auf einen neuen Windows 2022 Std ebenso SQL Express aktuelle Version 15.00 umziehen . Beides VM auf unterschiedlichen Exsi Host.
Unterschiedlich weil, ein Blech wegkommt und neues hingestellt wurde
SQL Server rentiert sich nicht, da DB nur 3 GB hat.
Bisher:
Datenbank gesichert auf Server old, dann über Netzwerk auf Server neu in Ordner SQL Server Backup Ordner kopiert.
Das Sichern der DB auf alt funktioniert auch das restore im Test, aber Wiederherstellen auf neu schlägt fehl.
Weil alte Version SQL und neue inkompatibel sind.
Was kann man da als Lösung nutzen?
Da gibts schon Beitrag aber , das Problem gelöst schein da nicht zu sein
SQL-2017: Datei oder Assembly "Microsoft.SqlServer.SmoExtended, Version 11" nicht gefunden
Danke schon mal.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 4874185916
Url: https://administrator.de/forum/datenbank-kopie-sql-express-4874185916.html
Ausgedruckt am: 26.12.2024 um 15:12 Uhr
12 Kommentare
Neuester Kommentar
Moin,
musst wohl einen(mehrere) Zwischenschritt(e) bei der Migration unternehmen.
MS sagt das hier..
und der 2012er lässt sich wie folgt migrieren:
Grüße
musst wohl einen(mehrere) Zwischenschritt(e) bei der Migration unternehmen.
MS sagt das hier..
SQL Server 2022 (16.x) supports upgrade from the following versions of SQL Server:
SQL Server 2012 (11.x) SP4 or later
SQL Server 2014 (12.x) SP3 or later
SQL Server 2016 (13.x) SP3 or later
SQL Server 2017 (14.x)
SQL Server 2019 (15.x)
und der 2012er lässt sich wie folgt migrieren:
- Step 1: Make a first migration from SQL 2000 to SQL 2008 for instance. You need to be SQL 2000 SP4, then follow this step : Migration SQL Server 2000 to SQL Server 2008
- Step 2: Make a second migration from SQL Server 2008 to 2012.
Grüße
Hey,
ich habe mal etwas mit GPT rumgefummelt, der würde folgendes vorschlagen:
Das Ding ist der oberhammer! :D
VG
Würde mich ja interessieren, ob das so gehen würde. :D
ich habe mal etwas mit GPT rumgefummelt, der würde folgendes vorschlagen:
how to migrate sql 2003 to sql 2022?
To migrate a database from SQL Server 2003 to SQL Server 2022, you can use the following steps:
Backup the database from the SQL Server 2003 instance using the BACKUP DATABASE statement.
Copy the database backup file to the server that is running SQL Server 2022.
Restore the database on the SQL Server 2022 instance using the RESTORE DATABASE statement.
Here is an example of the BACKUP DATABASE and RESTORE DATABASE statements that you can use:
-- Backup the database on the SQL Server 2003 instance
BACKUP DATABASE MyDatabase
TO DISK = 'C:\MyDatabase.bak'
-- Restore the database on the SQL Server 2022 instance
RESTORE DATABASE MyDatabase
FROM DISK = 'C:\MyDatabase.bak'
WITH REPLACE;
After restoring the database, you may need to update the compatibility level of the database to match the version of SQL Server 2022. You can do this using the ALTER DATABASE statement.
ALTER DATABASE MyDatabase
SET COMPATIBILITY_LEVEL = 150;
It's also a good idea to run the DBCC CHECKDB statement on the migrated database to verify its integrity.
DBCC CHECKDB ('MyDatabase')
WITH NO_INFOMSGS;
Note: These steps assume that the source and target databases have the same collation settings. If the collation settings are different, you will need to use the WITH MOVE option in the RESTORE DATABASE statement to specify the new collation settings. You can also use the COLLATE clause in the ALTER DATABASE statement to change the collation of the database.
Das Ding ist der oberhammer! :D
VG
Würde mich ja interessieren, ob das so gehen würde. :D
Zitat von @Bingo61:
Servus,
Danke habs befürchtet.
Krux ist, der Software Entwickler der WW, sitzt in Kuala Lumpur hat aber München als Firmenadresse.
Der Typ hat keinen Bock, seinen Kunden seine Software wieder arbeitsfähig stellen.
Servus,
Danke habs befürchtet.
Krux ist, der Software Entwickler der WW, sitzt in Kuala Lumpur hat aber München als Firmenadresse.
Der Typ hat keinen Bock, seinen Kunden seine Software wieder arbeitsfähig stellen.
Ja aber so aufwendig ist der Spaß doch nicht dass man den Entwickler braucht, sofern die Anwendung überhaupt mit einem neuen SQL klar kommt.
Auf einer Temp VM eine etwas älteren SQL einrichten da das Backup zurückspielen. Den "compatibility level" hoch setzen und noch mal ne runde drehen.
Übrigens der SQL Express hat nicht nur Nachteile bezüglich DB Größe sonder auch Geschwindigkeit.
Alternativ wäre auch das Import and Export Modul das jeder SQL Server besitzt ne Möglichkeit.
Der verbindet sich auf beide Server per ODBC und schiebt die Daten rüber.
Bei sowas muss man immer etwas "spielen"
Moin,
den Import per Skript versuchen, wie es 0xFFFF vorschlägt, kann man zwar probieren, aber damit umgeht man ja nur die Bedienoberfläche vom Management Studio. Die Skripte, die nötig sind, die DB von SQL Server 2000 auf 2012 zu bringen, werden dann kaum ausgeführt werden.
Du wirst wohl die Schritte gehen müssen, erst auf SQL Server 2008 / 2008R2, dann 2012 - 2017 und anschließend auf 2022 zu gehen.
Allerdings frage ich mich auch, ob Eure DB auf so einer neuen Version überhaupt lauffähig ist. Das müßte Euch eigentlich der Entwickler beantworten, aber wenn der nicht greifbar ist ...
Gruß, Mad Max
den Import per Skript versuchen, wie es 0xFFFF vorschlägt, kann man zwar probieren, aber damit umgeht man ja nur die Bedienoberfläche vom Management Studio. Die Skripte, die nötig sind, die DB von SQL Server 2000 auf 2012 zu bringen, werden dann kaum ausgeführt werden.
Du wirst wohl die Schritte gehen müssen, erst auf SQL Server 2008 / 2008R2, dann 2012 - 2017 und anschließend auf 2022 zu gehen.
Allerdings frage ich mich auch, ob Eure DB auf so einer neuen Version überhaupt lauffähig ist. Das müßte Euch eigentlich der Entwickler beantworten, aber wenn der nicht greifbar ist ...
Gruß, Mad Max
Im Prinzip genau das, was ich im ersten Post geschrieben hatte.
Wünsche Glück, dass alles rund läuft.
Dein Ernst? Die Lösung von MadMax kam später als die Meinige und dennoch ist das die Lösung?
Naja, ..
Grüße
Wünsche Glück, dass alles rund läuft.
Dein Ernst? Die Lösung von MadMax kam später als die Meinige und dennoch ist das die Lösung?
Naja, ..
Grüße
Hallo Bingo61,
Du solltest den SQL Server nochmal normal starten, also ohne Einzelbenutzermodus, und dann feststellen, wer da schneller ist mit der Anmeldung.
Starte das Management Studio, aber melde dich nicht an.
Öffne eine neue Abfrage (da mußt Du Dich anmelden) und führe folgenden Befehl aus:
Da sind alle Verbindungen aufgeführt. Eine davon ist Deine, Deine SessionID findest Du rechts unten in der Statusleiste neben dem Benutzernamen in klammern, also z.B. "sa (60)", "sa" ist dann der Benutzername und Deine SessionID ist 60. (Oder Du stellst sie fest mit "select @@spid").
Alle anderen sollten da nicht sein. Du mußt schauen, was das für Verbindungen sind und mußt die unterbinden. Vielleicht ist der Spionagedienst vom SQL Server dabei (SQL Server CEIP service), den könntest Du dann deaktivieren. Eben je nachdem, welche Verbindungen da sind, mußt Du sehen, wie Du die los wirst.
Wenn Du alle identifiziert und eliminiert hast, kannst Du es nochmal probieren mit dem Einzelbenutzermodus.
Denk aber dran, falls irgendwelche Verbindungen gewollt sind, die hinterher wieder einzuschalten.
@Uhli90: Grundsätzlich hast Du natürlich recht, daß man dort keine Daten ablegen soll, aber Systemdaten, insbesondere Anmeldedaten, sind halt trotzdem dort.
Gruß, Mad Max
Du solltest den SQL Server nochmal normal starten, also ohne Einzelbenutzermodus, und dann feststellen, wer da schneller ist mit der Anmeldung.
Starte das Management Studio, aber melde dich nicht an.
Öffne eine neue Abfrage (da mußt Du Dich anmelden) und führe folgenden Befehl aus:
select *
from sys.dm_exec_sessions s
join sys.dm_exec_connections c on c.session_id = s.session_id
order by s.session_id
Alle anderen sollten da nicht sein. Du mußt schauen, was das für Verbindungen sind und mußt die unterbinden. Vielleicht ist der Spionagedienst vom SQL Server dabei (SQL Server CEIP service), den könntest Du dann deaktivieren. Eben je nachdem, welche Verbindungen da sind, mußt Du sehen, wie Du die los wirst.
Wenn Du alle identifiziert und eliminiert hast, kannst Du es nochmal probieren mit dem Einzelbenutzermodus.
Denk aber dran, falls irgendwelche Verbindungen gewollt sind, die hinterher wieder einzuschalten.
@Uhli90: Grundsätzlich hast Du natürlich recht, daß man dort keine Daten ablegen soll, aber Systemdaten, insbesondere Anmeldedaten, sind halt trotzdem dort.
Gruß, Mad Max