Panduan Migrasi Oracle ke SQL Server dan SQL Server ke Oracle - Pt. 3

Bagian pertama dan kedua dari seri ini membahas perbedaan antara Oracle Database dan Microsoft SQL Server dalam implementasi transaksi mereka, dan perangkap konversi yang dihasilkan, serta beberapa elemen sintaks yang umum digunakan.

Angsuran terakhir ini akan mencakup gagasan tentang konsistensi membaca Oracle dan bagaimana mengubah arsitektur, berdasarkan gagasan ini, ke dalam versi Microsoft SQL Server. Ini juga akan membahas penggunaan sinonim (dan bagaimana TIDAK menggunakannya) dan peran proses kontrol perubahan dalam mengelola lingkungan database Anda.

Oracle Membaca Konsistensi dan Setara di SQL Server

Konsistensi membaca Oracle adalah jaminan bahwa semua data yang dikembalikan oleh satu pernyataan SQL berasal dari titik waktu tunggal yang sama.

Ini berarti bahwa jika Anda mengeluarkan pernyataan SELECT pada 12:01:02.345 dan dijalankan selama 5 menit sebelum mengembalikan hasil yang ditetapkan, semua data (dan hanya data) yang telah dikomit dalam database pada 12:01:02.345 akan membuatnya ke dalam set pengembalian Anda. Set pengembalian Anda tidak akan memiliki data baru yang ditambahkan selama 5 menit yang dibutuhkan database untuk memproses pernyataan Anda, atau pembaruan apa pun, dan tidak ada penghapusan yang akan terlihat.

Arsitektur Oracle mencapai konsistensi baca dengan memberi stempel waktu secara internal setiap perubahan pada data dan membangun kumpulan hasil dari dua sumber: file data permanen dan segmen undo (atau "segmen rollback," seperti yang dikenal hingga versi 10g).

Untuk mendukungnya, informasi undo harus dipertahankan. Jika ditimpa, itu menghasilkan kesalahan ORA-01555: snapshot too old .

Mengesampingkan undo segment management—dan cara menavigasi ORA-01555: snapshot too old error—mari kita lihat implikasi konsistensi baca pada implementasi praktis apa pun di Oracle. Juga, bagaimana itu harus dicerminkan di SQL Server, yang—seperti halnya dengan implementasi RDBMS lainnya, dengan pengecualian PostgreSQL yang mungkin dan memenuhi syarat—tidak mendukungnya?

Kuncinya adalah Oracle membaca dan menulis tidak saling memblokir. Ini juga berarti bahwa kumpulan pengembalian kueri yang berjalan lama mungkin tidak memiliki data terbaru.

Membaca dan menulis tanpa pemblokiran adalah keunggulan yang dimiliki Oracle, dan ini memengaruhi pelingkupan transaksi.

Tetapi konsistensi membaca juga berarti Anda tidak memiliki status data terbaru. Ketika dalam beberapa skenario itu sangat bagus (seperti membuat laporan untuk waktu tertentu), itu bisa membuat masalah signifikan di skenario lain.

Tidak memiliki data terbaru—bahkan “kotor”, atau tidak terikat—dapat menjadi penting: Skenario klasiknya adalah sistem reservasi kamar hotel.

Pertimbangkan kasus penggunaan berikut: Anda memiliki dua agen layanan pelanggan yang secara bersamaan menerima pesanan reservasi kamar. Bagaimana Anda bisa memastikan bahwa kamar tidak menjadi overbooked?

Di SQL Server, Anda dapat memulai transaksi eksplisit dan SELECT catatan dari daftar (yang dapat berupa tabel atau tampilan) ruang yang tersedia. Selama transaksi ini tidak ditutup (baik dengan COMMIT atau ROLLBACK ), tidak ada yang bisa mendapatkan catatan kamar yang sama dengan yang Anda pilih. Ini mencegah pemesanan ganda tetapi juga membuat setiap agen lain saling menunggu untuk menyelesaikan permintaan reservasi satu per satu, secara berurutan.

