Migrasi database: Konsep dan prinsip (Bagian 2)

Last reviewed 2024-03-11 UTC

Dokumen ini membahas penyiapan dan eksekusi proses migrasi database, termasuk skenario kegagalan. Dokumen ini adalah bagian 2 dari dua bagian. Bagian 1 memperkenalkan konsep, prinsip, dan terminologi tentang migrasi database periode nonaktif nyaris nol untuk arsitek cloud yang perlu memigrasikan database ke Google Cloud dari infrastruktur lokal atau cloud lainnya yang berbeda.

Penyiapan migrasi database

Bagian ini menjelaskan beberapa fase migrasi database. Pertama, Anda menyiapkan migrasi. Kemudian, setelah menyelesaikan migrasi dan mengalihkan klien ke database target, Anda dapat menghapus database sumber atau, jika perlu, menerapkan rencana penggantian karena masalah pada migrasi setelah peralihan. Penggantian membantu memastikan kelangsungan bisnis.

Selama migrasi, Anda perlu memberikan perhatian khusus pada setiap perubahan skema atau data yang mungkin terjadi. Untuk mengetahui informasi selengkapnya tentang dampak perubahan ini, lihat Perubahan dinamis selama migrasi nanti dalam dokumen ini.

Spesifikasi skema target

Untuk setiap sistem database target, Anda perlu menentukan dan membuat skemanya. Untuk migrasi database yang homogen, Anda dapat membuat spesifikasi ini lebih cepat dengan mengekspor skema database sumber ke database target, sehingga skema database target dibuat.

Bagaimana Anda memberi nama skema Anda adalah hal penting. Salah satu pilihannya adalah mencocokkan nama skema sumber dan target. Namun, meskipun cara ini mempermudah pengalihan klien, pendekatan ini dapat membingungkan pengguna jika alat terhubung ke skema sumber dan database target secara bersamaan—misalnya, untuk membandingkan data. Jika Anda memisahkan nama skema menggunakan file konfigurasi, memberikan skema database target dengan nama yang berbeda dari sumber akan memudahkan untuk membedakan skema.

Dengan migrasi database heterogen, Anda harus membuat setiap skema database target. Proses rekayasa dapat mengambil beberapa iterasi. Sebelum dapat menerapkan migrasi, Anda mungkin perlu mengubah skema lebih lanjut untuk mengakomodasi proses migrasi dan modifikasi data apa pun.

Karena Anda kemungkinan akan membuat database target beberapa kali saat menguji dan menjalankan migrasi, proses pembuatan skema harus dapat diulang (idealnya dilakukan melalui skrip penginstalan). Anda dapat menggunakan sistem pengelolaan kode untuk mengontrol versi skrip, memastikan konsistensi, dan mengakses histori perubahan skrip.

Migrasi kueri dan semantik eksekusi

Pada akhirnya, Anda perlu beralih klien mulai dari mengakses sistem database sumber hingga mengakses sistem database target. Dalam integrasi database homogen, kueri dapat tetap tidak berubah jika skema tidak diubah. Meskipun klien harus diuji pada sistem database target, klien tidak perlu diubah karena adanya kueri.

Untuk migrasi database heterogen secara umum, Anda harus mengubah kueri karena skema antara database sumber dan target berbeda. Perbedaannya mungkin berupa ketidakcocokan jenis data antara database sumber dan target. Selain itu, tidak semua kemampuan bahasa kueri yang tersedia dalam sistem database sumber mungkin tersedia di sistem database target, atau sebaliknya. Dalam kasus yang ekstrem, Anda mungkin perlu mengonversi kueri dari sistem database sumber menjadi beberapa kueri pada sistem target. Dalam skenario terbalik, ketika Anda memiliki lebih banyak kemampuan bahasa kueri yang tersedia di database target daripada di sumber, Anda mungkin perlu menggabungkan beberapa kueri dari database sumber ke dalam satu kueri pada target yang sesuai database.

Semantik kueri juga dapat berbeda. Misalnya, beberapa sistem database mewujudkan update dalam transaksi secara langsung dalam transaksi tersebut. Jadi, saat item data yang sama dibaca, nilai yang diupdate akan diambil. Sistem lain tidak segera menerapkan pembaruan dan menunggu hingga transaksi di-commit. Jika logika pada sistem database sumber bergantung pada penulisan yang terwujud, logika yang sama pada database target dapat menyebabkan data yang salah atau bahkan kegagalan.

