Hai Nama saya Antonina, saya adalah pengembang Oracle dari divisi IT Sportmaster Lab. Saya telah bekerja di sini hanya selama dua tahun, tetapi berkat tim yang ramah, tim yang erat, sistem bimbingan, dan pelatihan perusahaan, massa yang sangat kritis telah terkumpul ketika Anda ingin tidak hanya mengonsumsi pengetahuan, tetapi juga berbagi pengalaman Anda.
Jadi, Redefinisi Berbasis Edisi. Mengapa kita bahkan memiliki kebutuhan untuk mempelajari teknologi ini, apalagi, istilah "ketersediaan tinggi" dan bagaimana Redefinisi Berbasis Edisi membantu kita sebagai pengembang Oracle menghemat waktu?
Apa yang diusulkan sebagai solusi oleh Oracle? Apa yang terjadi di halaman belakang ketika menerapkan teknologi ini, masalah apa yang kami temui ... Secara umum, ada banyak pertanyaan. Saya akan mencoba menjawabnya dalam dua posting pada topik, dan yang pertama sudah di bawah cut.
Setiap tim pengembang, membuat aplikasi mereka sendiri, berusaha membuat algoritma yang paling terjangkau, paling toleran, dan paling andal. Mengapa kita semua berjuang untuk ini? Mungkin bukan karena kami sangat baik dan kami ingin merilis produk yang keren. Lebih tepatnya, bukan hanya karena kita begitu baik. Ini juga penting untuk bisnis. Terlepas dari kenyataan bahwa kita dapat menulis algoritma yang keren, menutupinya dengan unit test, melihat bahwa itu toleran terhadap kesalahan, kita masih (pengembang Oracle) memiliki masalah - kita dihadapkan dengan kebutuhan untuk meningkatkan aplikasi kita. Misalnya, kolega kami dalam sistem loyalitas dipaksa melakukan ini di malam hari.
Jika ini terjadi dengan cepat, pengguna akan melihat gambar: "Maafkan saya!", "Jangan sedih!", "Tunggu, kami memiliki pembaruan dan pekerjaan teknis di sini." Mengapa ini sangat penting untuk bisnis? Tapi itu sangat sederhana - untuk waktu yang lama, bisnis telah meletakkan kerugiannya tidak hanya kerugian beberapa barang nyata, nilai materi, tetapi juga kerugian dari infrastruktur yang rusak. Misalnya, menurut majalah Forbes, kembali 13, satu menit dari pemadaman layanan Amazon kemudian biaya 66 ribu dolar. Artinya, dalam setengah jam orang-orang kehilangan hampir $ 2 juta.
Jelas bahwa untuk usaha menengah dan kecil, dan bukan untuk raksasa seperti Amazon, karakteristik kuantitatif ini akan jauh lebih sedikit, tetapi meskipun demikian, secara relatif, ini tetap merupakan karakteristik evaluasi yang signifikan.
Jadi, kita perlu memastikan ketersediaan aplikasi kita yang tinggi. Apa saja tempat yang berpotensi berbahaya yang dimiliki pengembang Oracle untuk aksesibilitas ini?
Hal pertama yang pertama, perangkat keras kita mungkin gagal. Kami, sebagai pengembang, tidak bertanggung jawab untuk ini. Administrator jaringan harus memastikan bahwa server dan objek struktural operasional. Yang kami tuju adalah peningkatan perangkat lunak. Sekali lagi, pembaruan perangkat lunak terjadwal dapat dibagi menjadi dua kelas. Atau kami mengubah beberapa jenis infrastruktur, misalnya memperbarui sistem operasi tempat server berputar. Entah kami memutuskan untuk pindah ke rilis baru Oracle (alangkah baiknya jika kami berhasil pindah ke sana :)) ... Atau, kelas kedua, ini adalah yang memiliki hubungan maksimum dengan kami - ini memperbarui objek aplikasi yang kami kembangkan bersama Anda.
Sekali lagi, pembaruan ini dapat dibagi menjadi dua kelas lagi.
Atau kita mengubah beberapa karakteristik fisik dari objek ini (saya pikir setiap pengembang Oracle terkadang menemukan fakta bahwa indeksnya turun, dia harus membangun kembali indeks dengan cepat). Atau, katakanlah kita memperkenalkan bagian baru di tabel kita, yaitu, tidak akan berhenti terjadi. Dan tempat yang sangat bermasalah adalah perubahan dalam logika aplikasi.
Jadi apa hubungannya Redefinisi Berbasis Edisi dengan itu? Dan teknologi ini - ini hanya tentang cara memperbarui aplikasi online, dengan cepat, tanpa memengaruhi pekerjaan pengguna.
Apa persyaratan untuk pembaruan online ini? Kita harus melakukan ini tanpa disadari oleh pengguna, yaitu, semuanya harus tetap dalam kondisi kerja, semua aplikasi. Asalkan situasi seperti itu dapat terjadi ketika pengguna duduk, mulai bekerja dan ingat dengan tajam bahwa ia memiliki pertemuan yang mendesak, atau bahwa ia perlu membawa mobil ke layanan. Dia bangkit, lari karena tempat kerjanya. Dan pada saat itu, kami entah bagaimana memperbarui aplikasi kami, logika pekerjaan berubah, pengguna baru sudah terhubung dengan kami, data sudah mulai diproses dengan cara baru. Jadi, pada akhirnya kita perlu memastikan pertukaran data antara versi asli aplikasi dan versi baru aplikasi tersebut. Inilah mereka, dua persyaratan yang diajukan untuk pembaruan online.
Apa yang diusulkan sebagai solusi? Dimulai dengan versi 11.2 Rilis Oracle, teknologi Redefenition Berbasis Edisi diperkenalkan dan konsep-konsep seperti edisi, objek edisi, tampilan edisi, pemicu lintas-edisi diperkenalkan. Kami mengizinkan terjemahan semacam itu sebagai "versi". Secara umum, teknologi EBR dengan beberapa peregangan bisa disebut versi objek DBMS di dalam DBMS itu sendiri.
Jadi, apa Edition sebagai entitas?
Ini adalah semacam wadah di mana Anda dapat mengubah dan mengatur kode. Di dalam ruang lingkup Anda sendiri, di dalam versi Anda sendiri. Dalam hal ini, data akan diubah dan ditulis hanya untuk struktur yang terlihat dalam Edisi saat ini. Representasi versi akan bertanggung jawab untuk ini, dan kami akan mempertimbangkan pekerjaan mereka lebih lanjut.
Seperti inilah teknologi di luar. Bagaimana cara kerjanya? Sebagai permulaan - pada tingkat kode. Kami akan memiliki aplikasi asli kami, versi 1, di mana ada beberapa algoritma yang memproses data kami. Ketika kami memahami bahwa kami perlu memutakhirkan, saat membuat edisi baru, terjadi hal berikut: semua objek yang memproses kode diwariskan dalam edisi baru ... Pada saat yang sama, di kotak pasir yang baru dibuat ini, kami dapat bersenang-senang seperti yang kami inginkan, tanpa terlihat oleh pengguna: kami dapat mengubah pekerjaan mana yang fungsi, prosedur; ganti paket; kita bahkan dapat menolak untuk menggunakan objek apa pun.
Apa yang akan terjadi Versi asli tetap tidak berubah, tetap tersedia untuk pengguna dan semua fungsionalitas tersedia. Dalam versi yang kami buat, dalam edisi baru, objek-objek yang belum diubah tetap tidak berubah, yaitu, diwarisi dari versi asli aplikasi. Dengan blok yang telah kami sentuh, objek diperbarui dalam versi baru. Dan tentu saja, ketika Anda menghapus suatu objek, itu tidak tersedia untuk kita dalam versi baru dari aplikasi kita, tetapi tetap berfungsi dalam versi asli. Begitulah cara kerjanya pada tingkat kode.
Apa yang terjadi pada struktur data dan apa hubungan tampilan versi dengan itu?
Karena struktur data yang kami maksudkan adalah sebuah tabel, dan tampilan versi, ini sebenarnya adalah sebuah shell (saya menyebut diri saya "pencarian" etologis dari tabel kami), yang merupakan proyeksi ke kolom asli. Ketika kami memahami bahwa kami perlu mengubah operasi aplikasi kami, dan, katakanlah, entah bagaimana menambahkan kolom ke tabel, atau bahkan melarang penggunaannya, kami membuat tampilan versi baru dalam versi baru kami.
Dengan demikian, di dalamnya kita hanya akan menggunakan kumpulan kolom yang kita butuhkan, yang akan kita proses. Jadi, dalam versi asli aplikasi, data ditulis ke set yang didefinisikan dalam lingkup ini. Aplikasi baru akan menulis ke set kolom yang didefinisikan dalam ruang lingkupnya.
Strukturnya jelas, tetapi apa yang terjadi pada data? Dan bagaimana semua ini saling berhubungan, Kami memiliki data yang disimpan dalam struktur asli. Ketika kita memahami bahwa kita memiliki algoritma tertentu yang memungkinkan kita untuk mengkonversi data dari struktur asli dan menguraikan data ini menjadi struktur baru, algoritma ini dapat dimasukkan ke dalam apa yang disebut pemicu versi silang. Mereka hanya bertujuan melihat struktur dari berbagai versi aplikasi. Artinya, tergantung pada ketersediaan algoritma seperti itu, kita dapat menggantungnya di atas meja. Dalam hal ini, data akan ditransformasikan dari struktur asli ke yang baru, dan pemicu maju progresif akan bertanggung jawab untuk ini. Asalkan kita perlu memastikan transfer data ke versi lama, sekali lagi, berdasarkan beberapa jenis algoritma, pemicu terbalik akan bertanggung jawab untuk ini.
Apa yang terjadi ketika kami memutuskan bahwa struktur data kami telah berubah dan kami siap untuk bekerja dalam mode paralel baik untuk versi aplikasi yang lama maupun untuk versi aplikasi yang baru? Kami cukup menginisialisasi pengisian struktur baru dengan beberapa pembaruan menganggur. Setelah itu, kedua versi aplikasi kami tersedia untuk digunakan oleh pengguna. Fungsionalitas tetap untuk pengguna lama dari versi lama aplikasi, untuk pengguna baru, fungsionalitas akan berasal dari versi baru aplikasi.
Ketika kami menyadari bahwa pengguna dari aplikasi lama semuanya terputus, versi ini bisa disembunyikan dari penggunaan. Mungkin bahkan struktur data telah diubah. Kami ingat bahwa dengan kami tampilan versi dalam versi yang baru dibuat akan hanya akan melihat kumpulan kolom 1, 3,4,5. Nah dan sesuai, jika kita tidak membutuhkan struktur ini, itu bisa dihapus. Berikut ini ringkasan singkat cara kerjanya.
Apa batasan yang diberlakukan? Yaitu, Oracle yang berhasil, Oracle yang luar biasa, Oracle yang luar biasa: mereka datang dengan hal yang keren. Keterbatasan pertama saat ini adalah objek dari tipe versi, ini adalah objek PL / SQL, yaitu, prosedur, paket, fungsi, pemicu, dan sebagainya. Sinonim diversi dan tampilan diversi.
Apa yang tidak diversi dan tidak akan pernah diversi adalah tabel dan indeks, pandangan terwujud. Yaitu, dalam versi pertama, Anda dan saya hanya mengubah metadata dan dapat menyimpan salinannya sebanyak yang Anda inginkan ... pada kenyataannya, sejumlah salinan metadata ini, tetapi lebih lanjut tentang itu nanti. Yang kedua menyangkut data pengguna, dan replikasi mereka akan membutuhkan banyak ruang disk, yang tidak logis dan sangat mahal.
Batasan berikutnya adalah bahwa objek skema akan sepenuhnya versi jika dan hanya jika mereka milik pengguna yang diotorisasi versi. Bahkan, hak istimewa ini bagi pengguna hanyalah semacam tanda dalam basis data. Anda dapat memberikan izin ini dengan perintah biasa. Tetapi saya menarik perhatian Anda pada fakta bahwa tindakan ini tidak dapat diubah. Karena itu, jangan langsung menyingsingkan lengan baju kita, ketik semua ini di server pertempuran, dan pertama kita akan menguji.
Batasan berikutnya adalah bahwa objek yang tidak berversi tidak dapat bergantung pada yang berversi. Ya, itu cukup logis. Minimal, kami tidak akan mengerti edisi mana, versi objek yang akan dilihat. Pada titik ini, saya ingin menarik perhatian, karena kami harus bersaing dengan momen ini.
Selanjutnya Tampilan berversi milik pemilik skema, pemilik tabel, dan hanya di setiap versi. Pada intinya, tampilan berversi adalah pembungkus tabel, jadi jelas bahwa itu harus unik di setiap versi aplikasi.
Yang juga penting, jumlah versi dalam hierarki mungkin 2000. Kemungkinan besar, ini karena Anda tidak memuat kamus dengan berat. Saya katakan awalnya bahwa objek, ketika membuat edisi baru, diwariskan. Sekarang hierarki ini dibangun secara linier secara eksklusif - satu orangtua, satu keturunan. Mungkin akan ada semacam struktur pohon, saya melihat beberapa prasyarat untuk ini dalam kenyataan bahwa Anda dapat mengatur perintah pembuatan versi sebagai pewaris dari edisi tertentu. Ini saat ini merupakan hierarki yang sepenuhnya linier, dan jumlah tautan dalam rantai ini adalah 2000.
Jelas bahwa dengan beberapa peningkatan aplikasi kami, jumlah ini dapat habis atau melampaui batas, tetapi mulai dengan rilis Oracle yang ke-12, edisi ekstrem yang dibuat dalam rantai ini dapat dipotong dengan ketentuan bahwa mereka tidak lagi digunakan.
Saya harap Anda sekarang mengerti kira-kira cara kerjanya. Jika Anda memutuskan - "Ya, kami ingin menyentuhnya" - apa yang perlu dilakukan untuk beralih menggunakan teknologi ini?
Hal pertama yang pertama, Anda perlu menentukan strategi penggunaan. Tentang apa ini? Memahami seberapa sering struktur tabel kita berubah, apakah kita perlu menggunakan tampilan berversi, terutama jika kita membutuhkan pemicu lintas-versi untuk memastikan perubahan data. Atau kita hanya akan versi kode PL / SQL kami. Dalam kasus kami, ketika kami menguji, kami melihat bahwa kami masih memiliki perubahan tabel, jadi kami mungkin juga akan menggunakan tampilan versi.
Selanjutnya, secara alami, skema yang dipilih diberikan hak berversi.
Setelah itu, kami mengganti nama tabel. Mengapa ini dilakukan? Hanya untuk melindungi objek kode PL / SQL kami dari modifikasi tabel.
Kami memutuskan untuk melempar simbol tajam di ujung meja kami, mengingat batas 30 karakter. Setelah itu, tampilan versi dibuat dengan nama tabel asli. Dan mereka sudah akan digunakan di dalam kode. Adalah penting bahwa dalam versi pertama yang kita pindahkan, tampilan berversi adalah kumpulan kolom lengkap dalam tabel sumber, karena objek kode PL / SQL dapat mengakses semua kolom ini persis sama.
Setelah itu, kami melebihi pemicu DML dari tabel ke tampilan berversi (ya, tampilan berversi memungkinkan kami untuk menggantung pemicu di atasnya). Mungkin kita mencabut hibah dari tabel dan memberikannya kepada pandangan yang baru dibuat ... Secara teori, semua poin ini sudah cukup, kita hanya perlu mengkompilasi ulang kode PL / SQL dan pandangan dependen.
I-dan-dan-dan-dan ... Secara alami, tes, tes, dan tes sebanyak mungkin. Kenapa harus tes? Itu tidak bisa sesederhana itu. Apa yang kami temukan?
Inilah
pos kedua saya .