Di Oracle, Anda dapat mencapai hasil yang sama dengan mengeluarkan pernyataan SELECT ... FOR UPDATE terhadap catatan yang cocok dengan kriteria pencarian Anda.

Catatan: Ada solusi yang lebih baik, seperti menyetel bendera sementara yang menandai ruangan "sedang dipertimbangkan" alih-alih mengunci akses secara membabi buta. Tapi itu adalah solusi arsitektur, bukan pilihan bahasa.

Kesimpulan : Konsistensi membaca Oracle bukanlah “semua baik” atau “semua buruk” tetapi merupakan properti penting dari platform yang perlu dipahami dengan baik dan sangat penting untuk migrasi kode lintas platform.

Sinonim Publik (dan Pribadi) di Oracle dan Microsoft SQL Server

"Sinonim publik itu jahat." Ini bukan penemuan pribadi saya, tetapi saya telah menerimanya sebagai Injil sampai hari, minggu, dan tahun saya diselamatkan oleh sinonim publik.

Di banyak lingkungan basis data—saya akan mengatakan semua lingkungan Oracle yang pernah saya tangani, tetapi tidak ada yang saya rancang—menggunakan CREATE PUBLIC SYNONYM untuk setiap objek adalah rutinitas karena “kami selalu melakukannya dengan cara itu.”

Dalam lingkungan ini, sinonim publik hanya memiliki satu fungsi: untuk memungkinkan referensi ke suatu objek tanpa menentukan pemiliknya. Dan ini adalah salah satu alasan yang dipikirkan dengan buruk untuk membuat sinonim publik.

Namun, sinonim publik Oracle bisa sangat berguna dan memberikan manfaat produktivitas tim yang jauh lebih besar daripada semua kelemahannya, jika diterapkan dan dikelola dengan benar dan dengan alasan. Ya, saya mengatakan "produktivitas tim." Tapi bagaimana caranya? Untuk ini, kita perlu memahami cara kerja resolusi nama di Oracle.

Saat parser Oracle menemukan nama (kata kunci yang tidak dicadangkan), parser mencoba mencocokkannya dengan objek database yang ada dalam urutan berikut:

Catatan: Kesalahan yang muncul adalah ORA-00942: table or view does not exist untuk pernyataan DML, atau PLS-00201: identifier 'my_object' must be declared untuk prosedur tersimpan atau panggilan fungsi.

Dalam urutan resolusi nama ini, mudah untuk melihat bahwa ketika pengembang bekerja dalam skema mereka sendiri, objek lokal apa pun dengan nama yang sama sebagai sinonim publik akan menyembunyikan sinonim publik ini. (Catatan: Oracle 18c mengimplementasikan tipe skema "login-only", dan diskusi ini tidak berlaku untuk itu.)

Sinonim Publik untuk Tim Penskalaan: Kontrol Perubahan Oracle