Jika harus memigrasikan kueri, Anda harus menguji semua fungsi untuk memastikan bahwa perilaku klien sama sebelum dan sesudah migrasi. Anda juga dapat melakukan pengujian di tingkat data, tetapi pengujian tersebut tidak menggantikan pengujian pada tingkat klien. Klien menjalankan kueri dari sudut pandang logika bisnis dan hanya dapat diuji pada level logika bisnis.

Proses migrasi

Untuk migrasi database heterogen, proses migrasi menentukan cara data yang diekstrak dari sistem database sumber dimodifikasi dan dimasukkan ke dalam database target. Modifikasi data, seperti yang dibahas dalam Perubahan data dalam dokumen ini, ditentukan dan dieksekusi saat item data diekstrak dari database sumber dan ditransfer ke database target.

Dengan migrasi database homogen, saat skema database sumber dan target setara, modifikasi data tidak diperlukan. Data dimasukkan ke dalam database target seperti yang diekstrak dari database sumber.

Bergantung pada sistem migrasi database Anda, beberapa konfigurasi mungkin diperlukan. Misalnya, Anda harus menentukan apakah data yang diubah dan ditransfer harus disimpan secara bergantian dalam sistem migrasi database. Menyimpan data dapat memperlambat proses migrasi keseluruhan, tetapi akan mempercepat pemulihan jika terjadi kegagalan. Anda mungkin diminta untuk menentukan jenis verifikasi. Misalnya, beberapa sistem migrasi database mengkueri sumber dan sistem target untuk menetapkan kesetaraan set data yang dimigrasikan hingga titik kueri. Penanganan error mengharuskan Anda menentukan perilaku pemulihan kegagalan. Sekali lagi, persyaratan ini bergantung pada sistem migrasi database yang digunakan.

Perlu dikatakan, Anda perlu menguji migrasi data secara menyeluruh dan berulang. Idealnya, migrasi Anda diuji untuk memastikan bahwa setiap item data yang diketahui telah dimigrasikan, tidak ada error modifikasi data yang terjadi, performa dan throughput cukup, serta waktu untuk migrasi dapat dicapai.

Proses penggantian

Selama migrasi database, database sumber tetap operasional (kecuali migrasi Anda melibatkan periode nonaktif yang direncanakan). Jika migrasi database gagal, Anda dapat (dalam skenario terburuk) membatalkan migrasi dan mereset database target ke keadaan awal. Setelah mengatasi kegagalan, Anda dapat memulai ulang migrasi database. Kegagalan dan resolusi tidak memengaruhi sistem database sumber operasional.

Jika terjadi kegagalan setelah migrasi database selesai dan klien dialihkan ke database target, kegagalan dan proses penyelesaian dapat berdampak pada klien sehingga mereka tidak dapat beroperasi dengan benar. Dalam kasus terbaik, kegagalan akan diatasi dengan cepat dan periode nonaktif untuk klien akan singkat. Dalam kasus terburuk, kegagalan tidak akan teratasi, atau penyelesaiannya memerlukan waktu lama dan Anda harus mengalihkan klien kembali ke database sumber.

Untuk mengalihkan klien kembali ke database sumber, Anda harus memigrasikan semua perubahan data di database target kembali ke database sumber. Anda dapat menyiapkan dan menjalankan proses ini sebagai migrasi database yang terpisah dan lengkap. Namun, karena klien tidak beroperasi pada database target pada tahap ini, periode nonaktif yang signifikan akan terjadi.

Untuk menghindari periode nonaktif klien dalam skenario ini, Anda harus memulai proses migrasi segera setelah migrasi database asli selesai. Setiap perubahan yang diterapkan ke sistem database target segera diterapkan ke sistem database sumber. Mengikuti pendekatan ini akan memastikan bahwa sistem database target dan sumber tetap sinkron setiap saat.

Menyiapkan penggantian dari database target ke database sumber memerlukan upaya yang signifikan. Sangat penting untuk memutuskan apakah akan menerapkan dan menguji proses penggantian atau memahami konsekuensi jika tidak melakukannya—yaitu, periode nonaktif yang signifikan.

Eksekusi migrasi database

Mengeksekusi migrasi database melibatkan lima fase berbeda yang akan dibahas bagian ini. Fase keenam adalah penggantian, tetapi penggantian merupakan kasus ekstrem dan dianggap sebagai pengecualian untuk eksekusi migrasi database normal.

