Announcement

Collapse
No announcement yet.

BLOBs mit einem DB LINK übertragen

Collapse
X
Collapse
  • Page of 1
  • Filter
  • Time
  • Show
Clear All
new posts
Previous template Next
  • #1

    BLOBs mit einem DB LINK übertragen

    Hallo zusammen,

    ich muss große Datenmengen (bspw. eine Tabelle mit 300gb) per DB-LINK übertragen.

    Bei LOB (Secure Files) Spalten bricht dabei die Performance ein.
    Als Erschwernis kommt hinzu, dass die Daten im laufenden Betrieb hinzugefügt werden.
    Also per INSERT ohne APPEND (weil die Tabelle sonst gelockt ist für DML), wobei ein Staging möglich wäre.

    Habt ihr eine Idee, wie man LOB Übertragungen beschleunigen kann?

    Für alle Anregungen und Tipps bin ich dankbar

    Gruß
    Tags: None
  • #2
    LOBs und DB Links sind generell keine gute Idee.
    Ich würde es so machen, dass zuerst die Tabelle per expdb/impdb physikalisch übertragen wird, und anschließend die zwischenzeitlich aufgelaufenen Änderungen per DB Link kopiert werden.

    Soll das eine dauerhafte oder einmalige Migration sein?
    Zitat Tom Kyte:
    I have a simple philosophy when it comes to the Oracle Database: you can treat it as a black box and just stick data into it, or you can understand how it works and exploit it as a powerful computing environment.

    Comment

    • #3
      Sorry muss noch etwas nachtragen.
      Die Quellumgebung wird abgeschaltet nach der einmaligen Migration.
      Für die Zielumgebung haben wir kein Wartungsfenster.

      Danke für deinen Vorschlag dimitri.
      Wir haben uns eigentlich gegen EXPDB/IMPDB entschieden.
      Die Migration muss für einige Quelldatenbanken durchgeführt werden und Dumps erhöhen dabei den Aufwand.
      Außerdem denken wir, dass EXPDP + IMPDP + Datenübernahme mehr Zeit kostet als die Datenübernahme via DB-LINK.
      Zusätzlich bräuchten wir dann einen Staging Bereich um die Übernahme steuern zu können.
      Zuletzt editiert von FlexGer; 23.05.2017, 10:51.

      Comment

      • #4
        Originally posted by FlexGer View Post
        ich muss große Datenmengen (bspw. eine Tabelle mit 300gb) per DB-LINK übertragen.

        Bei LOB (Secure Files) Spalten bricht dabei die Performance ein.
        Als Erschwernis kommt hinzu, dass die Daten im laufenden Betrieb hinzugefügt werden.
        Also per INSERT ohne APPEND (weil die Tabelle sonst gelockt ist für DML), wobei ein Staging möglich wäre.
        Was bedeutet denn "Performance bricht ein"?
        Statt 100 Sätze pro sekunde nur noch 20?
        oder
        Statt 10MB pro Sekunde nur noch 2?

        Wäre ja ein ziemlicher Unterschied.

        Und was bedeutet eine Tabelle mit 300Gb
        Sind die 300gb das Volumen der Tabelle?
        Wieviel davon musst Du übertragen?
        Ist die Tabelle der Inhalt eines BLOB?
        Wie groß ist ein zu übertragender DS und wie groß das BLOB?
        Gruß, defo

        Comment

        • #5
          Originally posted by FlexGer View Post
          Außerdem denken wir, dass EXPDP + IMPDP + Datenübernahme mehr Zeit kostet als die Datenübernahme via DB-LINK.
          Zusätzlich bräuchten wir dann einen Staging Bereich um die Übernahme steuern zu können.
          Ist natürlich eure Entscheidung, aber wenn bei 85% die Übertragung wg. eines Netzwerkfehler abbricht, dann relativiert sich der zusätzliche Aufwand recht schnell wieder
          Wenn per DB Link, dann würde ich expdb mit dem NETWORK_LINK verwenden, denn dann kann man den Job zumindest wieder aufsetzen (Test!!).
          Zitat Tom Kyte:
          I have a simple philosophy when it comes to the Oracle Database: you can treat it as a black box and just stick data into it, or you can understand how it works and exploit it as a powerful computing environment.

          Comment

          • #6
            Originally posted by FlexGer View Post
            Für die Zielumgebung haben wir kein Wartungsfenster.

            Danke für deinen Vorschlag dimitri.
            Wir haben uns eigentlich gegen EXPDB/IMPDB entschieden.
            Die Migration muss für einige Quelldatenbanken durchgeführt werden und Dumps erhöhen dabei den Aufwand.
            Außerdem denken wir, dass EXPDP + IMPDP + Datenübernahme mehr Zeit kostet als die Datenübernahme via DB-LINK.
            Zusätzlich bräuchten wir dann einen Staging Bereich um die Übernahme steuern zu können.
            Was migriert Ihr denn da? Ein Schema in eine neue Instanz? Gleiche RDBMS Version?
            Ist das Ziel vorbereitet? Tablespace(s), BLOB Tablespace(s) bereits angelegt?
            Wie sehen die DDL der problematischen Tables aus? Externe BLOB Definition oder intern?
            Gruß, defo

            Comment

            • #7
              Wird Deine Zieldatenbank neu aufgebaut oder gibt es die schon ? Kommen die Daten der Tabelle mit dem Blob in eine eigene Tabelle oder müssen sie in eine mit weiteren Daten eingebaut werden ?
              Darauf kommt es bei der Übertragung ja auch an. Wenn die Datenbank mit diversen Inhalten schon besteht, aber die Tabelle in einen neuen tablespace kann, wäre auch der Transport über transportable Tablespace, am besten mit rman , eine Idee.

              Comment

              • #8
                Beim Einsatz von TTS muss der Quelltablespace für die Dauer der Kopiervorgangs der Metadaten auf Readonly gesetzt werden.
                Das könnte problematisch sein, da es sich ja anscheinend um ein OLTP System handelt.

                Falls das kein Problem ist, wäre nur noch die Enterprise Edition von nöten und etwas Testaufwand
                Zitat Tom Kyte:
                I have a simple philosophy when it comes to the Oracle Database: you can treat it as a black box and just stick data into it, or you can understand how it works and exploit it as a powerful computing environment.

                Comment

                • #9
                  Wenn man rman benutzt, muss der Quelltablespace meines Wissens nicht auf Readonly gesetzt werden. Das ist der Vorteil gegenüber dem "normalen" TTS. Ausprobiert habe ich es aber selbst noch nicht.
                  Kommt jetzt halt drauf an, was er so hat und braucht.

                  Comment

                  • #10
                    Vielen Dank für die Rückmeldungen und Vorschläge

                    Die Dauer der Übertragung liegt tatsächlich in der Datengröße der LOB Felder.
                    Bei TTS haben wir einige Probleme bei anderen Kunden gehabt, ORA-00721,29349,01537...
                    Für dieses Projekt haben wir es auch ausgeschlossen. Habt ihr denn schon erfolgreich Datenübernahmen (bestehende Tabellen füllen aus einem anderen Datenpool) mit TTS durchführen können?
                    Bei DB Links gibt es aktuell (11.2.0.3) auch Probleme, allerdings nur wenn ein Error bei der Transaktion auftritt.
                    Die Transaktion bleibt dann einfach hängen, für immer. Sieht so aus, als wenn das übertragende System keine Rückmeldung erhalten hat.
                    Habt ihr dafür einen Workaround?

                    Comment

                    • #11
                      Lass dir doch nicht alles aus der Nase ziehen.
                      Ich habe noch nie mit TTS gearbeitet.

                      Nochmal die Frage(n):
                      Wie sehen typische DDL aus?
                      Gibt es separate BLobspaces?
                      Habt Ihr Tablespaces vorbereitet, allokiert? Oder läuft das nebenher, während die Daten über den Link reingeblasen werden.
                      (Wenn ich es richtig verstanden habe, ja wohl auf eine Server der bereits in Production ist, also auch andere Sachen zu tun hat?)
                      Oder nutzt Ihr Raw files? Oder oder oder..
                      Gruß, defo

                      Comment

                      • #12
                        TTS funktioniert für die Metadaten auch prinzipiell über expdb/impdp nur dass eben auch die ganzen sonstigen Tablespacedaten mitgegeben werden. Wenn die Tabelle, in die die Daten sollen schon da ist funktioniert das schon mal nicht. Auch kein Backup/Restore mit SQL-Apply, obwohl man da vielleich tricksen kann.
                        Ich stelle mir das nach der letzen Antwort so vor:
                        DB1-Schema A und DB2-Schema A und DB3-Schema-B und ... ergeben zusammen DBZiel-Alle Schemata.
                        Jede DBx läuft solange, bis sie komplett in der ZielDB ist.
                        Liege ich da richtig ? Dann wäre auch noch wichtig, was für eine Oracle-Version und Edition Du hast.

                        Gruß
                        Uschi

                        Comment

                        Previous template Next
                        Working...
                        X