Tujuh Kebiasaan Mematikan dari DBA dan Cara Menyembuhkan Mereka

Menyebut kebiasaan buruk yang tersebar luas dalam administrasi basis data "mematikan" mungkin tampak
ekstrem. Namun, ketika Anda mempertimbangkan sifat kritis dari sebagian besar data, dan betapa
merusaknya kehilangan data atau korupsi dapat terjadi pada perusahaan, "mematikan" tampaknya cukup mematikan
.

Meskipun kebiasaan ini sangat umum di antara DBA, mereka dapat disembuhkan dengan
beberapa intervensi manajemen yang cerdas. Berikut ini adalah daftar tujuh kebiasaan yang kami
anggap paling mematikan, bersama dengan beberapa ide tentang cara menghilangkannya.

Kebiasaan # 1. Lompatan Iman: "Kami memiliki keyakinan pada cadangan kami."

Iman buta bisa sangat menawan, tetapi tidak ketika itu membuat cadangan database. Cadangan
harus dipercaya hanya sejauh telah diuji dan diverifikasi.

Obat:

Pastikan DBA Anda memverifikasi bahwa cadangan berhasil secara teratur, sebaiknya menggunakan
skrip yang memberi tahu mereka jika ada masalah.
Pertahankan cadangan ke cadangan Anda. DBA harus selalu menggunakan setidaknya dua
metode cadangan . Teknik yang umum adalah menggunakan ekspor kuno itu sebagai cadangan
ke cadangan online.
Uji sumber daya pulih sesering praktis. Tanda awal bahwa tim DBA Anda
terlalu banyak bekerja atau tidak memprioritaskan dengan benar adalah seperempat berlalu tanpa
pemulihan tes. Uji pemulihan memastikan bahwa strategi cadangan Anda berada di jalurnya, sementara
memungkinkan tim Anda untuk mempraktikkan kegiatan pemulihan sehingga mereka dapat menanganinya secara efektif
ketika saatnya tiba.

Kebiasaan # 2. HARAPAN HEBAT: "Ini akan bekerja seperti yang kita harapkan. Mari kita lanjutkan
."

Meskipun tidak ramah pengguna dalam arti tradisional, Oracle sangat
ramah pengguna daya - setelah Anda bekerja dengannya untuk sementara waktu, Anda mengembangkan naluri untuk
hal-hal yang "harus" bekerja. Meskipun naluri itu sering benar, salah satu
kebiasaan paling berbahaya yang dimiliki DBA adalah asumsi bahwa Oracle akan "bekerja"
seperti seharusnya.

Obat:

Menanamkan mentalitas "latihan, latihan, latihan" di seluruh organisasi. DBA
perlu berlatih kegiatan di kotak pasir yang aman dari lingkungan pengujian yang dirancang
untuk meniru perilaku sistem produksi. Organisasi perlu
memberikan waktu dan uang bagi mereka untuk melakukannya.
Pasangkan DBA yang tidak berpengalaman dengan yang senior jika memungkinkan - atau bawa mereka di bawah
sayap Anda sendiri. DBA baru cenderung tanpa rasa takut, tetapi belajar dari pengalaman orang lain
dapat membantu menanamkan beberapa paranoia yang sangat dibutuhkan.
Tinjau rencana untuk semuanya. Sungguh menakjubkan betapa sering DBA mengatakan, "Saya sudah melakukan itu
seratus kali, saya tidak perlu rencana." Jika mereka menuju ke mode eksekusi, mereka
benar - benar membutuhkan rencana.

Kebiasaan # 3. LAISSEZ-FAIRE ADMINISTRATION: "Kami tidak perlu memonitor sistem.
Para pengguna selalu memberi tahu kami ketika ada sesuatu yang salah."

Jika Anda bergantung pada pengguna untuk memberi tahu tim DBA bahwa ada masalah, mungkin
sudah terlambat.

Obat:

Instal ketersediaan dan sistem pemantauan kinerja sehingga masalah diidentifikasi
dan diselesaikan sebelum menyebabkan kegagalan yang berdampak pada layanan.
Hindari masalah perangkat lunak pasca rilis dengan bekerja sama dengan pengembang dan penguji untuk
memastikan bahwa semua perangkat lunak siap produksi stabil dan berkinerja tinggi.

Kebiasaan # 4. UJI MEMORI: "Kita akan ingat bagaimana ini terjadi, dan apa yang kita lakukan
untuk membuat semuanya berjalan lagi."

Mungkin tampak mustahil bahwa tim DBA akan melupakan prosedur besar yang membutuhkan waktu
berminggu-minggu untuk memperbaikinya, namun itu selalu terjadi. Untuk mencegah
kesalahan berulang dan memanfaatkan pengalaman yang didapat, dokumentasi sangat
penting.

Obat:

Mengharuskan DBA Anda mengelola perpustakaan dokumentasi dan
aktivitas harian yang komprehensif , termasuk tingkat dasar pemikiran, sintaksis, dan alur kerja yang signifikan.
Berikan timware groupware Anda di intranet Anda sehingga dokumen-dokumen ini
dapat dicari dalam keadaan darurat.
Menegakkan disiplin dokumentasi dan memeriksanya secara berkala. Tanyakan DBA Anda:
Kapan tablespace ini dibuat, oleh siapa, dan dengan apa SQL? Tugas apa yang
dilakukan pada hari tertentu? Jika mereka tidak dapat menjawab dengan cepat, Anda akan tahu mereka
kembali mengandalkan ingatan.

Kebiasaan # 5. THE BLAME GAME: "Jangan lihat aku, itu kesalahan pengembang bahwa SQL sedang
dalam produksi"

Beberapa DBA memiliki mentalitas "kami versus mereka" yang nyata ketika datang ke pengembang di
organisasi mereka. Mereka melihat diri mereka bukan sebagai fasilitator yang membantu pengembang
mengembangkan kode kualitas dari sudut pandang basis data, tetapi sebagai penjaga yang
mencegah kode berkualitas buruk dari membuatnya menjadi produksi. Ini mungkin tampak seperti
semantik, tetapi hubungan konfrontatif antara pengembang dan DBA menghasilkan
kurangnya inisiatif pengembang dan perlambatan signifikan dalam siklus rilis.

Obat:

Pilih DBA yang memahami bahwa adalah tanggung jawab mereka untuk bekerja sebagai tim terintegrasi
dengan pengembang yang mereka dukung.
Kembangkan sikap tim dengan menyusun keterlibatan DBA berkelanjutan dalam setiap proyek
dan bukan pada tonggak peninjauan.
Pertimbangkan untuk menetapkan DBA individu dalam peran dukungan pengembang. Jika itu jelas dalam
deskripsi pekerjaan, ada lebih banyak motivasi untuk melakukannya dengan baik.

Kebiasaan # 6. THE SOLO ACT: "Saya tahu apa yang saya lakukan dan tidak butuh bantuan."

Administrasi basis data semakin kompleks dan bahkan DBA paling senior
tidak mungkin mengetahui setiap detail terakhir. DBA memiliki spesialisasi yang berbeda, yang perlu
disingkirkan dan dimanfaatkan. Ketika DBA merasa mereka tahu, atau harus tahu, segalanya,
mereka tidak mengajukan pertanyaan dan kehilangan pengetahuan berharga yang bisa mereka peroleh
dari orang lain.

Obat:

Menumbuhkan budaya kerja tim di mana DBA mengakui bahwa mereka tidak tahu
jawabannya dan meminta bantuan.
Dorong DBA Anda untuk mencari peer group di luar sebagai forum untuk
bertukar pikiran dan menguji asumsi mereka. Tidak seorang pun dapat menyaingi
keahlian dan pengalaman bahkan kelompok yang relatif kecil.
Berikan jaring pengaman sumber daya teknologi seperti bahan referensi, kursus, dan
pakar atau konsultan luar sesuai permintaan.

Kebiasaan # 7. TECHNO-LUST: "Segalanya akan bekerja jauh lebih baik kalau saja kita punya ..."

DBA sering di atas teknologi terbaru, yang dapat membantu mereka melakukan
pekerjaan yang superlatif. Tetapi ketika keinginan untuk teknologi baru menyebabkan DBA merekomendasikan
pembelian perangkat keras atau tambahan perangkat lunak yang tidak perlu, biaya cenderung meroket
dengan cepat - seperti halnya masalah.

Obat:

Never upgrade your hardware infrastructure without first exhausting all tuning
opportunities. Remember, ten years ago enormous enterprises were run on servers
one-tenth the capacity--all thanks to necessity and skill.
Never consent to using advanced or new features until you're well aware of the
ongoing maintenance commitment and resulting costs.
Watch out for DBA support software that presents friendly GUI interfaces for difficult
tasks. This type of interface allows a beginner DBA to act as an intermediate DBA
under certain circumstances, but simultaneously prevents that beginner from
learning the actual skills behind the tasks. Moreover, these tools tend to hide real
risiko dari DBA, membuat kegiatan yang berpotensi merusak semudah point-and-
klik.

Apakah itu membutuhkan program dua belas langkah atau satu penyesuaian kecil, semua
kebiasaan DBA yang mematikan ini dapat ditendang. Tentu saja, langkah pertama adalah mengenali masalahnya. Dengan
memulai dengan daftar ini dan melakukan inventarisasi yang cermat atas keberhasilan dan kegagalan dalam
administrasi basis data tim Anda, Anda akan berada di jalur yang tepat untuk menemukan obatnya.