Big Data DBA: Database

Belajar Big Data Solusi Data Management Dengan Big Data

Articles by "Database"

Postgresql bottleneck sering kita alami ketika lalu lintas pada database postgresql kita sudah semakin padat. Sama halnya di jalan raya ketika trafik sudah semakin padat maka yang terjadi adalah kemacetan di jalan raya.

mengatasi postgresql bottleneck karena traffic
postgresql bottleneck



Banyak tumpukan saat ini diimplementasikan dengan mempercayai Object Relational Mapper, ORM, untuk melakukan hal yang benar dengan PostgreSQL sementara seseorang membuat logika bisnis penting pada sisi proses server aplikasi. Untuk sebagian besar postgresql bottleneck, ini berhasil dengan cukup baik tetapi seiring waktu seseorang harus mengunjungi kembali server database saat loadnya tinggi. Yang terjadi pada PostgreSQL, ia dapat mengalami pelambatan seiring peningkatan lalu lintas.

Ada banyak cara untuk mengatasi kemacetan kinerja / postgresql bottleneck, tetapi pada pembahasan berikutini kita bisa melihat hal ini dalam beberapa masalah seperti berikut:

  • Tuning Performance Parameters
  • Session Connections
  • Bloat
  • Autovacuum: Basic
  • Autovacuum: Advanced
  • Data Hotspots
  • Competing Application Processes
  • Replication Latency
  • Server Environment

Tentang “Kategori” dan “Potensi Dampak” PostgreSQL Bottleneck

Kompleksitas yang kita alami mengacu pada tingkat kesulitan dalam mengimplementasikan solusi tertentu. Sedangkan dampak potensial memberi Anda gambaran tentang dampak mitigasi yang ideal pada kinerja sistem Anda. Namun terkadang, karena usianya, jenis sistem, teknis kerja, dll., menggambarkan kompleksitas secara akurat dan potensi dampaknya dapat menjadi masalah. Pada akhirnya, mengingat lingkungan yang sangat kompleks, penilaian Andalah yang membuat keputusan akhir dalam melakukan aktivitas terhadap database postgresql.

Kategori kompleksitas

  • Low
  • Medium
  • High
  • Low-Medium-High

Kategori Dampak Potensial

  • Low
  • Medium
  • High
  • Low-Medium-High

Mengatasi PostgreSQL Bottleneck dengan Parameter Performance Tuning

Kompleksitas: Low
Potensi Dampak: High

Ada suatu ketika ternyata versi postgres modern masih dapat berjalan di i386. Meskipun setelan default telah diperbarui, parameternya masih disetel untuk menggunakan sumber daya minimal saat penginstalannya.

Pengaturan ini adalah yang paling mudah diatur dan biasanya diperbarui saat layanan diinstal pertama kali. Ketika anda tidak menyesuaikan nilai-nilai ini maka dapat mengakibatkan CPU dan IO tinggi yang merupakan salah satu penyebab postgresql bottleneck:

  • ukuran_cache_efektif ~ 50 hingga 75%
  • shared_buffers ~ 1/4 – 1/3 total RAM sistem
  • work_mem ~ 10MB

Jadi mari kita bahas variabel-variabel ini.

Nilai efektif cache yang disarankan, meskipun tipikal, dapat disetel secara tepat dengan merujuk ke “atas” yaitu RAM + free cache.

Mengatur shared buffer adalah teka-teki yang menarik. Ada dua cara untuk melihat pengaturan ini: dengan asumsi Anda memiliki basis data kecil, seseorang dapat menyetel shared buffer cukup tinggi sehingga pada dasarnya seseorang memiliki sistem basis data residen RAM.

Jika tidak, anda dapat mengkonfigurasi untuk memuat tabel dan indeks tersebut, yang paling sering digunakan oleh layanan, untuk tetap berada di RAM (aturan lama adalah 80/20). Pengaturan 1/3 RAM sistem dulunya adalah pengaturan yang direkomendasikan tetapi seiring waktu aturan tersebut turun menjadi 1/4 karena mesin memperoleh lebih banyak RAM karena ada yang namanya terlalu banyak kinerja ke shared buffer.

RAM yang terlalu sedikit berarti lebih banyak kerja CPU dan IO yang lebih tinggi. Anda akan tahu jika setelan shared buffer terlalu tinggi saat beban CPU dan kinerja IO mencapai titik stabil.

postgresql bottleneck io ram
sumber : percona


Faktor lain yang perlu dipertimbangkan sebagai faktor yang berpengaruh atas postgresql bottleneck adalah cache OS; dengan RAM yang cukup, Linux akan men-cache tabel dan indeks dalam RAM dan dapat bergantung pada berbagai pengaturan, mengelabui PostgreSQL agar percaya bahwa ia membaca dari disk bukan dari RAM.

Kinerja meningkat dengan mengorbankan peningkatan redundansi dengan sering menyalin halaman yang sama yang ditemukan di shared buffer ke dalam cache OS, yang merupakan alasan lain untuk menghindari cache shared buffer yang terlalu besar. Untuk perfeksionis di antara kita, lihat ekstensi pg_buffercache yang membaca penggunaan cache secara real-time (TIP: lihat tabel ini).

Menyetel work_mem terlalu rendah menjamin kinerja yang buruk karena diproses sebagai file sementara pada disk. Di sisi lain, meskipun menyetelnya tinggi tidak mempengaruhi kinerja, hal itu berisiko membuat server kekurangan RAM jika terlalu banyak koneksi yang aktif pada satu waktu.

Penggunaan RAM yang sama dengan work mem yang digunakan untuk setiap operasi pengurutan. Anda perlu melakukan sedikit penghitungan aritmatika untuk instance RAM yang digunakan oleh setiap kueri dan sesi. TIPS: gunakan EXPLAIN ANALYZE untuk melihat di mana operasi pengurutan dilakukan dan dengan memvariasikan nilai dalam sesi tertentu, seseorang dapat melihat saat operasi tersebut di tuliskan ke disk.