Proses yang dibahas di bagian ini adalah migrasi database heterogen dengan periode nonaktif nyaris nol. Jika dapat mengalami periode nonaktif yang signifikan, Anda dapat menggabungkan tiga fase pertama (pemuatan awal, migrasi berkelanjutan, dan pengosongan) menjadi satu fase dengan menggunakan pendekatan pencadangan dan pemulihan atau ekspor dan impor.

Migrasi database homogen menghadirkan kasus khusus. Dengan jenis migrasi ini, Anda dapat menggunakan fungsionalitas replikasi sistem pengelolaan database (untuk sistem yang mendukungnya) yang memigrasikan data sementara sistem database sumber tetap beroperasi.

Fase yang dibahas di sini menguraikan pendekatan yang mungkin perlu Anda ubah sesuai dengan persyaratan proses migrasi database Anda.

Fase 1: Pemuatan awal

Titik awalnya adalah memigrasikan semua data yang ditentukan untuk dimigrasikan dari semua database sumber. Pada awal migrasi data, database sumber memiliki status tertentu, dan status tersebut berubah selama migrasi.

Tips untuk memulai migrasi saat perubahan terjadi secara bersamaan adalah mencatat waktu sistem database tepat sebelum item data pertama diekstrak. Dengan stempel waktu ini, Anda dapat memperoleh semua perubahan database dari log transaksi yang dimulai pada waktu tersebut. Selain itu, pemuatan awal harus membaca status database yang konsisten di semua data. Anda mungkin memerlukan kunci durasi singkat pada database untuk mencegah pembacaan set data yang tidak konsisten.

Fase ini terdiri dari hal berikut:

  • Memperhatikan waktu sistem database tepat sebelum migrasi database dimulai.
  • Menjalankan proses migrasi pemuatan awal yang membuat kueri set data (baik lengkap maupun sebagian) dari database sumber yang perlu dimigrasikan dan memigrasikan set data. Dalam model database relasional, proses migrasi pemuatan awal mengeksekusi kueri seperti SELECT * atau kueri dengan pilihan, atau proyeksi, atau keduanya. Proses migrasi melakukan modifikasi data seperti yang ditentukan dalam proses tersebut.

Meskipun proses migrasi pemuatan awal dijalankan, klien biasanya membuat perubahan pada database sumber. Karena Anda mencatat waktu sistem database di awal, Anda dapat memperoleh perubahan tersebut dari log transaksi nanti.

Hasil dari fase pemuatan awal adalah migrasi lengkap set data awal dari sistem database sumber ke sistem database target. Namun, database sumber dan target belum disinkronkan karena klien kemungkinan mengubah database sumber selama migrasi. Fase 2 melibatkan pengambilan dan memigrasikan perubahan tersebut.

Fase 2: Melanjutkan migrasi

Melanjutkan migrasi memiliki dua tujuan. Pertama, operasi ini akan membaca perubahan yang terjadi di database sumber setelah pemuatan awal dimulai. Kedua, TGS akan menangkap dan mentransfer perubahan tersebut ke database target.

Fase ini terdiri dari hal berikut:

  • Memulai proses migrasi berkelanjutan dari waktu sistem database yang dicatat di Fase 1. Migrasi membaca log transaksi dari waktu tersebut dan menerapkan setiap perubahan ke sistem database target.
  • Mengeksekusi modifikasi data apa pun. Proses migrasi akan melakukan langkah ini seperti yang Anda tentukan.

Perubahan yang dicatat dalam log setelah waktu sistem database terkadang ditransfer selama pemuatan awal. Oleh karena itu, perubahan tersebut mungkin dapat diterapkan untuk kedua kalinya selama migrasi melanjutkan. Anda perlu menentukan proses migrasi untuk memastikan perubahan tidak diterapkan dua kali—misalnya, menggunakan ID. Misalnya, item data yang diubah ditransfer selama pemuatan awal, dan penyisipan tersebut dicatat ke dalam log transaksi. Dengan menerapkan ID ke item data, sistem migrasi dapat menentukan dari log transaksi bahwa penyisipan lain tidak diperlukan karena item data sudah ada.

Hasil dari fase migrasi yang berkelanjutan adalah bahwa database target disinkronkan sepenuhnya atau hampir disinkronkan sepenuhnya dengan database sumber. Jika perubahan dalam sistem database sumber tidak dimigrasikan, berarti Anda memiliki database yang hampir disinkronkan.

