DATABASE ADMINISTRATION

Pertemuan ke-2: Memilih dan menginstall DBMS

Memilih dan Menginstal DBMS

Memilih dan Menginstall DBMS salah satu tugas DBA

Asumsi : DBMS sudah terinstall pekerjaan terselesaikan

Memilih dan Menginstall DBMS membutuhkan keahlian, pengetahuan, dan pertimbangan.

Mendefinisikan strategi dari Organisasi DBMS

Proses memilih DBMS yang cocok tidak sesulit dulu.

Banyak organisasi besar dan menengah yang menginstall lebih dari satu DBMS.

Siapa yang memilih dan menginstal semua DBMS itu ? dan mengapa?

Banyak perusahaan membeli DBMS tanpa memiliki planning.

Perusahaan membeli DBMS kebutuhan bisnis atau aplikasi baru.

Perusahaan membeli DBMS baru keinginan untuk mendukung teknologi terbaru dan terbesar.

Perusahaan membeli DBMS tanpa evaluasi aplikasi kompatible dengan DBMS yang ada

Mendefinisikan strategi dari Organisasi DBMS

Masalah :

Apliasi yang ada apakah kompatible dengan DBMS yang baru

Perlu perubahan kode aplikasi DBMS yang lama di maintenance,

double job

Solusi DBA menjadi pertimbangan utama pemilihan DBMS Unit usaha Membeli DBMS approval dari DBAFakta Grup DBA = teknis kalah suara dari bisnis eksekutif

lain

Mendefinisikan strategi dari Organisasi DBMS

Grup DBA aturan DBMS perusahaan Aturan DBMS mengurangi jumlah DBMS

perusahaan Multiple DBMS di perusahaan tentukan DBMS

default

Memilih DBMS

Memilih DBMS

Sistem operasi Jenis organisasi ( Konservatif atau Liberal ? ) Tingkatan yang dicapai (Benchmarks) Skalabilitas. Ketersediaan perangkat lunak pendukung. Teknisi. Biaya Kepemilikan. Jadwal Release Referensi pelanggan.

Sistem operasi

Apakah DBMS yang dipilih support OS yang digunakan di perusahaan

Atau OS menyesuaikan DBMS yang akan digunakan

Type of organization

Organsiasi konservatif vs liberal Org konservatif kekuasaan yang ketat Org konservatif lingkungan mainframe tradisional Org konservatif pemerintahan, keuangan,

asuransi, kesehatan dll Org liberal mempertimbangkan alternatif

manufaktur, universitas, dll Contoh beberapa org liberal windows bukan OS

utama menggunakan DBMS multi OS

Benchmarks Benchmarks oleh vendor dan pengguna DBMS The Transaction Processing Performance Council

(TPC) mengeluarkan benchmark untuk pedoman dasar penglahan DB

Benchmark untuk indikator kinerja DB bukan penentu utama pemilihan DBMS

Benchmark tidak mewakili implementasi DBMS pada semua database produksi

Benchmark harus terus diperbaharui, mengingat setiap DBMS terus berkembang

Scalability

DBMS harus mendukung jumlah pengguna dan ukuran DB

DBMS apakah ada konfirmasi dari pengguna independen

Availability of supporting software tools

DBMS harus support tools data, antara lain :› Query dan tools analisa› Tools pendukung data warehouse› Tolls pendukung DB› Tools backup dan recovery› Tools monitoring kinerja› Tool planing kapasitas› DB utilitas› Dukungan berbagai Bahasa pemrograman

Technicians

Ada profesional DB di perusahaan Pertimbangan kebutuhan DBA, bantuan

teknis (sistem prog, administrator, dll) Adanya Programmer aplikasi

Cost of Ownership

Total biaya DBMS Tiap vendor variasi harga Total biaya kepemilikan :

› Biaya lisensi› Biaya lisensi software pendukung› Biaya profesional DB untuk support dan pengelolaan

DBMS baru› Biaya resource untuk pengoperasioan DBMS baru

Release schedule

Release vendor beragam Org liberal butuh fitur terkini rilis cepat lebih

baik Org konservatif perubahan cepat = bencana Perubahan cepat org konservatif upgrade >

yang dibutuhkan vs menggunakan DBMS usang

Reference customers

DBMS vendor referensi pengguna Vendor respon baik ? Temukan forum / user lain jawaban lebih