Mengatasi PostgreSQL Bottleneck dengan Session Connection: Pengelolaan

Kompleksitas: Low
Potensi Dampak: Low-Medium-High

Lalu Lintas Tinggi sering digambarkan sebagai sejumlah besar koneksi yang terjadi dalam interval waktu yang singkat. Terlalu banyak koneksi yang memblokir proses dan dapat menunda respons kueri dan bahkan dapat menyebabkan kesalahan sesi. Kalo sudah begini akan terjadi postgresql bottleneck, mau mencoba menangani akar permasalahannya bisa jadi bukanlah hal yang mudah tanpa menggali informasi dari log postgres.

Perbaikan yang mudah adalah meningkatkan jumlah koneksi:

# postgresql.conf: default is set to 100<br />max_connections


Alternatif untuk mengatasi postgresql bottleneck selanjutnya, pendekatan yang lebih canggih adalah penggabungan koneksi. Ada banyak solusi tetapi teknologi yang paling umum digunakan adalah pgbouncer. Di antara banyak kemampuannya, pgbouncer dapat mengatur sesi koneksi menggunakan salah satu dari tiga mode berikut :

  • Session pooling: Metode paling halus/sopan. Kenapa dikatakan metode paling sopan? Ketika klien terhubung, koneksi server akan ditetapkan untuk selama klien tetap terhubung. Ketika klien terputus, koneksi server akan dimasukkan kembali ke dalam pool. Ini adalah metode default.
  • Transaction pooling: Sambungan server ditetapkan ke klien hanya selama transaksi. Ketika PgBouncer mengetahui bahwa transaksi telah selesai, koneksi server akan dimasukkan kembali ke dalam pool.
  • Statement pooling: Metode paling agresif. Sambungan server akan dimasukkan kembali ke dalam kumpulan segera setelah kueri selesai. Transaksi multi-statement tidak diizinkan dalam mode ini karena akan rusak.

Secure Socket Layer (SSL), adalah pertimbangan lain pada kasus postgresql bottleneck. Ketika dikonfigurasi untuk menggunakan sertifikat SSL, perilaku default PostgreSQL mendorong semua sesi penghubung untuk menggunakan SSL sehingga menghabiskan lebih banyak daya pemrosesan CPU daripada sesi yang tidak terenkripsi.

Untuk case postgresql bottleneck ini, anda dapat mengkonfigurasi aturan otentikasi berbasis host, pg_hba.conf, memaksa sesi klien biasa untuk tidak menggunakan SSL dan sebaliknya memesan penggunaannya untuk tugas-tugas administratif, oleh superuser, atau dengan replikasi streaming.

Mengatasi PostgreSQL Bottleneck dengan Autovacuum: Basic

Kompleksitas: Medium
Potensi Dampak: Low-Medium

Multi-Version Concurrency Control adalah salah satu prinsip dasar yang membuat PostgreSQL menjadi solusi DBMS yang populer. Namun, salah satu kelemahan yang disayangkan adalah bahwa untuk setiap catatan yang diperbarui atau dihapus, tupel mati (sudah tidak digunakan) yang pada akhirnya harus dibersihkan.

Proses autovacuum yang disetel secara tidak tepat, merupakan mekanisme yang menangani dead-tuple, mengurangi kinerja, yaitu membuat server semakin sibuk, semakin signifikan pengaruhnya terhadap postgresql bottleneck.

Ketika anda mengelola daemon autovacuum, anda dapat menggunakan tiga (3) parameter berikut untuk mengatasi terjadinya postgresql bottleneck:

  1. autovacuum_max_workers: Meningkatkan jumlah worker autovacuum dari default tiga (3) worker berarti lebih banyak proses tersedia untuk menyedot datacluster, yang merupakan fitur yang sangat berguna untuk dipertimbangkan ketika dihadapkan dengan sejumlah besar tabel yang sangat besar. Idealnya, seseorang membuat satu worker per CPU. Worker tidak boleh melebihi jumlah CPU, karena terlalu banyak worker berpotensi berdampak pada peningkatan penggunaan CPU yang menyebabkan postgresql bottleneck. Biasanya anda bisa menetapkan nomor di antara dua batas ini. Ini adalah tindakan penyeimbangan antara memaksimalkan efisiensi autovacuum versus kinerja sistem secara keseluruhan.
  2. maintenance_work_mem: Semakin besar nilainya, semakin efisien penyedotannya. Ingatlah bahwa ada hukum keuntungan yang semakin berkurang. Nilai yang terlalu tinggi pada akhirnya hanya membuang-buang RAM dan yang lebih buruk dapat menghabiskan jumlah RAM yang tersedia untuk seluruh sistem database.
  3. autovacuum_freeze_max_age: Parameter ini mengurangi TXID WRAPAROUND. Semakin lama usia semakin jarang berjalan mengurangi jumlah pemuatan sistem. Tetapi seperti semua parameter autovacuum yang disebutkan sejauh ini, ada peringatan. Menunda nilai terlalu lama dan Anda berisiko kehabisan nomor txid sebelum proses selesai yang menyebabkan server mematikan paksa untuk melindungi integritas data. Menentukan nilai yang benar memerlukan tren txid terbesar / terlama terhadap proses autovacuum saat kueri pg_stat_activity untuk aktivitas WRAPAROUND.

Waspadalah terhadap RAM dan CPU yang melakukan over-commit, dapat menjadi postgresql bottleneck. Semakin tinggi nilai yang awalnya ditetapkan, semakin besar jumlah risiko sumber daya yang dikonsumsi habis saat pemuatan sistem meningkat. Mengatur terlalu tinggi dapat mengalami penurunan kinerja secara tiba-tiba saat memuat melebihi titik tertentu.

