Tabellen aus einer DB in andere zeitgesteuert schreiben

olibasto

Benutzer
Beiträge
6
Hallo zusammen,

als Newbie in der Thematik SQL setze ich mich gerade mit folgendem Problem auseinander:

Wir haben einen SQL Server, wo abends zeitgesteuert Tabellen aus unserer Navision Datenbank in einer anderen Datenbank eines anderen SQL Servers kopiert bzw. in Zukunft dann überschrieben werden sollen.

Wie gehe ich da am besten dran?
Per Hand habe ich es schon hingekriegt, aber Zeitgesteuert?!


Ich bin euch für eure Unterstützung sehr dankbar!
 
Werbung:
Du schreibst es wird bereits Abends von der einen in die andere DB geschrieben. Wie findet das denn statt? Welche MS SQL DBs sind im Einsatz? Was genau willst du verändern?
 
Hmmm, nicht ganz richtig...

Wir haben z.Zt. einen SQL Server 2005 mit einer Navision Datenbank im Einsatz .
Es ist erwünscht, dass ein weiterer SQL Server in der Version 2008 aufgesetzt werden soll, und dass auf diesem täglich Zeitgesteuert (abends) gezielte Tabellen aus dem 2005er auf dem 2008er kopiert werden.
Für mich hört sich dass nach einem "Job" an, der per SQL Taskplaner täglich durchlaufen werden soll - so die Theorie...
 
Also zugegeben: Ich habe bisher noch nichts zeitgesteuert in SQL gemacht. Ich bin mir aber sicher, das soetwas geht (zumindest mit der Vollversion, in SQL Express könnte das Probleme geben). Wenn man Tabellen in der Ziel DB komplett leert und wieder befüllt und keine Trigger auf der Tabelle liegen die Probleme machen ist der Code in SQL auch simpel. Allerdings muss man sich natürlich auch nach dem Sinn fragen, wäre eine Sicht auf die aktuellen Daten nicht besser?
 
Hintergrund des ganzen ist, daß unser Controler mit den Daten arbeitet. Und solange er seine Abfragen an die SQL 2005 mit den aktuellen Daten schickt, bedanken sich alle übrigen Mitarbeiter, die blöd in die Röhre gucken, da alles sehr Träge wird.
Und da der Controler nicht unbedingt mit Tagesaktuellen Daten arbeiten muss, möchten wir ihm diese als Kopie separat zur Ferfügung stellen.

Je nachdem wie sich das ganze dann entwickelt, möchten wir quasi eine Art Data Warehouse aufbauen, wo gezielte Daten in aufbereiteter Form bereitgestellt werden.


Aber irgendwie muss ich erstmal den ersten Teil überstehen ;-)
 
Hört sich schonmal nicht nach SQL Express an :)

Du solltest dich mal mit Replikation auseinander setzen, ich kann mir nicht vorstellen, das es so schwer ist einmal Täglich die Daten auf einen anderen SQL Server zu replizieren. Da ich erst seit 2 Wochen stolzer Besitzer eines vollweritgen SQL 2008 bin, kann ich da noch keine Tipps geben... Ansonsten kann ich dir aber helfen, einen Batch für eine Tabelle zu schreiben der die Tabelle droppt, neu erstellt und befüllt - das ist aber nicht schwer ;)
 
Hi,
Leg' Dir im SQL2005 einen "Linked Server" [im Deutschen SSMS "SQLServerManagementStudio" heisst das "Verbindungsserver"] zu dem anderen Server SQL 2008 an.
Also einen frei wählbaren Namen, der auf den anderen Server zeigt und Anmeldeinformationen enthält.
Details findest Du in der Hilfe.
Dann kannst Du auf die Spalten im anderen Server zugreifen indem Du einen 4-teiligen Pfad angibst:
<Verbindungsservernamen>.<Datenbankname>.<Schemaname>.<Tabellenname>
Z.B::SQL2008.ControllerDB.dbo.Auftraege

Dann schreibst Du in Deinem SQL 2005 ein Script das Du als StoredProcedure speicherst:
--------------------------------------------------------------------------
Truncate Table SQL2008.ControllerDB.dbo.Auftraege -- Leert die Tabelle, also VORSICHT
Insert SQL2008.ControllerDB.dbo.Auftraege
(Kunde,Auftraege)
Select Kunde, Auftraege from Auftraege
--------------------------------------------------------------------------

Diese StoredProcedure kannst Du dann im SQL-Serveragent als Job mit einem einfachen Zeitplan einrichten.
EXEC <StoredProcedurename>

Das ist mal die grobe Übersicht Da ist keine Fehlerbehandlung oder Sicherheitsüberlegung drin.
Mit dem SMSS kannst Du fast alles mit der Maus erledigen.
 
@Ritschi, vielen Dank für deine detaillierte Anleitung!!!

Momentan versuche ich es über einen anderen Weg - Replikation "Verteiler und Anonnent".
Da habe ich die Möglichkeit explizit aus einer Datenbank auch gezielte Tabellen auszuwählen, die ich repliziert haben möchte, was die Sache noch interessanter macht.
Auch ein Zeitablauf kann dort angegeben werden (per Taskplaner). Bei der Einrichtung habe ich mich für die "Merge" Variante entschieden.

Noch taste ich mich an die Sache ran, aber liege ich bei meiner Vorgehensweise richtig?
 
Ich würde sagen ja, habe allerdings noch nie repliziert. Da die Vollversion von SQL sowas bietet, würde ich es persönlich einer Script Lösung vorziehen, auch wenn ein Linked Server wie oben beschrieben vermutlich einwandfrei seinen Dienst tut. Der "vorgesehene Weg" von MS ist hier sicherlich nicht die falsche Wahl und im Fehlerfall für einen Dritten leichter nachvollziehbar.
 
So, in der Testumgebung hat es geklappt, jedoch scheitere ich im Livesystem.
Bekomme auf Seite des Verteilers (Server mit den Daten) über den replikationsmonitor folgende Fehlermeldung:

SQL.jpeg

Habe auch schon als auszuführenden Benutzer meinen hinterlegt, da ich auch Administratorrechte besitze. Aber auch da erscheint die gleiche Fehlermeldung.
Ich wüsste aber nicht, welches Recht ihm noch fehlen könnte.

Hier noch das Fenster, wo der Benutzer einzutragen ist (Eigenschaften der Lokalen Publikation):

SQL-02.jpeg



Vielen Dank für jede Hilfe!
 
Hi,
Das Problem liegt auf dem Abonenten, nicht auf dem Verteiler. Eine Merge Replikation heisst aber das die Daten auch wieder von der Replikation zurückgeschrieben werden sollen.
Der Controller soll doch nur eine Read-Only-Kopie bekommen, dann wäre es eher eine Snapshot- oder Transaktionsreplikation, je nach Datenmenge.
Bei kleineren Datenmenge Snapshot, ansonsten Transaktionsreplikation.
Bei Dir liest sich das aber wie eine Push Replikation mit Snapshotreplikation, weil abends bestimmte Tabellen auf dem anderen Server landen sollen.
Da sollte dann auch die Rechte Vergabe einfacher sein.
 
Ja, das ist richtig, es soll nur eine Read-Only Kopie erstellt werden.
Da werde ich mich am WE nochmals mit auseinandersetzen, um nicht im Laufenden Betrieb alles eventuell lahm zu legen;)

Werde am Montag berichten was draus geworden ist.
 
Werbung:
Zurück
Oben