objektif Kualitas rilis baru maksimal ?

Memilih DBMS baru hitung komplektifitas produk

adanya fungsi didukung vendor dan third party Programmer dan pengembang menggunakan

yang disediakan DBA Rencana dan persiapan lebih baik daripada

implementasi semua fitur secara membabibuta

Memilih DBMS

DBMS dirancang untuk pengguna yang unik DBMS DBMS enterprise, DBMS department, DBMS

personal, DBMS mobile pilih yang sesuai Proyek yang kompleks beberapa tipe DBMS Kebutuhan dukungan DBMS pilih di tingkat yang

sama Contoh : untuk pengguna ORACLE, gunakan ORACLE

personal untuk client tunggal

Arsitektur DBMS

Arsitektur DBMS Enterprise DBMS skalabilitas dan kinerja

tinggi. Depertemental DBMS kelompok kerja kecil-

menengah dalam sebuah organisasi;. Personal DBMS pengguna tunggal, Contoh.

Microsoft Access dan Visual dBase. Mobile DBMS versi khusus dari DBMS

departemenal atau Enterprise. DBMS mobile database lokal akses dan

modifikasi pada laptop atau perangkat genggam.

Enterprise DBMS

Enterprise DBMS skalabilitas dan kinerja tinggi Enterprise DBMS mendukung DB yang besar,

user banyak, multi aplikasi Enterprise DBMS mesin skala besar

(mainframe, server) Dukungan multiprosesor untuk multiprocessing,

paralel query, dll

Departmental DBMS

departmental DBMS DBMS workgroup jalan tengah

Mendukung kelompok kecil dan menengah Berjalan di UNIX, LINUX, Windows server Susah dibedakan dengan DBMS enterprise

hardware dan software hampir mirip Dengan harga hardware dan software yang terus

menurun pengguna department DBMS beralih ke DBMS enterprise

Personal DBMS

Dirancang untuk pengguna tunggal Contoh ms Access, dBase Vendor membuat versi personal dari DBMS

enterprise Biaya murah adanya penggunaan DBMS

personal untuk solusi department dan perusahaan (failed)

Personal DBMS hanya untuk skala kecil, tidak untuk multiuser

Mobile DBMS

Versi khusus dari DBMS department dan enterprise

Digunakan untuk remote, dan tidak terhubung jaringan

Dapat digunakan pada laptop dan telepon genggam

Ada sinkronisasi dengan DBMS enterprise / department di server utama

DBMS Clustering

Clustering beberapa sistem komputansi kerjasama dalam satu sistem

Meningkatkan skalabilitas dan availabilitas Arsitektur clustering :

› Shared disk› Shared nothing

Tiap sistem sumber daya sendiri (storage sendiri) Komunikasi antar sistem jaringan interkoneksi antar

komputer Permintaan dari klient diarahkan ke sistem yang

available Keuntungan skalabilitas

Share nothing

Semua sistem terhubung perangkat disk yang sama Setiap sistem memiliki CPU dan memori masing-

masing, tapi mengakses semua disk Cocok untuk pengolahan di perusahaan besar atau

mainframe Tidak cocok untuk small system

Share disc

DBMS Installation

DBMS dipilih diinstall DBMS bagian kompleks dari software ada

syarat dan lingkungan pendukung Yang harus dipahami di awal adalah syarat

instalasi

Kebutuhan hardware

Tiap DBMS kebutuhan dasar CPU Tiap DBMS menyertakan kebutuhan

hardware dan lingungan pendukung Tiap DBMS ada ciri khas untuk masing-

masing kebutuhan Hardware org menyesuaikan DBMS vs DBMS

menyesuaikan harware

Kebutuhan penyimpanan

Setiap DBMS membutuhkan disk storage untuk berjalan Setiap disk storage akan digunakan untuk indexes kebutuhan dari

DBMS dan database Index yang dimaksud antara lain :

Kebutuhan penyimpanan

Sistem katalog atau data Dictionary. Setiap sistem database lainnya yang dibutuhkan oleh DBMS Log file yang mencatat semua perubahan Startup atau kontrol file. Works file yang digunakan oleh DBMS untuk mengurutkan data dll Default database yang digunakan oleh DBMS untuk struktur sistem Temporary database structures System dump dan error processing files. Database yang digunakan untuk administrasi, pemantauan, dan

tuning