TIPS: Mirip dengan alokasi RAM terkait work_mem, anda dapat melakukan aritmatika atau benchmark environment untuk mengatur nilai secara optimal untuk menghindari terjadinya postgresql bottleneck.

Mengatasi PostgreSQL Bottleneck dengan Autovacuum: Advanced

Kompleksitas: High
Potensi Dampak: High

Karena banyaknya upaya yang terlibat, seseorang harus mempertimbangkan metode ini ketika risiko sistem database mendorong host ke batas fisiknya, dan pembengkakan yang berlebihan diidentifikasi sebagai masalah yang menyebabkan postgresql bottleneck.

Mengedit parameter runtime autovacuum di postgresql.conf adalah metode paling umum yang digunakan untuk mengontrol perilakunya untuk datacluster. Sayangnya, pendekatan seperti ini mungkin saja cocok untuk semua namun tidak berfungsi dengan baik dalam jangka panjang terutama sebagai skala sistem untuk menghindari postgresql bottleneck.

Parameter Penyimpanan Tabel: Seringkali akan ada tabel yang aktivitasnya mewakili jumlah yang signifikan dari total churn datacluster. Menyesuaikan berbagai parameter autovacuum pada setiap tabel demi tabel adalah cara terbaik untuk mengurangi hubungan hiper-aktif tanpa menggunakan pemanggilan VACUUM manual yang dapat berdampak signifikan pada sistem yang berujung pada postgresql bottleneck.

Setting tabel individual menggunakan SQL COMMAND ini.

ALTER TABLE .. SET STORAGE_PARAMETER

Mengatasi PostgreSQL Bottleneck dengan Bloat

Kompleksitas: Low
Potensi Dampak: Medium-High

Seiring waktu, bahkan dengan niat terbaik, atau tidak, kinerja dapat menurun karena kebijakan penyedotan yang tidak memadai yang menyebabkan “kembung” yang berlebihan bahkan menyetel daemon autovacuum dan secara manual memanggil VACUUM tidak akan mudah diselesaikan. Untuk kasus ini, ekstensi pg_repack akan membantu masalah postgresql bottleneck anda.

pg_repack: membangun kembali dan mengatur ulang tabel dan indeks dalam kondisi produksi.

Mengatasi PostgreSQL Bottleneck dengan Data Hotspots

Kompleksitas: High
Potensi Dampak: Low-Medium-High

Mirip dengan MySQL HotSpots, PostgreSQL experience, dan resolusinya, hot spot bergantung pada pengetahuan luas tentang aliran data dan dapat, pada mitigasi yang paling ekstrim, memperbaiki arsitektur sistem.

Berikut adalah beberapa teknik mitigasi yang lebih populer:

  • Indeks: Mengkonfirmasi bahwa kolom kriteria memiliki indeks yang ditetapkan berpeluang besar untuk meningkatkan kinerja kueri. Teknik lainnya adalah dengan mengkueri berbagai katalog dan tampilan pemantauan dan mengonfirmasi bahwa Perintah SQL meminta kolom dengan indeks. TIPS: gunakan tools seperti ekstensi pg_stat_statement dan pgbadger untuk menentukan kinerja kueri.
  • Heap Only Tuple (HOT): Ada yang namanya terlalu banyak indeks. Kurangi potensi pembengkakan dan kurangi ukuran tabel dengan menghapus semua indeks yang tidak digunakan pada klausa kuery WHERE dalam kueri SELECT.
  • Partisi Tabel: Tidak ada yang mempengaruhi kinerja seperti tabel yang beberapa kali lebih besar dari ukuran tabel rata-rata. Membagi tabel besar menjadi partisi yang lebih kecil misalnya dapat meningkatkan kinerja kueri saat membuat kueri data yang dipartisi menurut tanggal. Dan karena hanya satu worker autovacuum yang diizinkan untuk memproses satu tabel, memecahnya menjadi banyak tabel yang lebih kecil memungkinkan lebih dari satu pekerja untuk melakukan autovacuum. Keuntungan lain dari mempartisi tabel adalah bahwa pembersihan data jauh lebih efisien dan lebih cepat dengan memotong satu tabel yang dipartisi daripada menghapus sejumlah besar baris dari satu tabel berukuran super.
  • Parallel Querying: Diperkenalkan dalam versi terbaru postgres, anda dapat menggunakan beberapa CPU yang memproses satu kueri di mana sebelumnya hanya satu prosesor per kueri.
  • De-Normalisasi: Bergantung pada spesifikasinya, anda dapat meningkatkan kinerja dengan menggabungkan kolom dari beberapa tabel menjadi tabel tunggal yang lebih besar. Keuntungan kinerja dibuat dengan mengurangi perencanaan kueri tetapi dengan mengorbankan peningkatan redundansi data. Renungkan opsi ini dengan cermat sebelum menggunakannya! Cocok untuk digunakan pada datawarehouse.

Mengatasi PostgreSQL Bottleneck dengan Competing Application Processes

Kompleksitas: Low
Potensi Dampak: High

Aplikasi PHP + Java + Python: Hindari menjalankan aplikasi dan postgres di host yang sama. Kembali ke masa lalu, seseorang dapat dengan mudah menggabungkan layanan web dan RDBMS pada mesin yang sama karena penggunaan sumber daya mereka gratis.

Waspadalah terhadap aplikasi yang berbasis pada bahasa ini karena mereka dapat menghabiskan banyak RAM, terutama bisa menjadi pengumpulan sampah, yang kemudian bersaing dengan sistem database yang mengurangi kinerjanya secara keseluruhan yang berkontribusi dalam postgresql bottleneck .

Mengatasi PostgreSQL Bottleneck dengan Replication Latency