Bergantung pada cara Anda mengonfigurasi sistem migrasi database, perbedaannya bisa kecil atau besar. Misalnya, untuk meningkatkan efisiensi, tidak setiap perubahan harus segera dimigrasikan. Jika tidak, Anda dapat membuat muatan berat pada sumber jika perubahan pada sumber melonjak. Secara umum, perubahan dikumpulkan dan dimigrasikan dalam batch sebagai operasi massal. Dengan batch yang lebih kecil, perbedaan yang terjadi antara sumber dan target akan lebih sedikit. Namun, sumber Anda dapat menimbulkan muatan yang lebih tinggi jika perubahan sering dilakukan.

Jika ukuran tumpukan dikonfigurasi secara dinamis, sebaiknya sinkronkan batch yang lebih besar di awal tahap migrasi, lalu sinkronkan batch dengan ukuran yang lebih kecil secara bertahap saat database hampir selesai. Pendekatan ini membuat proses pengambilan data menjadi lebih efisien dan nantinya mengurangi perbedaan antara database sumber dan target.

Fase 3: Pengosongan

Untuk bersiap mengalihkan klien dari database sumber ke database target, Anda harus memastikan bahwa database sumber dan database target disinkronkan sepenuhnya. Pengosongan adalah proses migrasi perubahan yang tersisa dari database sumber ke database target.

Fase ini terdiri dari hal berikut:

  • Meminta sistem database sumber. Artinya, tidak ada modifikasi data yang dapat terjadi di database sumber, dan log transaksi tidak menerima entri modifikasi tambahan.
  • Menunggu semua perubahan untuk dimigrasikan ke database target. Proses ini adalah pengosongan perubahan yang sebenarnya.
  • Setelah pengosongan selesai, cadangkan database target agar memiliki titik awal yang ditentukan untuk pencadangan inkremental di masa mendatang.

Hasil dari fase pengosongan adalah sistem database sumber dan sistem database target disinkronkan, dan tidak akan ada modifikasi data.

Untuk memastikan bahwa pengosongan selesai, item data "penyisipan terakhir" dapat ditulis ke dalam database sumber. Setelah item data "sisipkan terakhir" muncul di database target yang sesuai, fase pengosongan akan selesai.

Fase 4: Peralihan

Setelah fase pembuangan selesai, Anda dapat mengalihkan klien dari database sumber ke database target. Kami merekomendasikan praktik terbaik berikut:

  • Sebelum mengaktifkan akses ke database produksi, uji fungsi dasar untuk memastikan bahwa klien beroperasi dan berperilaku sebagaimana mestinya. Jumlah kasus pengujian akan menentukan periode nonaktif sebenarnya untuk database produksi Anda.
  • Cadangkan database target sebelum Anda mengaktifkan akses klien. Praktik terbaik ini memastikan status awal database target dapat dipulihkan.

Pada akhir peralihan, klien beroperasi sepenuhnya dan mulai mengakses database produksi (yang disebut dalam dokumen ini sebagai database target hingga saat ini).

Fase 5: Penghapusan database sumber

Setelah menyelesaikan peralihan ke database produksi, Anda dapat menghapus database sumber. Sebaiknya cadangkan setiap database sumber sehingga Anda memiliki status akhir yang telah ditentukan yang dapat diakses. Peraturan data mungkin juga memerlukan cadangan akhir untuk alasan kepatuhan.

Fase 6: Penggantian

Menerapkan penggantian, terutama untuk klien database yang sangat penting, dapat menjadi perlindungan yang baik terhadap masalah terkait migrasi Anda. Penggantian mirip seperti migrasi, tetapi secara terbalik. Artinya, dengan penggantian, Anda akan menyiapkan migrasi dari database target kembali ke database sumber. Dengan migrasi database yang heterogen, penggantian menjadi lebih kompleks. Oleh karena itu, sebaiknya Anda hanya melakukan peralihan ini setelah memastikan bahwa proses migrasi database dan aplikasi yang terhubung dengan database target telah memenuhi perjanjian tingkat layanan (SLA) Anda.

Setelah menghabiskan database sumber dan mencadangkan semua database, Anda dapat mengaktifkan proses migrasi yang mengidentifikasi perubahan dalam database target dan memigrasikannya ke database sumber sebelum peralihan.

Membangun proses migrasi ini memastikan bahwa setelah klien melakukan perubahan pada database target, database sumber akan disinkronkan dan status data mereka selalu diperbarui. Penggantian mungkin diperlukan beberapa hari atau minggu setelah peralihan. Misalnya, klien mungkin mengakses fungsi untuk pertama kalinya dan diblokir karena fungsi yang rusak yang tidak dapat diperbaiki dengan cepat. Dalam hal ini, klien dapat dialihkan kembali untuk mengakses database sumber. Sebelum klien dialihkan kembali, semua perubahan pada database target harus dimasukkan ke dalam database sumber.