logs

Kebutuhan memory

Sebuah DBMS memerlukan memori untuk fungsionalitas dasar dan akan menggunakannya untuk proses yang paling internal seperti memelihara sistem area global dan banyak melakukan tugas.

beberapa pertimbangan lain

Versi atau Release ?

Vendor biasanya membuat perbedaan antara versi dan rilis dari produk perangkat lunak.

Sebuah versi baru dari perangkat lunak merupakan masalah besar, dengan banyak perubahan dan fitur baru.

rilis adalah versi dalam skala kecil kecil, dengan perubahan sedikit dan tidak banyak fitur baru.

Ada keuntungan dan resiko penerapan

Fitur dan Kompleksitas

fitur kompleks perubahan jalur akan mempengaruhi kinerja

client/server dan jaringan menambah komplektifitas DBMS

Integrasi dengan software dan infrastruktur lani mempersulit migrasi

bahasa pemrograman, cara embed query, perubahan API dll mempengaruhi komplektifitas DBMS

Hal lain yang perlu dipertimbangkan

Reputasi dari Vendor DBMS Dukungan Kebijakan dari DBMS Gaya Organisasi Skill Staf DBA Platform Support Perangkat Lunak Pendukung Fallback Planning

Database Standards and Procedures

Konvensi Penamaan Database

Perlu penamaan yang standar Dikembangkan bersama administrasi data Publikasi penamaan ke seluruh lingkungan organisasi Mencakup : tabel, kolom, view, indeks, program, tipe

user-defined data, fungsi user-defined, trigger, dan store prosedure

Standar Data Administration

Kebijkan organiasi terkait data Pedoman kepemilikan data Metadata kebijakan manajemen Pedoman konseptual dan logical pemodelan data Tanggung jawab menciptakan dan memelihara data Pedoman penggunaan tools Kebijakan terkait sharing data Pedoman perubahan data

Standar Database Administration

instalasi dan prosedur pengujian Upgrade kebijakan dan prosedur Bug memperbaiki bug dan praktek-praktek

pemeliharaan Membuat Sebuah daftar untuk memberitahukan

perubahan yang akan datang Pertimbangan disain Antarmuka penyimpanan, penggunaan, dan pemantauan

prosedur

Jika ada fungsi SA dalam organisasi Standard SA sama dibutuhkan seperti standar

DA dan DBA, mencakup› DBMS installation and testing procedures › Upgrade policies and procedures › Bug fix and maintenance practices › A checklist of departments to notify for impending

changes › Interface considerations › DBMS storage, usage, and monitoring procedures

System Administration Standards

Standar Pengembangan Aplikasi

Penjelasan tentang bagaimana mengakses database yang berbeda

Standar Coding dengan SQL Tips dan triks kinerja SQL Penyusunan prosedur dan bimbingan tentang bagaimana

menanamkan SQL dalam program aplikasi Interpretasi dari SQL STATE dan kode kesalahan Referensi materi pemrograman lainnya

Standart Keamanan Database

Menentukan siapa yang berwenang Daftar pemberian otorisasi database. Informasi pada setiap interface yang digunakan. Kebijakan penggunaan klausa WITH GRANT OPTION

dan CASCADING. Prosedur pemberitahuan kepada User. Prosedur menghapus user

Unit testing— for developing and testing individual programs

Integration testing— for testing how individual programs interoperate

User acceptance testing— for end user testing prior to production status

Quality assurance— for shaking out program bugs Education— for training end users how to work the

application system

Application Migration and Turnover Procedures

Yang harus dilakukan Organisasi

Harus berkomitmen untuk terus-menerus memberikan pendidikan teknis untuk DBA, programer, dan administrator sistem. Menyediakan katalog program yang tersedia mencakup semua aspek penggunaan DBMS.

Minimal, kursus berikut harus disediakan: dasar-dasar DBMS Pemodelan Data dan Desain Database Database Administrasi Pengantar SQL Advanced SQL Pemrograman Database

Kesimpulan

Perencanaan komprehensif diperlukan untuk menciptakan lingkungan database yang efektif.

Langkah langkah yang harus diambil untuk memilih teknologi DBMS yang benar, menerapkan strategi yang tepat, upgrade dan mengembangkan standar database yang berguna

menjamin ketersediaan pendidikan berkelanjutan bagi pengguna database.

Terima kasih