Kompleksitas: Low
Potensi Dampak: High

async vs sync: Versi terbaru dari postgres mendukung replikasi logis dan streaming dalam mode sinkron dan asinkron. Meskipun mode replikasi default adalah asinkron, anda harus mempertimbangkan implikasi penggunaan replikasi sinkronisasi terutama melalui koneksi jaringan dengan latensi kurang dari ideal.

Mengatasi PostgreSQL Bottleneck dengan Server Environment

Terakhir, yang tidak kalah penting untuk mengatasi postgresql bottleneck, adalah pertimbangan yang paling mendasar yaitu membuat host lebih besar dan lebih baik. Mari kita tinjau apa yang diberikan oleh masing-masing sumber daya berikut melalui peningkatan kinerja ke database PostgreSQL yang dapat membantu mengatasi postgresql bottleneck:

  • RAM: Semakin banyak semakin baik, ini memungkinkan kita untuk menetapkan lebih banyak RAM ke kueri dan meningkatkan jumlah sesi individu. Lebih banyak RAM berarti lebih banyak database di-cache sehingga mengoptimalkan IO.
  • CPU: Lebih banyak CPU berarti lebih banyak proses bercabang yaitu lebih banyak menyedot micro process, koneksi sesi, dll.
  • HDD: Optimalisasi ukuran dan kecepatan
    • meningkatkan ukuran database yang diizinkan
    • kinerja kueri keseluruhan meningkat karena IO yang lebih cepat terutama ketika operasi seperti penggabungan jenis penulisan ke disk
  • Partisi Disk:
    • Memecah datacluster di beberapa partisi meningkatkan jumlah saluran dan mengisolasi operasi berbeda yang dilakukan postgres pada saat yang bersamaan. Misalnya, anda dapat meletakkan indeks dan tabel pada partisi terpisah yang memiliki karakteristik kinerja berbeda.
    • Tabel sesi sementara dan operasi seperti merge sort dapat didedikasikan untuk satu partisi berkecepatan tinggi atau dijalankan di beberapa partisi untuk meningkatkan IO
    • Pencatatan log dapat diisolasi ke dalam partisi dan jika Anda kehabisan ruang, hal itu tidak akan memengaruhi RDBMS
    • WALL logs, mirip dengan logging biasa, dapat memiliki partisi sendiri untuk operasi write only. Jika kehabisan ruang, seperti yang dapat terjadi saat pengiriman log dan koneksi ke slave terputus, integritas database sepenuhnya terjamin karena tabel berada di tempat lain.

Demikianlah point-point yang ditengarai dapat menimbulkan ataupun menyebabkan prostgresql bottleneck. Apakah tulisan mengenai postgresql bottleneck ini bermanfaat bagi anda ?

Apabila memang tulisan mengenai postgresql bottleneck ini bermanfaat bagi anda, silahkan untuk membaginya dengan rekan-rekan anda supaya dapat lebih banyak memberikan manfaat.


Sumber : Percona

Mengenal Database Oracle 18c – Big Data DBA.  Pada postingan kita kali ini, kita akan melihat-lihat terlebih dahulu mengenai database terbaru dan digadang-gadang menjadi database masa depan dari perusahaan ternama Oracle. Sebagaimana yang telah diumumkan oleh Larry Ellison di ajang OOW 2017 tentang database masa depan yang merupakan perubahan besar dalam dunia teknologi Oracle. Dalam dunia otomasi, kita telah melihat perubahan besar dari kehidupan sehari-hari menjadi kehidupan profesional. Ada kemajuan besar di setiap area kehidupan. Perjalanan database Oracle dimulai dari Oracle v2: hingga ke versi terbaru saat ini yaitu pada versi oracle 12c.


ORACLE DATABASE 18C

Sebagaimana pemberitaan akhir-akhir ini, kita akan melihat database oracle berikutnya yaitu pada oracle 18c. Sebagian besar biaya perusahaan untuk melakukan tuning kinerja / performance dan maintenance database, karena kinerja bisnis yang buruk harus mengalami banyak masalah seperti kehilangan bisnis, beban kerja, dll, hal-hal penting semacam ini tetap diingat saat merancang database Oracle 18c yang sekarang menjadi product fenomenal Oracle. Database oracle 18c ini juga disebut sebagai database otonomi awan (Cloud Autonomic Database). Database oracle 18c menawarkan otomasi total berdasarkan machine learning dan menghilangkan tenaga kerja manusia, kesalahan manusia, dan juga tuning yang dilakukan manual.





Pada database oracle versi 18c ini memiliki banyak fitur baru yang lebih memilih tidak adanya tenaga kerja manusia. Jadi bisa dibilang pada oracle database 18c, tenanga manusia sudah dihilangkan. Tidak adanya tenaga kerja manusia berarti telah memangkas setengah biaya, tidak ada kesalahan manusia berarti 100x dapat diandalkan. Sehingga tujuan akhir yang akan dicapai adalah “self-driving database”.

Tidak adanya tenaga kerja manusia pada database oracle 18c meliputi otomasi dalam instalasi, patching, upgrade, dan juga tuning database oracle yaitu dengan cara menggunakan teknik robot dengan bantuan machine learning.

Teknologi Database Oracle yang sudah sangat membumi ini mengotomatisasi manajemen untuk menghadirkan availability, performance, dan security yang belum pernah ada sebelumnya dan tentu saja dengan biaya yang jauh lebih rendah. Untuk penggunaan bisnis, Database Oracle 18c akan tersedia pada bulan Desember 2017.

Sebagaimana yang sudah diketahui pada versi database oracle yang sebelumnya, database oracle ini memiliki perkembangan yang sangat pesat. Namun kita juga harus tahu bahwa pada setiap versi database oracle yang baru menyebabkan ada fitur yang hilang atau ditambahkan dari database yang sebelumnya. Ada beberapa alas an mengapa kita bisa mengatakan bahwa oracle merevolusi database cloud menjadi database self-driving pertama di dunia.


