pergerakan data besar

Saya ingin memindahkan miliaran baris dari schema1.table1 ke schema2.table2 baru di mana table2 adalah yang refactored dari table1. Karenanya struktur tabel mereka berbeda. table1 dan table2 dipartisi tetapi table2 kosong. Kedua skema ini berada dalam DB oracle yang sama. Apa cara efisien kinerja untuk melakukan migrasi data ini? Apakah Anda ingin melakukan komit hanya di bagian paling akhir atau memilih untuk komit tambahan? misalkan migrasi data gagal setelah menyelesaikan 99% pekerjaan yang membutuhkan waktu beberapa jam. Apakah Anda mundur sekarang? Jika Anda melakukan incremental commit, bagaimana Anda menangani kegagalan?

Sejalan INSERT APPENDdengan NOLOGGINGakan menjadi cara untuk melakukan ini, maka seperti halnya dengan semua operasi NOLOGGING, segera lakukan pencadangan. Tandai indeks yang tidak dapat digunakan terlebih dahulu, nonaktifkan kendala, ubah tabel, lakukan operasi, lalu aktifkan kembali kendala dll.

Append menyebabkan Oracle untuk selalu mengambil ruang bebas di atas tanda air tinggi saat ini, sehingga tidak efisien dalam menggunakan kembali ruang di segmen tersebut, tetapi ia menghindari bermain-main dengan freelist dan overhead UNDO. Jika Anda harus memulai lagi dengan alasan apa pun TRUNCATE, jangan DELETE.

Mengenai komitmen tambahan, itu akan tergantung pada bagaimana data Anda tersegmentasi, dapatkah Anda dengan mudah mengatakan memindahkan nilai satu bulan pada suatu waktu (misalnya, apakah skema pemartisian sama dengan sumber dan target)? Karena ingat bahwa jika Anda perlu memenuhi beberapa predikat, itu jelas akan memperlambat Anda. Tes untuk memastikan operasi tidak akan gagal secara logis (mis. Tipe data yang tidak kompatibel dalam sumber dan target) kemudian mengalokasikan sumber daya yang cukup dan hanya pergi untuk itu dalam satu transaksi. Semoga berhasil!

jika skema partisi adalah sama (data partion a dalam tabel 1 pergi ke partisi a dalam tabel 2 dll) maka saya akan pergi untuk beberapa sesi dan setiap sesi menambahkan data mereka di partisi 'sendiri'. Ini mencegah banyak penguncian dan memiliki kecepatan terbaik. Tergantung pada perangkat kerasnya, Anda dapat mengisi kartu HBA hingga lehernya. Komit untuk setiap partisi - dengan asumsi lebih dari beberapa baris untuk setiap partisi - tidak akan menjadi masalah dan saya pasti akan melakukannya. Dengan asumsi bahwa aplikasi sedang down selama migrasi, fallback sederhana: jangan mengubah aplikasi dan memotong partisi table2 sebelum mencoba lagi, setidaknya untuk bagian-bagian di mana aplikasi mengubah data sebelum menjalankan kedua dapat dilakukan.

saya harap ini membantu