Announcement

Collapse
No announcement yet.

partielles Update auf Tabelle via SSIS

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • partielles Update auf Tabelle via SSIS

    Hallo zusammen,

    ich beschäftige mich momentan mit den Integration Services von SQL S 2005.
    Ich habe bereits einen Datenfluss angelegt.
    Hierbei soll eine Oracle Tabelle(OLE DB Source) komplett in eine SQL Server 2005 Tabelle(OLE DB Destination)hineingezogen werden.Das klappt soweit auch, die Daten werden erfolgreich in meine SQL Tabelle eingespielt. Nun möchte ich aber nicht immer die Tabelle komplett Droppen und Neuaufbauen, sondern nur die Datensätze der Oracle Tabelle (Source) in die Destinationtabelle einfügen,löschen,ändern die eben in der Sourcetabelle gelöscht,geändert oder eingefügt wurden.
    Die Daten der Destinationtabelle bei denen keine Änderung vorgenommen wurde, sollen einfach in der Tabelle weiterhin bestehen.
    Wisst ihr einen Rat? Ich habe es bereits mit Lookup versucht, bin jedoch kläglich gescheitert, da ich kein zugeschnittenes Beispiel gefunden hab.

    Kennt jemand eine Lösung?

    MfG,
    Sensewell

  • #2
    Hallo Sensewell,

    seit SQL Server 2008 gibt es den Merge Befehl, der hier passen würde; nur hast Du 2005.

    Sieh Dir mal den Datenfluss-Task "Langsam veränderliche Dimension" (Slowly changing dimension, SCD) an, der ist hier gedacht. (siehe Kimball)
    Die Zusatzfunktionen für Timestamp etc kannst Du dabei einfach ignorieren, es ist halt ein universelleres Task.
    Olaf Helper

    <Blog> <Xing>
    * cogito ergo sum * errare humanum est * quote erat demonstrandum *
    Wenn ich denke, ist das ein Fehler und das beweise ich täglich

    Comment


    • #3
      Guten Morgen,

      danke für deine Antwort. Ich werde das mal die Tage ausprobieren.

      Ich habe nun leider ein zweites Leiden.
      Ich entwickle lokal auf meiner Workstation dieses SSIS Projekt. Hierbei habe ich die 2 Connection Manager bzw. VErbindungen eingerichtet. Die eine Verbindung ist für einen SQL-Server(Provider: MS OLE DB PROVIDER for SQL Server) und die andere für die Oracle DB.
      Nun musste ich, um mich zu Oracle überhaupt eine Verbindung aufzunehmen eine Datenquelle (ODBC) einrichten. Ich habe mich für eine System-DNS entschieden, und kann diese dann auch im ConnectionManager(Provider: Native OLEDB\Oracle Provider for OLE DB, Servername = DNS Name) angeben.
      Soweit so gut, wenn ich jetzt jedoch das Paket auf einen DB-Server importiere und es danach ausführe bekomme ich im Execution P. folgende Meldung sobald er auf die Oracle DB zugreifen möchte: ERROR: SSIS Error Code DTS_E_CANNOTACQUIRERECONNECTIONFROMCONNECTIONMANAG ER. The AcquireConnection method call to to connection manager "oracledb.username" failed with error code 0xV0202009

      Meine erste Überlegung war, dass die SystemDNS ja nicht auf dem Server vorhanden ist. Habe darauf die System-DNS eingerichtet--> eben genau die Einträge von meiner lokalen Maschine.
      Danach bekomme ich immernoch die gleiche Fehlermeldung. Meine 2. Überlegung ist nun, ob es an den unterschiedlichen Treiberversionen (lokal: Oracle 9.2; Server: Oracle 10g_home1) liegt.
      Hat jemand sich mit solch einem Problem bereits befasst? Kann ich das Paket nicht so deployen, dass er auf dem Server keinerlei Eingriffe auf das vorhandene BS(z.B. auf die System-DNS) vornehmen muss?

      LG,

      Sensewell

      P.S: Ich habe jetzt kein neues Thema aufgemacht, damit der Hintergrund klar ist.

      Comment


      • #4
        1. Eine System-DSN musst Du eh immer nehmen, da SSIS / das Paket nicht unter Deinem Account läuft (bzw. besser nicht sollte). Damit andere Accounts dran kommen, muss es eine System-DSN sein.

        2. "Native OLEDB\Oracle Provider for OLE DB" verwendet keine ODBC Verbindung, sonst könntest Du sie auch auswählen. Hier musst Du den TnsName für Oracle eintragen.

        Grundsätzlich ist folgendes zu beachten:
        - Oracle Treiber müssen installiert sein. Sie sind m.W. halbwegs abwärtskompatibel, d.h. mit einem 10.0 Treiber kannst Du auch auf 9.2 zugreifen
        - TnsNames.ora muss natürlich auch vorhanden und mit den richtigen=gleichen Servernamen und IP sein
        - Teste auf dem Server, wo SSIS läuft, ob Du auf Oracle zugreifen kannst, z.B. mit SQL*Plus
        - Wenn die Anmeldung an Oracle über Windows Account läuft, dann meldet sich SSIS mit seinem Dienst-Konto an. Der Account braucht also auch entsprechende Rechte. Entweder einrichten oder Dienst-Konto umkonfigurieren.

        Grundsätzlich funktioniert das alles, bei mir läuft der Datenabzug aus Oracle via SSIS jedenfalls.
        Olaf Helper

        <Blog> <Xing>
        * cogito ergo sum * errare humanum est * quote erat demonstrandum *
        Wenn ich denke, ist das ein Fehler und das beweise ich täglich

        Comment


        • #5
          Moin,


          ich habe nun für die Oracle Table eine "Data Reader Source " genommen. Davor habe ich aus dem connection Manager eine "New Connection" -ADO.Net:ODBC Data Provider erstellt.
          Darauf konnte ich meine DSN(System) auswählen und musste ein PW und User angeben. Soweit so gut- Test COnnection etc. klappt alles, Datenfluss läuft durch ohne Fehler.

          Nun habe ich das jedoch alles "lokal" bei mir gemacht- Darauf habe ich ein "develop" durchgeführt und die Manifestdatei gestartet um das Paket auf das Filesystem zu legen.
          Darauf bin ich auf meinen SQL-Server und habe per Import das Package auf den Server importiert. Darauf bekomme ich beim ausführen folgende Fehlermeldung:
          ERROR: System.Data.OracleClient.Oracle Exception: ORA-01005: null passwort given; logon dinied .....

          nachdem ich gegoogelt habe, fand ich heraus, dass es daran liegt, dass das PW von BIDS verschlüsselt wird und nur von "mir" als Ausführender entschlüsselt wird. Wie regel ich diese Angelegenheit, um diese Entschlüsselung/Verschlüsselung zu umgehen? Mit "use Connection String" habe ich bereits versucht, jedoch scheint mir dieser auch verschlüsselt zu werden.

          LG

          Comment


          • #6
            So- nun hat sich das letzte "Problem" auch lösen lassen!
            http://dbaduck.com/2007/08/20/workin...l-server-2005/

            Danke für die Hilfe.

            Comment

            Working...
            X