1. Self – Driving


Teknologi tumbuh begitu cepat sehingga kita bisa melihat banyak peralatan yang dapat berjalan secara otomatis, atau sering disebut dengan istilah self-driving. Sekarang hal tersebut terjadi di Database Oracle 18c. Kecerdasan self-recovering berfungsi untuk secara otomatis mendeteksi dan menerapkan pengerjaan korektif untuk memastikan akses tanpa henti ke data Anda. Database otonom baru ini mudah digunakan. Membuat data warehouse menjadi lebih sederhana. Pengguna cukup menentukan tabel, memuat data, dan kemudian menjalankan beban kerja mereka dalam hitungan detik-tidak ada penyetelan manual yang dibutuhkan.


2. Penurunan Biaya


Tidak ada bisnis yang ingin menghabiskan banyak uang sederas air mengalir. Setiap bisnis baik skala kecil maupun skala besar memainkan peran penting bagi mereka. Semua jenis industri menghabiskan banyak uang untuk departemen TI supaya dapat bertahan dalam persaingan yang besar. Dengan menggunakan database oracle 18c dapat menghilangkan downtime yang mahal karena konfigurasi manual dan rawan kesalahan dengan cara melakukan manajemen adaptif termasuk aplikasi patch, pembaruan, dan peningkatan self-driving. Self-tuning menggunakan machine learning adaptif, yang secara otomatis mengaktifkan casing kolumnar, indeks penyimpanan, kompresi, dan prioritas sumber daya untuk memberikan sumber daya yang dibutuhkan untuk pekerjaan aktual yang dilakukan pada beban kerja, dan juga untuk menghindari over-provisioning yang mahal.


3. Dapat diandalkan


Oracle database 18c memiliki kemampuan memulihkan diri secara otomatis, mendeteksi dan menerapkan tindakan perbaikan untuk memastikan akses tanpa henti ke data Anda. Oracle Autonomous Database Cloud secara otomatis akan mengimplementasikan Oracle Real Application Clusters (RAC) dan cross-region Oracle Active Data Guard untuk memastikan ketersediaan data secara terus menerus. Kita tidak dapat menentukan / menemukan waktu downtime untuk pemeliharaan, update, upgrade, atau penambahan kapasitas komputasi dan penyimpanan.

Sebagian besar Database Administrator oracle saat ini merasa was was dalam menghadapi “Autonomous Database Service Suite” yang akan membuat para DBA menjadi tanpa pekerjaan alias menganggur. Namun pada kenyataan nya tidak lah demikian, karena sebenarnya ada beberapa jenis layanan database di cloud yang butuh untuk ditangani tenaga2 mantan DBA nantinya .. 

a. Oracle Database Cloud Service
b. Oracle Bare Metal Cloud Database Service
c. Oracle Database Exadata Cloud Service
d. Oracle Database Exadata Cloud Machine
e. Oracle Database Express Cloud Service

Sekarang, kita akan melihat beberapa hal penting tentang Database Otonomi pada database oracle 18c yang mungkin sebagian besar orang tidak tahu.

Oracle self driving database (Autonomous Database) akan tersedia mulai Oracle18c namun masih ada periode oracle support yang sangat besar untuk versi database oracle 12c R1 / R2. 12c R1 sampai 4 tahun lebih apabila kita hitung dari tahun ini, artinya kita membicarakan support oracle database 12C R1 sampai dengan lebih kurang tahun 2021.

Oracle support untuk versi database oracle 12c R2 sampai dengan April 2025 dan kemungkinan masih bias diperpanjang. Seperti yang kita ketahui bahwa para pengguna database oracle biasanya tidak bergerak begitu cepat untuk menggunakan rilis database oracle berikutnya sampai dengan mereka benar-benar membutuhkannya atau sampai masa support mendekati habis masa berlakunya. Jadi, Oracle database 18c adalah rilis yang akan digunakan untuk pelanggan yang benar-benar membutuhkannya atau oleh pelanggan yang menginginkan teknologi yang sangat up to date.

Sampai saat ini database self-driving Oracle dirancang untuk dijalankan di Exadata, seperti yang kita ketahui Exadata adalah sistem Engineering yang sangat kuat namun tidak murah .. jadi .. sebagian besar pelanggan pasti nya tidak akan menggunakan di Exadata, apalagi untuk pengguna di negara-negara berkembang. Artinya, Exadata memiliki biaya tinggi untuk menjadi perangkat keras biasa bagi sebagian besar perusahaan di seluruh dunia.

Sampai dengan pamaparan hal ini, maka tentunya tidak ada yg perlu ditakutkan bagi para DBA. Kenapa? Karena Database Oracle self-driving 18c belum akan menjadi mekanisme regular terhadap database perusahaan anda.

Jika anda tertarik untuk nantinya menggunakan database oracle 18c ini, maka anda perlu menyimak lebih banyak pemaparan berikut ini. Atau jika anda tertarik dengan big data tanpa harus mengetahui seluk beluk oracle database, maka anda juga bisa mulai cari tahu mengenai apa itu big data, serta bagaimana sebenarnya arsitektur big data.




Oracle database 18c bukanlah settingan untuk Service Database Otonomi.


Setelan Layanan Database Otonomi adalah jenis layanan yang tersedia sampai sekarang hanya untuk Oracle Public Cloud.

Setelan Layanan Database Otonomi akan berjalan hanya di Exadata (Sampai dengan saat ini, bias saja berubah lagi ke depannya).

Jadi sebenarnya Oracle Database 18c hanya release database oracle lainnya ?

Kesimpulannya adalah bahwa "Oracle 18c" akan berdampak kecil untuk database "reguler" On-premise dan layanan database yang terkait dengan "self driving".