Dalam pendekatan ini, beberapa situasi memerlukan perhatian khusus:

  • Anda harus mendesain skema target agar migrasi terbalik (dari database target ke database sumber) dapat dilakukan. Misalnya, jika proses migrasi awal Anda (dari sumber ke target) memiliki penggabungan atau agregasi, migrasi terbalik tidaklah mudah atau bahkan tidak mungkin dilakukan. Dalam kasus tersebut, data individual juga harus tersedia di database target.
  • Masalah dapat muncul di mana database sumber memiliki log transaksi, tetapi database target tidak menyediakan fitur non-fungsional tersebut. Dalam hal ini, migrasi terbalik (dari target ke sumber) harus mengandalkan kueri diferensial. Penyiapan tersebut harus dirancang dan disiapkan dalam skema database target.
  • Klien yang awalnya beroperasi di database sumber harus selalu tersedia dan beroperasi sehingga dapat diaktifkan dalam penggantian. Setiap perubahan fungsional yang dilakukan pada klien yang mengakses database target juga harus dilakukan pada klien yang mengakses database sumber untuk memastikan kesetaraan fungsional.

Meskipun penggantian adalah upaya terakhir, menerapkan penggantian sangat penting dan harus diperlakukan sebagai migrasi database menyeluruh, yang mencakup pengujian.

Perubahan dinamis selama migrasi

Secara umum, database adalah sistem dinamis karena skema dan nilai data dapat berubah. Skema database dapat berubah berdasarkan faktor seperti persyaratan bisnis, dan nilai data dapat berubah bersamaan dengan, atau tidak bergantung pada, perubahan skema. Perubahan nilai data dapat terjadi secara dinamis kapan saja dengan perubahan yang terkait pada implementasi aplikasi. Bagian berikut membahas beberapa kemungkinan perubahan dan implikasinya terhadap migrasi database.

Perubahan skema

Database dapat dikategorikan ke dalam sistem yang memerlukan skema yang telah ditetapkan atau bebas skema atau tanpa skema. Secara umum, sistem yang memerlukan skema yang telah ditetapkan akan mendukung operasi perubahan skema—misalnya, menambahkan atribut atau kolom dalam sistem relasional.

Dalam sistem ini, Anda mengontrol perubahan melalui proses manajemen perubahan. Proses manajemen perubahan memungkinkan perubahan dengan cara yang terkendali. Setiap operasi yang bergantung pada skema, seperti kueri atau proses migrasi data, akan diubah secara bersamaan untuk memastikan perubahan yang konsisten secara keseluruhan.

Sistem database yang tidak memerlukan skema yang telah ditetapkan dapat diubah kapan saja. Perubahan skema tidak hanya dapat dilakukan oleh pengguna yang diberi otorisasi, dalam beberapa kasus dan dapat dilakukan secara terprogram. Dalam kasus ini, perubahan skema dapat terjadi kapan saja. Operasi yang bergantung pada skema mungkin gagal—misalnya, kueri atau proses migrasi data. Untuk mencegah perubahan skema yang tidak terkontrol dalam sistem database ini, Anda harus menerapkan proses manajemen perubahan sebagai konvensi dan aturan yang diterima, bukan oleh penegakan sistem.

Perubahan data

Secara umum, skema mengontrol kemungkinan nilai data untuk berbagai atribut data. Sistem tanpa skema tidak memiliki batasan pada nilai data.

Dalam kedua kasus tersebut, nilai data dapat muncul yang sebelumnya tidak disimpan. Misalnya, jenis enumerasi sering diimplementasikan sebagai kumpulan string dalam sistem database. Pada tingkat bahasa pemrograman, hal ini dapat diterapkan di klien sebagai jenis enumerasi sebenarnya, tetapi belum tentu demikian. Ada kemungkinan bahwa klien menyimpan apa yang dianggapnya sebagai nilai enumerasi valid yang tidak dianggap valid oleh klien lain. Selain itu, proses migrasi data mungkin mengunci fungsinya dari nilai enumerasi. Jika nilai baru muncul, proses migrasi data mungkin gagal.

