grande spostamento dei dati

Vorrei spostare miliardi di righe da schema1.table1 a nuovo schema2.table2 dove table2 è refactored da table1. Quindi la loro struttura del tavolo è diversa. sia table1 che table2 sono partizionati ma table2 è vuoto. Entrambi questi schemi sono nello stesso DB di Oracle. Qual è il modo efficiente per eseguire questa migrazione dei dati? Desideri eseguire il commit solo alla fine o optare per il commit incrementale? ad esempio, supponiamo che la migrazione dei dati fallisca dopo aver completato il 99% del lavoro che ha richiesto alcune ore. Esegui il rollback ora? Se esegui il commit incrementale, come gestisci l'errore?

Parallelamente INSERT APPENDcon NOLOGGINGsarebbe il modo per fare questo, poi come con tutte le operazioni NOLOGGING, eseguire un backup immediatamente sul completamento. Contrassegnare prima gli indici inutilizzabili, disabilitare i vincoli, modificare la tabella, eseguire l'operazione, quindi riattivare i vincoli ecc.

Append fa sì che Oracle afferri sempre lo spazio libero sopra l'attuale limite massimo, quindi non è efficiente nel riutilizzare lo spazio nel segmento, ma evita di armeggiare con l'elenco libero e l'overhead UNDO. Se devi ricominciare per qualsiasi motivo, TRUNCATEnon farlo DELETE.

Per quanto riguarda il commit incrementale, dipenderà da come sono segmentati i tuoi dati, puoi dire con facilità lo spostamento di un mese alla volta (ad esempio, lo schema di partizionamento è lo stesso nell'origine e nella destinazione)? Perché ricorda che se hai bisogno di soddisfare un predicato, questo ovviamente ti rallenterà. Prova per assicurarti che l'operazione non fallisca logicamente (ad es. Tipi di dati incompatibili nell'origine e nella destinazione), quindi alloca risorse sufficienti e procedi in un'unica transazione. In bocca al lupo!

se lo schema di partizione è lo stesso (i dati della partizione a nella tabella 1 vanno alla partizione a nella tabella 2 ecc.), andrei per più sessioni e ogni sessione aggiungerebbe i loro dati nella loro "propria" partizione. Ciò impedisce molti blocchi e ha la migliore velocità. A seconda dell'hardware è possibile riempire le schede HBA fino al loro collo. Un commit per ogni partizione - presupponendo più di poche righe per ogni partizione - non sarà un problema e lo farei sicuramente. Supponendo che l'applicazione non sia attiva durante la migrazione, il fallback è semplice: non modificare l'app e troncare le partizioni di table2 prima di riprovare, almeno per quelle parti in cui l'app ha modificato i dati prima che potesse verificarsi una seconda esecuzione.

spero che questo possa essere d'aiuto