Anda masih penasaran dengan Database “Self-Driving” ini ?


Mari kita analisa semua itu. Bagaimana bisa semua hal itu dilakukan saat ini dengan "Oracle 
Database Cloud Service (DBCS) biasa" dan bagaimana kita berpikir Oracle akan melakukannya.  Kita berbicara tentang "Bagaimana Oracle akan melakukan hal itu semua dikarenakan debut Autonomous Datawarehouse Database Cloud akan dilakukan di bulan Desember 2017”.

Penerapan Patch. 

Saat ini, jika Anda ingin menerapkan Patch, anda menggunakan DBCS hanya untuk masuk ke console, untuk melihat di layar jika ada patch yang tersedia untuk database itu dan anda hanya perlu melakukan beberapa klik untuk mengaplikasikannya .. Jadi sederhana.

Jadi .. kalua dipikir tidak "begitu sulit" bagi Oracle Corp, untuk mengganti klik menjadi proses otomatis.

Ada beberapa patch yang memerlukan penghentian database dikarenakan mereka mengubah biner, dll. Yah .. paling mungkin Oracle sudah punya mekanisme untuk menerapkan patch tanpa harus menghentikan database dan mereka telah memutuskan untuk menggunakannya sekarang .. jika kita bayangkan bagaimana cara kerja database di dalam menjalankan kalimat berurutan .. dll. setiap kalimat .. operasi .. dll semua ini bisa dikoordinasikan sehingga patch mempengaruhi entah bagaimana "posting" kalimat .. dll. Fakta menerapkan patch dengan sendirinya bukanlah hal yang besar mengingat tingkat perkembangan produk Oracle selama bertahun-tahun .. Jadi .. patch yang diaplikasikan dengan sendirinya hanyalah sebuah langkah maju yang berhubungan dengan tingkat otomasi.


Upgrade

Sampai sekarang ketika Anda bekerja dengan DBCS, satu-satunya cara untuk mengupgrade database yang sudah bekerja di cloud adalah menciptakan service lain yang akan mempunyai node komputasi lain dan kemudian kita menerapkan prosedur reguler untuk mengupgrade database tersebut. Namun, kita harus ingat bahwa Oracle telah bekerja sangat keras dalam membangun mekanisme yang sangat maju untuk mengelola PDB. Saat ini kita bisa mengkloning PDB secara hot-plug, kita bisa memindahkan PDB dari satu kontainer ke wadah lain yang sedang aktif .. pada dasarnya sangat mirip dengan mekanisme yang ditanamkan untuk memindahkan datafile secara online .. jadi .. teknologi ini sudah sangat matang dilakukan oleh Software Oracle untuk kali ini .. Jadi .. Upgrade database pasti merupakan prosedur yang sama untuk apa yang dilakukan dengan PDB, definisi boot CDB-nya memiliki binari dari versi yang sesuai dan kita hanya memindahkan data. Maka bisa kita tarik kesimpulan itulah mekanisme perangkat lunak Oracle database yang akan digunakan untuk meng-upgrade database secara “hot”. Jadi .. jika kita menyadari dengan semua pemaparan di atas .. semua ini hanyalah teknologi yang kita gunakan dengan rilis saat ini .. Perbedaan dalam database otonom adalah mereka menerapkan prosedur ini dengan database lengkap berdasarkan layanan baru ini.


Melakukan Tuning Itu Sendiri

Lebih mudah dijelaskan .. ketika anda men setting query menggunakan teknik adaptif .. dll. Semua ini bisa terjadi / dilakukan dengan database yang sedang berjalan .. membangun kembali indeks secara online .. dll. Harusnya selaras operasinya saat ini bisa dilakukan secara online. .. tidak begitu sulit untuk memiliki mesin AI (Artificial Intelligence) yang mengumpulkan data dan mengambil beberapa keputusan berdasarkan tes internal .. statistik .. dll. jadi .. tingkat otomasi / otonom baru ini hanya apa yang kita miliki namun dilakukan secara otomatis.


Apakah anda tertarik untuk melanjutkan pembahasan oracle database 18c ini? atau anda ingin melihat langsung pemaparan dari Larry Ellison ? anda bisa menyimak video youtube di bawah ini :




Mari kita bicara mengenai apa saja yang biasa dilakukan saat melakukan tuning :


Penerapan Patch: 

Dilakukan dari waktu ke waktu .. meskipun tidak terlalu sering .. jadi .. tidak banyak perubahan yang harus di lakukan saat kita melakukan pekerjaan ini.

Upgrade:

Apalagi untuk upgrade database oracle.. sangat jarang kapan kita mengaplikasikan upgrade ke database .. jadi .. tidak banyak perubahan yang harus di lakukan ketika kita melakukan pekerjaan ini.

Tuning itu sendiri:

Banyak perusahaan konsultan menggunakan banyak waktu dalam pengaturan secara konstan ke database karena berbagai alasan, sangat umum beberapa objek, beberapa perintah, beberapa kode, dll yang ditambahkan, dihapus, dirubah dalam database dan tentu saja variasi bagian ini akan berpengaruh dalam performa database oracle. Hal ini bisa berdampak relatif tinggi pada biaya banyak perusahaan, karena pengaturan database secara konstan menyiratkan biaya tinggi yang berkelanjutan. Tentu .. kita harus melihat seberapa bagus mesin bisa melakukan ini. Kita harus ingat bahwa saat ini sudah tersedia "Tuning Advisor" dan mereka tidak sempurna, terkadang kita menerapkan beberapa rekomendasi dan kinerja beberapa eksekusi perintah. Yang bisa menjadi kondisi terburuk adalah faktor "Tuning itu sendiri", bener bener bener bener bener bener bener bener bener bener ya. Jika hasilnya sangat bagus dan nyaman, pastinya faktor ini akan mengurangi banyak biaya bagi perusahaan dan tentu saja akan mempengaruhi cara DBA atau yang bertugas melakukan setting database.

