Ich bin derjenige, der mit SSIS völlig unwohl ist.
Wenn die Quelltabellen keine Identitätsspalten haben
- Erstellen Sie eine leere Datenbank auf dem Zielserver
- Erstellen Sie einen Verbindungsserver mit dem Quellserver auf dem Zielserver
- Führen Sie das folgende Skript in der Quellendatenbank aus, um select * into ... -Anweisungen zu generieren
- Führen Sie das generierte Skript aus der Zieldatenbank aus
- Skript-Primärschlüssel, Indizes, Trigger, Funktionen und Prozeduren aus der Quellendatenbank
- Erstellen Sie diese Objekte mit dem generierten Skript
Nun die T-SQL, um die Select * into ... -Anweisungen zu generieren
SET NOCOUNT ON
declare @name sysname
declare @sql varchar(255)
declare db_cursor cursor for
select name from sys.tables order by 1
open db_cursor
fetch next from db_cursor into @name
while @@FETCH_STATUS = 0
begin
Set @sql = 'select * into [' + @name + '] from [linked_server].[source_db].[dbo].[' + @name + '];'
print @sql
fetch next from db_cursor into @name
end
close db_cursor
deallocate db_cursor
Dies erzeugt eine Zeile für jede Tabelle, die kopiert werden soll
select * into [Table1] from [linked_server].[source_db].[dbo].[Table1];
Für den Fall, dass die Tabellen Identitätsspalten enthalten, schreibe ich die Tabellen mit Identitätseigenschaft und Primärschlüsseln.
In diesem Fall verwende ich Einfügen in ... Auswählen ... nicht über einen Verbindungsserver, da dies keine Massentechnik ist. Ich arbeite an einigen PowerShell-Skripten, die [dieser SO-Frage 1] ähneln , aber ich arbeite immer noch an der Fehlerbehandlung. Wirklich große Tabellen können Speicherfehler verursachen, da eine ganze Tabelle in den Speicher geladen wird, bevor sie über SQLBulkCopy an die Datenbank gesendet wird.
Die Neuerstellung von Indizes usw. ähnelt dem obigen Fall. Dieses Mal kann ich die Neuerstellung der Primärschlüssel überspringen.