Contoh lain ditemukan pada penyimpanan struktur JSON. Umumnya, struktur JSON disimpan dalam string jenis data. Namun, struktur tersebut ditafsirkan sebagai nilai JSON setelah diakses. Jika struktur JSON berubah, sistem database tidak mendeteksinya; proses migrasi data yang menafsirkan string sebagai nilai JSON mungkin akan gagal.

Perubahan proses migrasi

Manajemen perubahan selama migrasi database yang sedang berlangsung bersifat sulit dan kompleks, serta dapat menyebabkan kegagalan migrasi data atau inkonsistensi data. Sebaiknya perubahan yang diperlukan tertunda hingga akhir fase pengosongan, saat sistem database sumber dan target disinkronkan. Pada tahap ini, perubahan akan dibatasi pada database target dan kliennya (kecuali jika penggantian juga diterapkan).

Jika Anda perlu mengubah proses migrasi selama migrasi data, sebaiknya buat perubahan seminimal mungkin dan buat beberapa perubahan kecil, bukan perubahan yang lebih rumit. Selain itu, sebaiknya uji perubahan tersebut terlebih dahulu menggunakan instance pengujian database sumber dan target. Idealnya, Anda memuat sumber pengujian dengan data produksi yang kemudian dimigrasikan ke target pengujian. Dengan pendekatan ini, Anda dapat memverifikasi perubahan yang diusulkan tanpa memengaruhi migrasi produksi yang sedang berlangsung. Setelah menguji dan memverifikasi perubahan, Anda dapat menerapkan perubahan tersebut ke sistem produksi.

Agar perubahan dapat dilakukan selama migrasi data yang sedang berlangsung, Anda harus dapat menghentikan sistem migrasi data dan memulai ulang sistem, mungkin dengan proses migrasi data yang dimodifikasi. Dalam hal ini, Anda tidak harus memulai dari awal dengan fase pemuatan data awal. Jika sistem migrasi data mendukung fitur migrasi pengujian, Anda juga dapat menggunakannya.

Sebaiknya hindari mengubah skema, nilai data, atau proses migrasi data selama migrasi data. Jika harus membuat perubahan, Anda dapat mempertimbangkan untuk memulai ulang migrasi data dari awal untuk memastikan bahwa Anda memiliki status awal yang ditentukan. Dalam situasi apa pun, sebaiknya Anda menguji menggunakan data produksi dan mencadangkan database sebelum menerapkan perubahan, sehingga jika diperlukan, Anda dapat mereset keseluruhan sistem ke status yang konsisten.

Mitigasi kegagalan migrasi

Masalah tidak terduga dapat terjadi selama migrasi database. Berikut ini menyoroti beberapa area yang mungkin memerlukan perencanaan awal:

  • Throughput tidak memadai. Sistem migrasi mungkin tidak memiliki throughput yang memadai, meskipun telah dilakukan pengujian muat. Masalah ini mungkin disebabkan oleh banyak penyebab, seperti peningkatan rasio perubahan database sumber yang tidak terduga atau throttling jaringan. Anda dapat mempersiapkan diri untuk kasus ini dengan menyiapkan resource tambahan untuk peningkatan skala dinamis atau penskalaan dinamis dari semua komponen yang terlibat.
  • Ketidakstabilan database. Database sumber atau database target dapat menunjukkan ketidakstabilan, yang dapat memperlambat proses migrasi data atau mencegah akses sesekali. Proses migrasi data mungkin perlu sering dipulihkan. Dalam hal ini, pengalihan HA atau DR yang disengaja mungkin dapat mengatasi masalah ini. Peralihan akan mengubah lingkungan nonfungsional (mesin dan penyimpanan) dan dapat membantu mengurangi masalah. Dalam hal ini, Anda perlu menguji proses peralihan dan pemulihan migrasi database untuk memastikan bahwa peralihan tidak menyebabkan inkonsistensi data dalam database target.
  • Kehabisan ukuran file log transaksi. Dalam beberapa kasus, log transaksi disimpan dalam file yang memiliki batas atas. Ada kemungkinan bahwa batas atas ini telah tercapai dan migrasi database akan gagal. Penting untuk memahami bagian mana dari sistem database yang dapat dikonfigurasi ulang secara dinamis untuk mengatasi keterbatasan resource yang muncul. Jika aspek tertentu tidak dapat dikonfigurasi secara dinamis, ukuran awal harus ditentukan dengan cermat.

Semakin Anda membuat pengujian awal realistis dan lengkap, semakin besar kemungkinan Anda akan menemukan potensi masalah untuk diatasi.

Langkah selanjutnya