Jadi .. ada satu hal penting untuk dipikirkan .. apakah memang pada oracle database enterprise anda sangat penting untuk menjalankan semua tuning ini. Tentunya dengan sendirinya tanpa adanya seseorang yang bisa memantau apa yang sedang dilakukan database, apakah ini suatu kelebihan atau justru menjadi bom waktu untuk DBA  ..?

Kita akan jujur .. pekerjaan yang kita lakukan dengan database kritis tidak akan mungkin memberi kepercayaan 100% pada perangkat lunak mesin untuk menyesuaikan diri dengan permintaan tanpa kendali atau pengawasan manusia. Tentu saja, memang ada beberapa database yang berada dalam kendali  beberapa tingkat kepentingan, atau keadaan yang sesuai dengan model itu yang memang harus disetel 100% tanpa pengawasan tapi bukan kasus biasa.

Dalam penyesuaian process autonomous database DBA akan memilih elemen apa yang bisa disetel secara otomatis dan yang mana dari mereka akan tetap terkendali dengan dBA. Pada akhirnya .. DBA akan selalu dibutuhkan . Pada kondisi ini DBA akan memiliki lebih banyak fasilitas untuk melakukan pekerjaan  mereka lebih mudah, tapi kenyataan berpikir untuk benar-benar mengganti manusia adalah sesuatu yang sulit terjadi meski mesin bisa mengambil keputusan yang benar.

Mari kita jelaskan contoh sederhana, Oracle Data Guard memiliki pilihan untuk FAILOVER secara otomatis dalam beberapa keadaan, tapi untuk beberapa kemungkinan kesalahan manusia bisa saja terjadi dan database bisa failover saat manusia tidak menginginkannya, jadi sebagian besar perusahaan masih enggan untuk menggunakan FSF (Fast Start Failover), Ini adalah mekanisme yang bekerja dengan sempurna  secara teknis namun memberikan kontrol total terhadap perangkat lunak untuk menerapkan sesuatu yang penting pada data adalah sesuatu yang sebagian besar tidak boleh ditanamkan oleh perusahaan.

Secara umum dapat kita katakana bahwa database otonom akan mengurangi ribuan jam kerja untuk DBA tetapi tidak akan mewakili secara praktis dan nyata untuk melakukan penghapusan kehadiran manusia.


Jadi, database otonom menjanjikan hal berikut:


Mengurangi waktu administrasi


  • Sedikit waktu untuk infrastruktur
  • Sedikit waktu untuk menambal, mengupgrade
  • Sedikit waktu untuk memastikan ketersediaan
  • Sedikit waktu untuk menyetel

Lebih banyak waktu untuk Inovasi


  • Lebih banyak waktu pada desain database
  • Lebih banyak waktu pada analisis data
  • Lebih banyak waktu pada kebijakan data
  • dan sangat penting .. Lebih banyak waktu untuk mengamankan data

Jadi .. dengan database oracle berada di Cloud, DBA harus memperkuat kemampuan mereka dalam hal database security


Sekarang mari kita beralih ke titik analisis yang lain ..

Masa depan DBA terkait dengan Oracle Database Cloud


17 tahun yang lalu .. cukup sederhana untuk merancang arsitektur database. Anda hanya harus memutuskan untuk memasukkan database Anda ke dalam:

  • Server ..
  • Atau di Mainframe
  • Atau bahkan di mesin desktop biasa dalam beberapa kasus ..

Sekarang, ketika DBA akan memutuskan tempat untuk mengajukan database, DBA harus memikirkan banyak pilihan .. seperti:

  • Server ..
  • Mesin Virtual
  • Sistem Rekayasa seperti "Exadata"
  • dan lainnya ..

DBA dan management harus memutuskan apakah arsitektur yang akan ditanamkan:

  • "On-Prem" sebagai pilihan reguler
  • Cloud di pusat data kita sendiri (Private Cloud)
  • Hybrid Cloud
  • Public Cloud, sekarang Cloud publik memiliki lebih banyak pilihan dengan database otonom di Oracle18c – dll


Dan untuk analisa selanjutnya ..


Dahulu mungkin begitu sederhana untuk merancang arsitektur database, namun sekarang tidak seperti itu. Sekarang kita memiliki banyak pilihan, dengan masing-masing dengan pro dan kontra nya sendiri sendiri. Pada dasarnya akan ada banyak pilihan.

Jadi .. pertanyaannya adalah .. Siapa yang akan bertugas mendesain semua ini ..?

Manajer Umum? jelas tidak .. ini akan dirancang oleh Arsitek Basis Data .. (DBAs)

Sekarang DBA akan diminta lebih banyak untuk memahami bisnis daripada sekedar mekanisme menjaga database agar tetap sehat dan berjalan.

Sebelumnya biaya Server .. service .. dll .. bukan hal utama dengan apa yang harus hadapi oleh DBA.. mereka fokus hanya dalam menjaga agar database berjalan dan menginstallnya. Sekarang berbeda, untuk database di Cloud, misalnya menyiratkan keputusan tentang jenis layanan apa yang akan digunakan dan dalam mode apa .. "Metered , Non-Metered “. Faktor-faktor tersebut berdampak langsung pada ekonomi perusahaan dan modus operasi database ini, jadi .. sekarang DBA lebih terkait dengan bisnis rule.

Beberapa tahun yang lalu dari menit pertama Oracle Corp mengumumkan perilisan "Oracle Cloud", tingkat keahlian lain untuk DBA lahir, mengubah bisnis ini semakin kompleks.