Sekarang mari kita lihat sebuah tim hipotetis dari 100 pengembang yang bekerja pada database yang sama (yang merupakan sesuatu yang saya alami). Selanjutnya, mari kita asumsikan mereka semua bekerja secara lokal di workstation pribadi mereka dan melakukan pembangunan non-database secara independen, semua terkait dengan lingkungan pengembangan database yang sama. Resolusi penggabungan kode dalam kode non-basis data (baik itu C#, Java, C++, Python, atau apa pun) akan dilakukan pada waktu check-in perubahan-kontrol dan akan berlaku dengan pembuatan kode berikutnya. Tetapi tabel database, kode, dan data perlu diubah bolak-balik beberapa kali selama pengembangan yang sedang berlangsung. Setiap pengembang melakukan ini secara independen, dan itu segera berlaku.

Untuk ini, semua objek database dibuat dalam skema aplikasi umum. Ini adalah skema yang dirujuk oleh aplikasi. Setiap pengembang:

• Terhubung ke database dengan akun/skema pengguna pribadi mereka
• Selalu dimulai dengan skema pribadi yang kosong
• Referensi skema umum hanya melalui resolusi nama ke sinonim publik, seperti dijelaskan di atas

Saat pengembang perlu membuat perubahan apa pun ke database—membuat atau mengubah tabel, mengubah kode prosedur, atau bahkan memodifikasi kumpulan data untuk mendukung beberapa skenario pengujian—mereka membuat salinan objek dalam skema pribadi mereka. Mereka melakukan ini dengan mendapatkan kode DDL menggunakan perintah DESCRIBE dan menjalankannya secara lokal.

Mulai saat ini, kode pengembang ini akan melihat versi lokal dari objek dan data, yang tidak akan terlihat (atau berdampak pada) orang lain. Setelah pengembangan selesai, kode database yang dimodifikasi diperiksa ke dalam kontrol sumber, dan konflik diselesaikan. Kemudian, kode terakhir (dan data, jika diperlukan) diimplementasikan dalam skema umum.

Setelah ini, seluruh tim pengembangan dapat melihat database yang sama lagi. Pengembang yang baru saja mengirimkan kode menghapus semua objek dari skema pribadinya dan siap untuk tugas baru.

Kemampuan untuk memfasilitasi pekerjaan paralel independen untuk banyak pengembang ini adalah manfaat utama dari sinonim publik—penting yang sulit untuk dilebih-lebihkan. Namun, dalam praktiknya, saya terus melihat tim membuat sinonim publik dalam implementasi Oracle "hanya karena kami selalu melakukannya." Sebaliknya, dalam tim yang menggunakan SQL Server, saya tidak melihat pembuatan sinonim publik ditetapkan sebagai praktik umum. Fungsionalitas ada tetapi tidak sering digunakan.

Di SQL Server, skema default saat ini untuk pengguna ditentukan dalam konfigurasi pengguna dan dapat diubah kapan saja jika Anda memiliki hak "mengubah pengguna". Metodologi yang sama persis seperti yang dijelaskan di atas untuk Oracle dapat diimplementasikan. Namun, jika metode ini tidak digunakan, sinonim publik tidak boleh disalin.

Karena Microsoft SQL Server tidak mengaitkan akun pengguna baru dengan skemanya sendiri secara default (seperti halnya Oracle), asosiasi tersebut harus menjadi bagian dari skrip "buat pengguna" standar Anda.

Di bawah ini adalah contoh skrip yang membuat skema pengguna khusus dan menetapkannya ke pengguna.

Pertama, buat skema untuk pengguna baru yang perlu di-onboard ke database bernama DevelopmentDatabase (setiap skema harus dibuat dalam kumpulannya sendiri):

 use DevelopmentDatabase; GO CREATE SCHEMA Dev1; GO CREATE SCHEMA Dev2; GO

Kedua, buat pengguna pertama dengan skema default yang ditetapkan:

 CREATE LOGIN DevLogin123 WITH PASSWORD = 'first_pass123'; CREATE USER Dev1 FOR LOGIN DevLogin123 WITH DEFAULT_SCHEMA = Dev1; GO

Pada titik ini, skema default untuk pengguna Dev1 adalah Dev1 .

Selanjutnya, buat pengguna lain tanpa skema default:

 CREATE LOGIN DevLogin321 WITH PASSWORD = 'second_pass321'; CREATE USER Dev2 FOR LOGIN DevLogin321; GO

Skema default untuk pengguna Dev2 adalah dbo .

Sekarang ubah pengguna Dev2 untuk mengubah skema default ke Dev2 :

 ALTER USER Dev2 WITH DEFAULT_SCHEMA = Dev2; GO

Sekarang skema default untuk pengguna Dev2 adalah Dev2 .

Skrip ini menunjukkan dua cara untuk menetapkan dan mengubah skema default untuk pengguna di database Microsoft SQL Server. Karena SQL Server mendukung beberapa metode otentikasi pengguna (yang paling umum adalah otentikasi Windows) dan orientasi pengguna dapat ditangani oleh administrator sistem daripada oleh DBA, metode ALTER USER untuk menetapkan/mengubah skema default akan lebih bermanfaat.

Catatan: Saya membuat nama skema sama dengan nama pengguna. Tidak harus seperti ini di SQL Server, tetapi ini adalah preferensi saya karena (1) cocok dengan cara melakukannya di Oracle dan (2) menyederhanakan manajemen pengguna (mengatasi keberatan terbesar pada bagian DBA untuk melakukannya dengan benar di tempat pertama)—Anda tahu nama pengguna, dan Anda secara otomatis mengetahui skema default pengguna.

Kesimpulan : Sinonim publik adalah alat penting untuk membangun lingkungan pengembangan multi-pengguna yang stabil dan terlindungi dengan baik. Sayangnya, dalam pengamatan saya di industri, ini lebih sering digunakan untuk alasan yang salah—membuat tim menderita kebingungan dan kerugian lain dari sinonim publik tanpa menyadari manfaatnya. Mengubah praktik ini untuk mendapatkan manfaat nyata dari sinonim publik dapat membawa manfaat nyata bagi alur kerja pengembangan tim.

Manajemen Akses Basis Data dan Proses Manajemen Perubahan

Seperti yang baru saja kita bicarakan tentang dukungan untuk pengembangan paralel oleh tim besar, ada baiknya membahas satu topik terpisah dan sering disalahpahami: proses kontrol perubahan.

Manajemen perubahan sering kali menjadi semacam birokrasi yang dikendalikan oleh pemimpin tim dan DBA, yang dibenci oleh pengembang pemberontak yang ingin memberikan segalanya jika bukan "kemarin" lalu "sekarang".

Sebagai DBA, saya selalu menempatkan penghalang pelindung di jalan ke database "saya". Dan saya punya alasan yang sangat bagus untuk ini: Database adalah sumber daya bersama.

Menciak

Dalam konteks kontrol sumber, manajemen perubahan diterima secara umum karena memungkinkan tim untuk kembali dari kode baru tetapi rusak ke kode lama tetapi berfungsi. Namun dalam konteks basis data, manajemen perubahan bisa tampak seperti serangkaian hambatan dan batasan yang tidak masuk akal yang ditempatkan oleh DBA: Ini adalah kegilaan murni yang memperlambat pengembangan secara tidak perlu!

Mari kita kesampingkan kata-kata kasar pengembang ini: Saya seorang DBA dan saya tidak akan melempar batu pada diri saya sendiri! Sebagai DBA, saya selalu menempatkan penghalang pelindung di jalan ke database "saya". Dan saya punya alasan yang sangat bagus untuk ini: Database adalah sumber daya bersama.

Setiap tim pengembangan—dan masing-masing pengembangnya—memiliki tujuan yang ditentukan secara spesifik dan hasil yang sangat spesifik. Satu-satunya tujuan yang ada di meja DBA setiap hari adalah stabilitas database sebagai sumber daya bersama. DBA memiliki peran unik dalam sebuah organisasi untuk mengawasi semua upaya pengembangan di semua tim dan untuk mengontrol database yang diakses oleh semua pengembang. DBA-lah yang memastikan bahwa semua proyek dan semua proses berjalan tanpa mengganggu satu sama lain dan masing-masing memiliki sumber daya yang dibutuhkan untuk berfungsi.

Masalahnya adalah ketika kedua tim pengembangan dan DBA duduk terkunci di menara gading masing-masing.

Pengembang tidak tahu, tidak memiliki akses, dan bahkan tidak peduli apa yang terjadi pada database selama itu berjalan dengan baik untuk mereka. (Ini bukan hasil kerja mereka, juga tidak akan memengaruhi evaluasi kinerja mereka.)

Tim DBA menjaga database tetap dekat, melindunginya dari pengembang yang “tidak tahu apa-apa” tentangnya, karena tujuan tim mereka adalah stabilitas database. Dan cara terbaik untuk memastikan stabilitas adalah dengan mencegah perubahan yang merusak—sering kali menghasilkan sikap melindungi database dari perubahan apa pun sebanyak mungkin.

Sikap yang saling bertentangan ini terhadap database dapat, seperti yang saya lihat, menyebabkan permusuhan antara tim pengembangan dan DBA dan menghasilkan lingkungan yang tidak dapat dijalankan. Tetapi DBA dan tim pengembangan harus bekerja sama untuk mencapai tujuan bersama: memberikan solusi bisnis, yang menyatukan mereka sejak awal.

Setelah berada di kedua sisi pembagian pengembang-DBA, saya tahu bahwa masalahnya mudah dipecahkan ketika DBA lebih memahami tugas umum dan tujuan tim pengembangan. Di pihak mereka, pengembang perlu melihat database bukan sebagai konsep abstrak tetapi sebagai sumber daya bersama—dan di sana, DBA harus berperan sebagai pendidik.

Kesalahan paling umum yang dilakukan DBA non-pengembang adalah membatasi akses pengembang ke kamus data dan alat pengoptimalan kode. Akses ke tampilan katalog Oracle DBA_ , tampilan V$ dinamis, dan tabel SYS tampaknya bagi banyak DBA sebagai "hak istimewa DBA" padahal, pada kenyataannya, ini adalah alat pengembangan yang penting.

Hal yang sama berlaku untuk SQL Server, dengan satu komplikasi: Akses ke beberapa tampilan sistem tidak dapat diberikan secara langsung, namun itu hanya bagian dari peran database SYSADMIN , dan peran ini tidak boleh diberikan di luar tim DBA. Ini dapat diselesaikan (dan harus diselesaikan dalam kasus migrasi proyek dari Oracle ke SQL Server) dengan membuat tampilan dan prosedur tersimpan yang dijalankan di bawah hak SYSADMIN tetapi dapat diakses oleh pengguna non-DBA. Ini adalah tugas pengembangan yang harus dilakukan DBA saat lingkungan pengembangan SQL Server baru dikonfigurasi.

Perlindungan data adalah salah satu tanggung jawab utama DBA. Meskipun demikian, cukup umum bagi tim pengembangan untuk memiliki akses penuh ke data produksi yang tidak difilter untuk memungkinkan pemecahan masalah tiket terkait data. Ini adalah pengembang yang sama yang memiliki akses terbatas ke struktur data—struktur yang telah dibuat oleh mereka atau untuk mereka sejak awal.

Ketika hubungan kerja yang tepat antara tim pengembangan dan DBA terbentuk, pembuatan proses kontrol perubahan yang baik menjadi intuitif. Spesifik dan tantangan manajemen perubahan sisi database adalah kekakuan dan fluiditas database pada saat yang sama - strukturnya kaku, datanya cair.

Sering terjadi bahwa manajemen perubahan pada modifikasi struktur—yaitu, pada bahasa definisi data, atau DDL—ditetapkan dengan baik sementara perubahan data memiliki sedikit atau tidak ada sama sekali dalam cara manajemen perubahan. Pembenarannya sederhana - data berubah setiap saat.

Tetapi jika kita melihat ini lebih dekat, kita akan melihat bahwa dalam sistem apapun, semua data termasuk dalam salah satu dari dua kategori: data aplikasi dan data pengguna.

Data aplikasi adalah kamus data yang mendefinisikan perilaku aplikasi dan sama pentingnya dengan prosesnya seperti kode aplikasi apa pun. Perubahan pada data ini harus berada di bawah proses kontrol perubahan yang ketat, sama seperti perubahan aplikasi lainnya. Untuk menciptakan transparansi dalam proses kontrol perubahan untuk perubahan data aplikasi, data aplikasi dan data pengguna harus dipisahkan secara eksplisit.

Di Oracle, itu harus dilakukan dengan menempatkan aplikasi dan data pengguna masing-masing dalam skemanya sendiri. Di Microsoft SQL Server, itu harus dilakukan dengan menempatkan masing-masing ke dalam skema terpisah atau – jauh lebih baik – ke dalam database terpisah. Membuat pilihan ini harus menjadi bagian dari perencanaan migrasi: Oracle memiliki resolusi nama dua tingkat (skema/pemilik – nama objek) sedangkan SQL Server memiliki resolusi nama tiga tingkat (basis data – skema/pemilik – nama objek).

Pemisahan yang benar antara aplikasi dan data pengguna memungkinkan tim DBA untuk mengatasi masalah terpenting kedua: keamanan data pengguna. Karena data pengguna berada secara terpisah, maka akan sangat mudah untuk menerapkan prosedur pemecah kaca untuk akses data pengguna berdasarkan kebutuhan.

Kesimpulan : Proses kontrol perubahan sangat penting dalam proyek apa pun. Dalam rekayasa perangkat lunak, manajemen perubahan di sisi database sering diabaikan karena data dianggap “terlalu cair”. Tetapi justru karena data bersifat “fluid” dan “persisten” pada saat yang sama, proses kontrol perubahan yang dirancang dengan baik harus menjadi landasan arsitektur lingkungan basis data yang tepat.

Tentang Penggunaan Alat Migrasi Kode

Alat pihak pertama standar, Oracle Migration Workbench dan SQL Server Migration Assistant, dapat membantu dalam migrasi kode. Namun yang perlu diperhatikan adalah aturan 80/20: Ketika kode akan dimigrasikan 80% dengan benar, menyelesaikan 20% sisanya akan membutuhkan 80% upaya migrasi Anda.

Risiko terbesar dalam penggunaan alat migrasi sejauh ini adalah persepsi “peluru perak”. Seseorang mungkin tergoda untuk berpikir, "Ini akan berhasil, dan saya hanya perlu membersihkan dan merapikan sedikit." Saya mengamati sebuah proyek yang gagal karena sikap seperti itu dari tim konversi dan kepemimpinan teknisnya.

Di sisi lain, saya membutuhkan waktu empat hari kerja untuk menyelesaikan konversi dasar sistem Microsoft SQL Server 2008 ukuran menengah (sekitar 200 objek) menggunakan fungsionalitas penggantian massal Notepad++ sebagai alat pengeditan utama.

Tak satu pun dari elemen migrasi penting yang telah saya bahas sejauh ini dapat diselesaikan dengan alat migrasi.

Tentu, gunakan alat bantuan migrasi, tetapi ingat bahwa ini hanya menyediakan bantuan pengeditan. Teks keluaran yang dihasilkan perlu ditinjau, dimodifikasi, dan—dalam beberapa kasus—menulis ulang agar menjadi kode yang layak produksi.

Pengembangan alat kecerdasan buatan dapat mengatasi kekurangan alat migrasi ini di masa depan, tetapi saya berharap bahwa perbedaan antara basis data akan kabur sebelum itu dan proses migrasi apa pun itu sendiri tidak akan diperlukan. Jadi, selama jenis proyek ini dibutuhkan, kita harus melakukannya dengan cara lama, menggunakan kecerdasan manusia kuno.

Kesimpulan : Menggunakan alat bantuan migrasi sangat membantu tetapi ini bukan "peluru perak", dan proyek konversi apa pun masih memerlukan tinjauan terperinci dari poin-poin di atas.

Migrasi Oracle/SQL Server: Selalu Perhatikan Lebih Dekat

Oracle dan Microsoft SQL Server adalah dua platform RDBMS yang paling berkembang biak di lingkungan perusahaan. Keduanya memiliki kepatuhan dasar dengan standar ANSI SQL, dan segmen kecil kode dapat dipindahkan dengan sedikit modifikasi, atau bahkan apa adanya.

Kesamaan ini menciptakan kesan yang menipu bahwa migrasi di kedua platform adalah tugas yang sederhana dan mudah dan bahwa aplikasi yang sama dapat dengan mudah diadopsi dari menggunakan satu ujung belakang RDBMS ke ujung lainnya.

Dalam praktiknya, migrasi platform semacam itu jauh dari sepele dan harus memperhitungkan elemen halus dari cara kerja setiap platform dan, di atas segalanya, cara mereka menerapkan dukungan untuk elemen paling penting dari manajemen data: transaksi.

Sementara saya membahas dua platform RDBMS yang merupakan inti dari keahlian saya, peringatan yang sama—“tampak sama tidak berarti itu berfungsi sama”—harus diterapkan untuk memindahkan kode di antara sistem manajemen database yang sesuai dengan SQL lainnya. Dan dalam semua kasus, titik perhatian pertama harus pada bagaimana penerapan manajemen transaksi berbeda antara platform sumber dan target.