Maka bisa dipastikan DBA tidak akan dipecat. Sekarang peran DBA lebih penting lagi. Peran DBA hanya bergeser untuk lebih berperan sebagai arsitek.


Siapa yang harus khawatir karena semua perubahan ini ..?


Jenis DBA (Database Administrator) operasional yang bertugas atau atau petugas yang hanya melakukan tugas sederhana seperti:


  • Memeriksa Backups.
  • Memeriksa penyimpanan.
  • Membuat beberapa laporan.
  • Memasang Patch.
  • Memasang softwares.
  • Menciptakan lingkungan yang selalu baru bagi pengembang.

Semua tugas mudah dan sederhana .. telah dihapus dengan penambahan otomasi di Oracle Releases terbaru

Misalnya, sekarang pada saat membuat Oracle Database Cloud Service, ada banyak elemen yang tercipta secara otomatis termasuk:


  • Pembuatan node (Host)
  • Instalasi Perangkat Lunak
  • dan lain sebagainya.

Jadi .. hanya dengan contoh sederhana ini .. Anda bisa menyadari bahwa pada saat bekerja dengan Oracle Database Cloud Service Anda tidak perlu menginstal softwares lagi ..

Jika Anda ingin membuat konfigurasi RAC dalam menggunakan Oracle Database Cloud Service hanyalah beberapa klik mudah dan Anda bisa juga melakukan konfigurasi RAC-DG yang kompleks.
Era tugas rutin dan membosankan semakin jauh, jadi jika Anda seorang DBA yang bertugas atas tugas sederhana semacam itu, maka jawabannya adalah iya, anda perlu khawatir dengan masa depan anda.

Bertolak belakang dengan kesimpulan di atas, jika Anda seorang DBA yang bertugas menanamkan arsitektur MAA. Database Cloud, Exadata, dll. Maka anda perlu berbahagia, pentingnya peran anda sekarang akan semakin besar.


Jadi sekarang kita coba kembali ke pusat pembicaraan kita

Anda bisa membayangkan apa yang akan menjadi visi seseorang yang memulai karir sebagai DBA dengan semua pilihan yang ada di pasaran saat ini. Seseorang yang hampir tidak belajar SQL dan "Create table ", dll. Ketika pasar sedang berbicara tentang database otonom, Ini perbandingan antara motor 100cc dan motor 1000cc, sesuatu seperti itu.


Jadi apa yang kita dapatkan dari semua ini tentang penggunaan database oracle 18c ?


#1. DBA dengan jenis tugas pemeliharaan rutin bisa dihapus dari peran atau pekerjaan mereka jika mereka tidak berevolusi untuk fokus pada semua generasi baru yang terkait dengan Database Cloud ini.

#2. DBA yang mendapat hak istimewa untuk bekerja dengan Oracle Database selama era keemasan database "On-prem", sekarang mereka berada pada saat yang tepat untuk tumbuh sejajar dengan sesuatu yang mendefinisikan "sebelum" dan "setelah " masa tersebut. Dari itu Sekarang DBA akan memiliki kesempatan untuk beralih ke peran yang lebih strategis dalam organisasi mereka dan berdasarkan pada itu pendapatan "gaji, komisi, dll" akan semakin tinggi, sekarang anda akan dilibatkan dalam keputusan penting bagi perusahaan.

#3. Maaf untuk DBA yang baru masuk di dunia database seperti ini, perjalanan yang harus Anda jalankan lebih sulit dari sebelumnya jika anda ingin mendapatkan level teratas di area ini karena hari demi hari semakin banyak pilihan.


Kesimpulan yang bisa didapatkan :


1. Jika Anda adalah tipe DBA # 1 sesuai dengan deskripsi sebelumnya, mungkin Anda memiliki beberapa pilihan berkembang menjadi # 2, atau jika Anda memutuskan untuk tetap berada dalam peran yang sama, pembayaran Anda bisa kurang dari waktu ke waktu atau bahkan peran Anda secara perlahan bisa lenyap.

2. Jika Anda tipe DBA # 2, teruskan di jalur anda ini, dan peran Anda akan semakin penting di bidang ini, oleh karena itu nilai bayaran Anda akan memiliki probabilitas tinggi untuk ditingkatkan. Satu hal lagi, sebagian besar DBA tidak akan sampai menjadi Cloud Architect karena ini memerlukan waktu belajar, meneliti, melakukan pengujian, dll. Jadi .. berbanggalah jika anda mencapainya dan bisa memanfaatkannya di dalam organisasi anda saat ini ataupun pada pekerjaan anda di masa depan.

3. Jika Anda adalah tipe DBA # 3, jangan menyerah. Jangan melihat perjalanannya terlalu lama seperti sebelumnya, teruslah belajar dan Anda akan mendapatkan level sebagai pesaing bagus di pasar.


Kita harus mengatakan bahwa teknologi membentuk sebuah langkah menuju perubahan besar yang baik untuk semua teknisi. Kita mendapatkan hal baru untuk dipelajari dan meningkatkan kemampuan teknis kita, perang industri melawan biaya dan downtime akan dipecahkan dan pelanggan adalah raja pasar di sana. Juga beberapa keuntungan bagi pelanggan akan menghemat waktu adalah perubahan positif yang sangat besar bagi mereka. Karena adanya perubahan, kita tidak bisa menjangkau sisi negatif seperti dalam sejarah komputer kita bisa melihat permintaan Computer tidak mengurangi pekerjaan dan peluang lain di sisi lain sudah bisa menyelesaikan banyak permasalahan. Hanya saja dengan terjadinya perubahan baru, maka kita harus siap untuk keterampilan baru.


Refference :
http://oracle-help.com
http://www.zdnet.com
https://community.oracle.com

MKRdezign

Contact Form

Name

Email *

Message *

Powered by Blogger.
Javascript DisablePlease Enable Javascript To See All Widget