BAB 2 LANDASAN TEORI

BAB 2 LANDASAN TEORI

2.1

Teori – Teori Umum 2.1.1

Analisis Menurut Hoffer-George-Valacich (1999, p28), analisis adalah proses

mempelajari cara kerja perusahaan saat ini dan sistem informasi yang digunakan untuk melakukan tugas-tugas perusahaan. Analisis terdiri dari beberapa fase. Yang pertama adalah menentukan persyaratan. Pada bagian ini, analis bekerja dengan pengguna untuk menentukan atau mencari tahu apa yang pengguna inginkan dari sistem yang diusulkan. Biasanya dilakukan sebuah pembelajaran yang hati-hati dari berbagai sistem yang ada baik secara manual maupun secara komputerisasi, yang mungkin dapat diganti atau dikembangkan sebagai bagian dari proyek ini. Kedua, persyaratan tersebut dipelajari dan dibuat strukturnya berdasarkan relasi yang ada dan menghapus atau membuang semua pengulangan. Ketiga, membuat alternatif desain awal untuk dicocokkan dengan persyaratan di atas. Kemudian dilakukan proses perbandingan antara alternatif-alternatif tersebut untuk mencari alternatif mana yang paling baik yang memenuhi persyaratan termasuk biaya, tenaga kerja, tingkatan teknis yang perusahaan ingin lakukan pada proses pengembangan. Hasil dari analisis adalah uraian dari solusi alternatif yang direkomendasikan oleh tim analis. Setelah rekomendasi tersebut diterima, proses perencanaan dapat segera dimulai untuk memperoleh perangkat keras dan sistem perangkat lunak yang dibutuhkan untuk membangun atau mengoperasikan sistem seperti yang diusulkan. 7

8 2.1.2

Proses Bisnis Menurut Whitten, Bentley, dan Dittman (2004, p27), proses bisnis adalah

aktivitas-aktivitas yang menanggapi kegiatan-kegiatan bisnis. Proses bisnis adalah pekerjaan, prosedur, dan aturan yang dibutuhkan untuk menyelesaikan kegiatan bisnis.

2.1.3

Prototipe Menurut Connolly-Begg (2005, p304), prototipe adalah sebuah contoh

model dari aplikasi database yang dapat bekerja, namun keseluruhan fungsi-fungsi yang ada belum bekerja secara normal, dan belum memenuhi semua fungsionalitas dari sistem akhir. Menurut O’Brien (2003, p711), prototipe adalah model untuk bekerja dari sebuah sistem informasi yang meliputi versi sementara dari input atau output pemakai, database, file, metode pengendalian, dan rutinitas pemrosesan.

2.1.4

Teknologi Informasi Menurut Turban (2001, p3), teknologi informasi adalah komponen-

komponen individual yang secara khusus diatur ke dalam sistem informasi berbasiskan komputer. Menurut O’Brien (2003, p704), teknologi informasi adalah perangkat keras, perangkat lunak, telekomunikasi, manajemen database, dan teknologi pemrosesan informasi lainnya yang digunakan dalam sistem informasi berbasis komputer.

9 2.1.5

Data dan Informasi

2.1.5.1

Pengertian Data Menurut Hoffer (2005, p5), data adalah representasi dari objek dan

kejadian-kejadian yang disimpan dan mempunyai arti dan kepentingan dalam lingkungan pengguna. Menurut O’Brien (2003, p13), data merupakan fakta atau observasi mengenai fenomena fisikal atau transaksi bisnis. Menurut Whitten-Bentley-Dittman (2004, p27), data adalah fakta-fakta mentah mengenai orang, tempat, kejadian, dan hal-hal yang menyangkut kepentingan perusahaan. Masing-masing fakta tersebut secara relatif tidak berarti.

2.1.5.2

Pengertian Informasi Menurut Hoffer (2005, p5), informasi adalah data yang telah diproses

dengan cara tertentu untuk meningkatkan pengetahuan yang dimiliki oleh orang yang menggunakan data tersebut. Menurut O’Brien (2003, p703), informasi adalah data yang ditempatkan dalam konteks yang berarti dan berguna untuk pemakai akhir. Menurut Whitten-Bentley-Dittman (2004, p27), informasi adalah data yang telah diproses atau diatur ulang menjadi bentuk yang lebih berarti bagi suatu pihak. Informasi disusun dari kombinasi data yang mempunyai arti penting bagi penerimanya.

2.1.6

Sistem Menurut O’Brien (2003, p712), Sistem adalah :

1. Sekelompok elemen yang saling berhubungan dan membentuk kesatuan.

10 2. Sekelompok komponen yang bekerja sama menuju tujuan yang bersama dengan menerima input serta menghasilkan output dalam proses transformasi yang teratur. 3. Perkaitan metode, prosedur, atau teknik yang disatukan oleh interaksi teregulasi untuk membentuk kesatuan organisasi. 4. Sekumpulan orang, mesin, dan metode yang teratur dan yang dibutuhkan untuk menyelesaikan serangkaian fungsi tertentu.

2.1.7

Teori Jaringan

2.1.7.1

Bandwidth Menurut Anttalainen (2003, p81), informasi yang dipancarkan melalui

suatu jaringan telekomunikasi, apakah itu digital atau analog, berada dalam wujud arus atau voltase elektrik. Nilai dari arus atau voltase ini berubah sepanjang waktu, dan perubahan ini berisi informasi. Sinyal yang dipancarkan (perubahan arus atau voltase) terdiri dari berbagai frekuensi. Cakupan frekuensi itu disebut bandwidth dari sinyal. Bandwidth adalah salah satu satu karakteristik utama dari informasi analog dan juga faktor pembatasan yang paling utama untuk tingkat pengiriman data dari informasi digital.

2.1.7.2

Leased Line Menurut Anttalainen (2003, p280), suatu perusahaan yang terdiri dari

berbagai kantor di dalam suatu area, pada umumnya memerlukan akses informasi antar lokasi. Karena tujuan ini operator jaringan publik menyewa kabel atau optical fiber untuk koneksi antar kantor (biasa disebut leased-line).

11 Ini adalah cara yang yang paling hemat untuk saling berhubungan antar LAN ketika jarak hanya beberapa kilometer. Untuk koneksi jarak jauh, tidak mungkin secara ekonomis membangun koneksi fisik untuk masing-masing customer. Ini akan memerlukan repeater dan pasangan kabel atau fiber sepanjang negeri itu. Sebagai gantinya, kapasitas transmisi end-to-end yang diperlukan disewa dari jaringan inti dari operator jaringan interlokal. Untuk koneksi interlokal (jarak jauh), operator menggunakan sistem transmisi optikal dengan kapasitas tinggi yang digunakan untuk interkoneksi pertukaran publik di dalam jaringan.

 

Gambar 2.1 Leased-line lokal dan jarak jauh

12 2.1.8

Client – Server

2.1.8.1 Client Menurut Hoffer (2005, p60) client adalah sebuah komputer desktop atau laptop yang berkonsentrasi pada pengaturan hubungan antara pengguna dengan sistem dan data yang bersifat lokal. Menurut O’Brien (2003, p693), client adalah : 1.

Pemakai akhir.

2.

Mikrokomputer berjaringan dari pemakai akhir dalam jaringan client atau server.

3.

Versi paket perangkat lunak yang didesain untuk menjalankan mikrokomputer berjaringan dari pemakai akhir, seperti client browser web, client groupware, dan lain-lain.

2.1.8.2 Server Menurut O’Brien (2003, p713), server adalah : 1.

Komputer yang mendukung aplikasi dan telekomunikasi dalam jaringan, serta pembagian peralatan peripheral, perangkat lunak, dan database diantara berbagai terminal kerja dalam jaringan

2.

Versi perangkat lunak untuk pemasangan server jaringan yang didesain untuk mengendalikan dan mendukung aplikasi pada mikrokomputer client dalam jaringan client atau server, contohnya meliputi sistem operasi jaringan multi-user dan perangkat lunak khusus untuk menjalankan internet, intranet, dan aplikasi web ekstranet seperti e-commerce dan kerja sama perusahaan.

13 2.1.8.3 Arsitektur Three-Tier Client-Server Arsitektur Three-Tier Client-Server terdiri dari : •

Lapisan antarmuka user (user interface layer), yang berjalan pada komputer client.

•

Lapisan business logic dan data processing yang berjalan pada sebuah server yang disebut server aplikasi.

•

Lapisan DBMS yang menyimpan data yang dibutuhkan oleh server aplikasi. Lapisan ini dapat berjalan pada server terpisah yang disebut database server. Client hanya bertanggung jawab terhadap antarmuka user dari aplikasi

dan mungkin melakukan beberapa proses logika yang sederhana, seperti validasi masukan. Pusat business logic dari aplikasi berada pada server aplikasi, secara fisik terhubung dengan client dan database server dalam local area network (LAN) atau wide area network (WAN). Satu server aplikasi didesain untuk melayani banyak client. Desain three-tier mempunyai keuntungan antara lain : • Kebutuhan perangkat keras yang lebih murah karena client hanya untuk antarmuka. • Pemeliharaan aplikasi terpusat dengan pengiriman business logic untuk banyak pemakai akhir ke dalam server aplikasi tunggal. Arsitektur ini tidak perlu mendistribusikan perangkat lunak. • Modularitas tambahan membuat lebih mudah untuk memodifikasi atau mengganti satu tier tanpa mempengaruhi tier lain.

14 • Load balancing menjadi lebih mudah dengan pemisahan pusat business logic dari fungsi database.

Gambar 2.2 Arsitektur Three-Tier Client-Server

2.1.9 Database 2.1.9.1

Pengertian Database Menurut Connolly-Begg (2005, p15), database adalah kumpulan data

yang saling berhubungan secara logika dan dirancang untuk memenuhi kebutuhan informasi organisasi. Menurut O’Brien (2003, p696), database adalah kumpulan terpadu dari elemen data logis yang saling berhubungan.

15 2.1.9.2

Database Management System (DBMS)

2.1.9.2.1

Pengertian DBMS

Menurut Connolly-Begg (2005, p16), DBMS adalah sistem perangkat lunak yang memungkinkan pengguna untuk mendefinisikan, membuat, memelihara, dan mengontrol akses ke database. DBMS adalah perangkat lunak yang berinteraksi dengan program aplikasi pengguna dan database. Sebuah DBMS harus menyediakan fasilitas sebagai berikut. •

Mampu mendefinisikan database, biasanya melalui Data Definition Language

(DDL).

DDL

memungkinkan

pengguna

untuk

menentukan tipe data, struktur, dan batasan terhadap data yang akan disimpan ke database. •

Memungkinkan pengguna untuk memasukkan (insert), merubah (update), menghapus (delete), dan mengambil (retrieve) data dari database, biasanya melalui Data Manipulation Language (DML). DML memungkinkan pengguna untuk melakukan query.

•

Menyediakan kendali akses ke database. Sebagai contoh DBMS dapat menyediakan : o Sistem keamanan yang memungkinkan untuk mencegah pengguna yang tidak berkepentingan untuk mengakses database. o Sistem integrasi yang menjaga konsistensi data yang tersimpan.

16 o Sistem kendali yang memungkinkan database untuk diakses secara bersamaan. o Sistem

pemulihan

yang

memungkinkan

untuk

mengembalikan keadaan database ke kondisi konsisten yang sebelumnya jika terjadi kesalahan, termasuk kesalahan perangkat keras dan perangkat lunak. o Sebuah katalog yang bisa diakses oleh pengguna yang di dalamnya terdapat deskripsi atau penjelasan dari data yang terdapat di dalam database.

2.1.9.2.2

Sistem Database Terpusat

Menurut

Silberschaz-Korth-Sudarshan

(2002,

p683),

sistem

database terpusat adalah sistem yang berjalan pada sistem komputer tunggal dan tidak berinteraksi dengan sistem komputer lain. Sistem database tersebut memiliki jangkauan dari sistem database pengguna tunggal pada komputer personal hingga sistem database high-performance pada sistem server mutakhir.

2.1.9.3 Arsitektur DBMS Oracle Menurut Best (2005, p1-8), DBMS Oracle adalah sistem manajemen database yang menyediakan pendekatan yang terbuka, komprehensif, dan terintegrasi terhadap manajemen informasi. DBMS Oracle terdiri dari Oracle instance dan Oracle database.

17 2.1.9.3.1

Oracle Instance

Menurut Abbey (1999, p108), Oracle instance adalah kumpulan proses pada server Oracle yang mempunyai System Global Area (SGA) sendiri dan kumpulan file database yang berhubungan dengan prosesproses tersebut. Menurut Cyran (2005, p1-13), setiap kali suatu database dimulai, suatu System Global Area (SGA) dialokasikan dan proses background Oracle dimulai. Kombinasi dari proses background dan buffer memori disebut Oracle instance. Memori dan proses dari suatu instance yang mengatur data database yang berhubungan secara efisien dan melayani satu atau beberapa pemakai dari database. Menurut Dawes (2005, p28), sebuah instance server Oracle tersusun atas struktur memori utama Oracle, yang disebut System Global Area (SGA) dan beberapa proses background Oracle. Proses server berkomunikasi dengan SGA pada saat user mengakses data dalam database. Komponen instance terdiri dari : •

System Global Area (SGA) System Global Area (SGA) adalah suatu daerah shared memori yang berisi data dan informasi kendali untuk satu Oracle instance. Oracle mengalokasikan SGA ketika suatu instance dimulai dan menghapus alokasi itu ketika kejadian berhenti. Masing-masing instance mempunyai SGA sendiri. Pemakai yang sedang terhubung ke database Oracle berbagi data di dalam SGA. Untuk performa optimal, keseluruhan SGA harus sebesar mungkin (selagi masih sesuai dengan memori nyata) untuk menyimpan sebanyak mungkin

18 data di dalam memori dan untuk meminimalkan I/O pada disk. Komponen utama SGA terdiri dari : -

Shared Pool: menampung perintah SQL yang baru saja dijalankan oleh pemakai database.

-

Database Buffer Cache: menampung data yang baru saja diakses oleh pemakai database.

-

Redo Log Buffer: menyimpan informasi transaksi untuk keperluan recovery.

•

Proses background Setiap proses background melakukan tugas khusus dalam mendukung pengaturan instance. Proses background yang utama adalah sebagai berikut : - System Monitor (SMON): melakukan recovery instance jika terjadi kegagalan instance, menggabungkan space kosong dalam database, dan mengatur space yang digunakan untuk sorting. - Process Monitor (PMON): menghapus koneksi database pemakai yang gagal. - Database Writer (DBWn): menulis blok database yang telah dimodifikasi dari Database Buffer Cache SGA ke data files pada disk. - Log Writer (LGWR): menulis informasi recovery transaksi dari redo log buffer SGA ke online redo log files pada disk.

19 - Checkpoint (CKPT): update database saat melakukan checkpoint.

2.1.9.3.2

Database Oracle

Menurut Cyran (2005, p1-1), Database Oracle adalah suatu koleksi data yang diperlakukan sebagai suatu unit. Tujuan suatu database adalah untuk menyimpan dan mendapat kembali informasi terkait. Suatu server database menjadi kunci untuk memecahkan permasalahan manajemen informasi. Secara umum, suatu server mengatur sejumlah besar data di dalam suatu lingkungan banyak pemakai sedemikian sehingga banyak pemakai dapat secara bersamaan mengakses data yang sama itu. Semua ini terpenuhi dengan performa yang tinggi. Suatu database server juga mencegah akses yang tidak diijinkan dan menyediakan solusi efisien untuk perbaikan kegagalan. Database ini mempunyai struktur logical dan struktur fisik. Karena struktur fisik dan logika terpisah, penyimpanan data secara fisik dapat diatur tanpa mempengaruhi akses ke struktur penyimpanan logika.

Struktur Fisik database Menurut Cyran (2005, p1-8), struktur fisik database dari database Oracle mencakup data file, redo log, dan control file. •

Data file Setiap database Oracle mempunyai satu atau lebih physical data file. Data file tersebut berisi semua data pada database. Data

20 dari struktur logika database, seperti indeks dan tabel, secara fisik disimpan di dalam data file yang dialokasikan untuk suatu database. Karakteristik data file adalah : o Suatu data file dapat dihubungkan hanya dengan satu database. o Data file dapat mempunyai karakteristik tertentu yang diatur agar data file dapat secara otomatis memperbesar space ketika database kekurangan space. o Satu atau lebih data file membentuk suatu unit logika dari penyimpanan database yang disebut tablespace. Data di dalam suatu data file dibaca, jika dibutuhkan, selama operasi database normal dan disimpan di memori cache Oracle. Sebagai contoh, asumsikan bahwa seorang pemakai ingin mengakses beberapa data di dalam suatu tabel suatu database. Jika informasi yang diminta tidaklah berada di dalam memori cache untuk database, maka data tersebut dibaca dari data file dan disimpan di dalam memori. Data baru atau data yang dimodifikasi tidak perlu langsung ditulis pada data file. Untuk mengurangi jumlah akses ke disk dan untuk meningkatkan performa, data disatukan di dalam memori dan semua data ditulis pada data file secara bersamaan.

21 •

Control File Setiap database Oracle mempunyai suatu control file. Control file berisi masukan yang menetapkan struktur fisik dari database. Sebagai contoh, control file berisi informasi berikut : o nama database, o nama dan lokasi data file dan redo log file, o waktu pembuatan database. Oracle dapat memperbanyak control file, yang secara bersama-sama menjaga sejumlah salinan control file yang identik, untuk melindungi dari suatu kegagalan yang menyertakan control file. Setiap kali suatu instance dari database Oracle dimulai, control file mengidentifikasi database dan redo log yang harus dibuka untuk operasi database sehingga database dapat berproses. Jika struktur fisik database diubah (sebagai contoh, jika suatu data file baru atau redo log dibuat), maka control file secara otomatis dimodifikasi oleh Oracle agar sesuai dengan perubahan itu. Suatu control file juga digunakan dalam recovery database.

•

Online Redo Log File Setiap database Oracle mempunyai satu set dari dua atau lebih redo log file. Set dari redo log file secara bersama dikenal

22 sebagai redo log untuk database. Suatu redo log dibuat berdasarkan redo entries (juga disebut redo records). Fungsi utama dari redo log adalah untuk merekam semua perubahan yang dibuat terhadap data. Jika suatu kegagalan membuat data yang telah dimodifikasi tidak dapat ditulis secara permanen pada data file, maka perubahan tersebut dapat diperoleh dari redo log, jadi perubahan data tersebut tidak pernah hilang. Untuk melindungi dari suatu kegagalan yang menyertakan redo log itu sendiri, Oracle mengijinkan suatu multiplexed redo log sedemikian sehingga dua atau lebih salinan dari redo log dapat dibuat pada disk yang berbeda. Informasi di dalam redo log file digunakan hanya untuk recover database dari suatu kegagalan media atau kegagalan sistem yang mencegah data ditulis pada data file. Sebagai contoh, jika suatu gangguan listrik yang menyebabkan operasi database terhenti, maka data di dalam memori tidak bisa ditulis pada data file, dan data hilang. Bagaimanapun, data yang hilang dapat di-recover ketika database dijalankan, setelah listrik diperbaiki. Dengan mengapply informasi pada redo log file yang paling baru pada data file database, Oracle mengembalikan database ke waktu di mana gangguan listrik terjadi. Proses menerapkan redo log selama suatu operasi recovery disebut rolling forward. Oracle dapat secara otomatis membuat arsip dari log file saat database dalam mode ARCHIVELOG.

23 •

Archived Log File Archived log file berisi history dari perubahan data (redo) yang dihasilkan oleh instance. Dengan menggunakan archived log file dan backup database, dapat dilakukan recover data yang hilang. Oracle dapat secara otomatis membuat archived log file saat database berada pada mode ARCHIVELOG.

•

Parameter File Parameter file berisi daftar parameter konfigurasi untuk database dan instance. Oracle merekomendasikan untuk membuat suatu server parameter file (SPFILE) sebagai cara dinamis untuk menjaga parameter inisialisasi. Suatu SPFILE mengijinkan penyimpanan dan pangaturan parameter inisialisasi secara terus menerus di dalam file pada disk di server.

•

Password File Password file memungkinkan pemakai dapat terhubung dari lokasi yang berbeda ke database dan melakukan tugas-tugas administratif.

•

Alert dan Trace File Setiap proses background dan server dapat menulis pada trace file yang berhubungan. Ketika suatu kesalahan internal

24 dideteksi oleh suatu proses, informasi tentang kesalahan tersebut ditulis kedalam trace file-nya. Beberapa informasi ditulis ke suatu trace file untuk database administrator, sedangkan informasi lain untuk Oracle Support Service. Informasi trace file juga digunakan untuk mengatur instance dan aplikasi. Alert file atau alert log, adalah suatu trace file khusus. Alert log dari suatu database adalah suatu catatan kronologis dari kesalahan dan pesan.

•

Backup File Untuk

mengembalikan

suatu

file

adalah

dengan

menggantikannya dengan suatu backup file. suatu file di-restore ketika kesalahan pemakai atau kegagalan media telah merusak atau menghapus file yang asli. User-managed backup and recovery memerlukan pemakai untuk mengembalikan backup file sebelum dapat melakukan percobaan recovery dari backup file. Servermanaged backup and recovery mengatur proses backup, seperti penjadwalan backup, dan juga proses recovery, seperti meng-apply backup file yang benar ketika recovery diperlukan.

Struktur Logika database Menurut Dawes (2005, p136), database Oracle 10g menyimpan objek skema – seperti tabel – secara logika dalam tablespace sementara secara fisik disimpan pada data file. Database Oracle terdiri dari dua atau lebih tablespace, dan setiap tablespace berada pada satu atau lebih data

25 file. Saat membuat sebuah tabel, dapat ditentukan pada tablespace mana tabel tersebut dimasukkan.   Menurut Cyran (2005, p1-10), struktur logika database, mencakup blok data, extent, dan segmen, memungkinkan Oracle untuk mempunyai kendali penggunaan disk space. •

Tablespace Suatu database dibagi menjadi unit penyimpanan logis yang disebut tablespace, yang mengelompokkan struktur logika yang berhubungan.

Sebagai

contoh,

tablespace

biasanya

mengelompokkan semua objek aplikasi menjadi satu untuk menyederhanakan beberapa operasi administratif. Setiap database secara logis dibagi menjadi satu atau lebih tablespace. Satu atau lebih data file secara eksplisit dibuat untuk masing-masing tablespace untuk secara fisik menyimpan data dari semua struktur logika di dalam suatu tablespace. Gabungan ukuran data file dalam suatu tablespace menjadi total kapasitas penyimpanan dari tablespace tersebut. Setiap database Oracle berisi suatu tablespace SYSTEM dan suatu tablespace SYSAUX. Oracle membuatnya secara otomatis ketika database dibuat. Sistem secara default akan membuat suatu tablespace dengan ukuran file yang kecil. Tablespace SISTEM dan SYSAUX dibuat seperti tablespace dengan ukuran file yang kecil.

26 Oracle juga mengijinkan pembuatan tablespace dengan ukuran file yang besar. Hal ini mengijinkan database Oracle untuk berisi tablespace yang dibuat dari file besar tunggal, bukan beberapa file yang lebih kecil. Hal ini mengijinkan database Oracle menggunakan kemampuan sistem 64-bit untuk menciptakan dan mengatur file dengan ukuran yang sangat besar. Konsekuensinya adalah database Oracle sekarang dapat meningkat sampai kepada 8 exabytes dalam ukuran. Dengan file yang diatur oleh Oracle, tablespace dengan ukuran file yang besar membuat data files transparan untuk para pemakai. Dengan kata lain, pemakai dapat melaksanakan operasi pada tablespace, bukan pada data file. Suatu tablespace dapat online (dapat diakses) atau offline (tidak dapat diakses). Suatu tablespace biasanya online, sehingga para pemakai dapat mengakses informasi di dalam tablespace tersebut. Bagaimanapun, kadang-kadang suatu tablespace dibuat offline untuk membuat sebagian dari database menjadi tak tersedia dan membiarkan akses normal kepada bagian database yang lain. Hal ini membuat banyak tugas administratif lebih mudah untuk dilaksanakan.

27

Gambar 2.3 Data file dan Tablespace

•

Oracle Data Blocks Oracle mengatur space penyimpanan di dalam data file suatu database dalam unit yang disebut blok data. Suatu blok data adalah unit data yang terkecil yang digunakan oleh suatu database. Secara fisik, pada level sistem operasi, semua data disimpan di dalam bytes. Masing-masing sistem operasi mempunyai suatu ukuran blok. Oracle meminta data di dalam berbagai blok data Oracle, bukan blok sistem operasi. Ukuran blok standar ditetapkan oleh parameter inisialisasi DB_BLOCK_SIZE. Ukuran blok data haruslah merupakan

28 beberapa ukuran blok sistem operasi di dalam batas yang maksimum untuk menghindari I/O yang tidak perlu. Blok data Oracle menjadi unit penyimpanan paling kecil yang dapat digunakan atau dialokasikan oleh Oracle.

•

Extent Extent adalah suatu unit logika dari alokasi space penyimpanan database terbuat dari sejumlah data blok yang berdekatan. Satu atau lebih extent pada gilirannya menyusun suatu segmen. Ketika space yang ada di suatu segmen telah digunakan seluruhnya, Oracle mengalokasikan suatu extent baru untuk segmen itu.

•

Segment Suatu segmen adalah satu set extent yang berisi semua data untuk suatu struktur penyimpanan logika spesifik di dalam suatu tablespace. Sebagai contoh, untuk masing-masing tabel, Oracle mengalokasikan satu atau lebih extent untuk membentuk segmen data

tabel,

dan

untuk

masing-masing

indeks,

Oracle

mengalokasikan satu atau lebih extent untuk membentuk segmen indeks.

29

Gambar 2.4 Data Block, Extent, dan Segment

2.1.9.4 Oracle Net Service Menurut Cyran (2005, p10-5), Oracle Net Service menyediakan solusi koneksi tingkat enterprise di dalam lingkungan komputasi terdistribusi dan heterogen. Oracle Net Service memungkinkan suatu session jaringan dari suatu aplikasi client kepada suatu database Oracle. Oracle Net Service menggunakan protokol komunikasi atau Application Programmatic Interfaces (APIs) yang didukung oleh suatu cakupan jaringan yang luas untuk menyediakan suatu database terdistribusi dan proses terdistribusi untuk Oracle.

30 •

Suatu protokol komunikasi adalah satu set aturan yang menentukan bagaimana aplikasi mengakses jaringan dan bagaimana data dibagi lagi ke dalam paket untuk transmisi melalui jaringan.

•

Suatu API adalah satu set subroutine yang menyediakan, dalam kasus jaringan, suatu sarana untuk membuat komunikasi antar proses yang berbeda lokasi melalui suatu protokol komunikasi. Setelah suatu session jaringan dibentuk, Oracle Net Service bertindak

sebagai kurir data untuk aplikasi client dan database server. Oracle Net Service bertanggung jawab untuk membuat dan memelihara koneksi antara database server dan aplikasi client, seperti halnya pertukaran pesan antara database server dan aplikasi client. Oracle Net Service dapat melakukan pekerjaan ini karena ditempatkan pada setiap komputer di dalam jaringan. Oracle Net Service menyediakan ketransparanan lokasi, konfigurasi dan manajemen terpusat, serta instalasi dan konfigurasi cepat. Oracle Net Service juga mengizinkan pemaksimalan sumber daya sistem dan peningkatan performa. Arsitektur shared server Oracle meningkatkan skalabilitas aplikasi dan banyaknya client yang secara bersamaan terhubung dengan database. Oracle Net Manager menyediakan graphical user interface (GUI) yang digunakan untuk melakukan konfigurasi Oracle Net Services untuk Oracle home pada client local atau server host. Oracle Net Manager akan mengubah isi dari file tnsnames.ora. Isi dan struktur dari file tnsnames.ora adalah : # tnsnames.ora Network Configuration File: D:\oracle\ora10g\NETWORK\ADMIN\tnsnames.ora # Generated by Oracle configuration tools. ORCL =

31 (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = tcp)(HOST = mweishandell)(PORT = 1521)) ) (CONNECT_DATA = (SERVICE_NAME = orcl) ) ) Parameter

Deskripsi

DESCRIPTION

Memulai bagian deskripsi koneksi dari file.

ADDRESS_LIST

Memulai daftar semua deskripsi informasi alamat dari koneksi.

ADDRESS

Deskripsi koneksi untuk net service name.

PROTOCOL

Protokol yang digunakan, misalnya TCP/IP.

HOST

Nama dari mesin dimana listener berjalan. IP address juga dapat ditetapkan dalam TCP/IP.

PORT

Lokasi listening dari listener ke TCP/IP.

CONNECT_DATA Memulai bagian service untuk service name ini. SERVICE_NAME

Menentukan hubungan ke service yang mana, yang dapat sama dengan ORACLE_SID atau nama database global. Tabel 2.1 Parameter tnsnames.ora

2.1.9.5 Listener Menurut Cyran (2005, p10-5), ketika suatu instance dimulai, suatu proses listener membuat suatu saluran komunikasi ke Oracle. Ketika sebuah proses pemakai membuat suatu permintaan koneksi, listener menentukan

32 apakah perlu menggunakan suatu proses shared server dispatcher atau suatu proses dedicated server dan menetapkan suatu koneksi yang sesuai. Listener juga menetapkan suatu saluran komunikasi antar database. Ketika beberapa instance atau database berjalan dalam satu komputer, nama service memungkinkan instance untuk register secara otomatis dengan listener lain pada komputer yang sama. Suatu nama service dapat mengidentifikasi beberapa instance, dan suatu instance dapat merupakan kepunyaan beberapa service. Client yang sedang berhubungan dengan suatu service tidak perlu menetapkan instance yang mana yang mereka perlukan.

2.1.9.6 Oracle Enterprise Manager (OEM) Menurut Abbey (1999, p21), Oracle Enterprise Manager (OEM) adalah sekumpulan alat untuk mengatur lingkungan Oracle secara keseluruhan, termasuk di dalamnya sistem, aplikasi, jaringan, dan database. Menurut CurtisKing (1998, p489), Oracle Enterprise Manager (OEM) merupakan sejumlah tools untuk mempermudah dan mengotomatisasi pengaturan database Oracle. Komponen-komponen yang terdapat dalam OEM adalah sebagai berikut. • OEM console OEM console adalah alat utama untuk mengatur database. OEM Console dapat memeriksa status objek jaringan, seperti node, listener, dan database. OEM console dapat menyalakan atau mematikan instance, melihat status dari pekerjaan yang sudah dijadwalkan, dan memeriksa kembali aktivitas dari kejadian yang sudah terdaftar.

33 • Oracle Administrator Toolbar Oracle Administrator Toolbar menyediakan akses cepat ke alat administrasi database yang sering digunakan. • Database Administration Tools Database

Administration Tools dapat melakukan aktivitas seperti

menyalakan atau mematikan Oracle instance, menambah tempat penyimpanan database, membuat tabel atau indeks, mengatur pengguna database, dan mengisi data ke database. • Oracle Intelligent Agent Oracle Intelligent Agent merupakan sebuah proses yang menjalankan pekerjaan database

dan laporan atas peristiwa sesuai dengan yang

diminta oleh OEM console.

2.2

Teori - Teori Khusus 2.2.1

Keamanan Database Menurut Connolly-Begg (2005, p542), keamanan database adalah

mekanisme-mekanisme yang melindungi database terhadap ancaman-ancaman yang disengaja maupun tidak disengaja. Pertimbangan keamanan tidak hanya berlaku untuk data yang ada di dalam database. Pelanggaran terhadap keamanan akan mempengaruhi bagian-bagian lain pada sistem, yang memberikan dampak pada database. Sebagai akibatnya, keamanan database meliputi perangkat keras, perangkat lunak, manusia, dan data. Untuk mengimplementasi keamanan membutuhkan kendali yang sesuai, yang ditentukan sesuai dengan sasaran untuk

34 sistem. Kebutuhan keamanan ini, walaupun sering diacuhkan sebelumnya, namun kini telah disadari oleh perusahaan-perusahaan. Alasannya adalah peningkatan jumlah data penting perusahaan yang disimpan pada komputer dan kehilangan data atau ketidaktersediaan data, dapat mendatangkan bencana bagi perusahaan. Sebuah database mewakili sebuah sumber penting perusahaan yang harus dijaga dengan menggunakan pengendalian yang tepat. Situasi-situasi yang berhubungan dengan keamanan database adalah sebagai berikut : -

Pencurian dan penipuan data

-

Kehilangan kerahasiaan data

-

Kehilangan privasi

-

Kehilangan integritas data

-

Kehilangan ketersediaan data Situasi-situasi

pertimbangan

tersebut

perusahaan

untuk

mewakili

lokasi-lokasi

meminimalisasi

resiko,

yang yang

menjadi menjadi

kemungkinan-kemungkinan terjadinya kehilangan atau kerusakan data. Pada beberapa situasi, suatu kejadian yang mengakibatkan kehilangan data di suatu lokasi, dapat juga mengakibatkan kehilangan data di lokasi lain Dari situasi-situasi di atas, yang akan dibahas di dalam skripsi ini adalah mengenai integritas data dan ketersediaan data. Kehilangan integritas data mengakibatkan ketidaktepatan dan kerusakan data, yang dapat berdampak serius pada seluruh kegiatan operasional perusahaan. Banyak perusahaan yang sekarang mencari kegiatan operasional yang berjalan terus menerus, atau yang disebut dengan istilah 24/7 (24 jam dalam sehari, 7 hari dalam seminggu). Kehilangan ketersediaan data berarti bahwa data, sistem, atau keduanya tidak dapat diakses,

35 yang dapat berdampak serius pada seluruh kegiatan operasional perusahaan, termasuk operasional keuangan perusahaan. Pada beberapa kasus, kejadian yang mengakibatkan sebuah sistem tidak dapat diakses dapat juga mengakibatkan kerusakan data. Tujuan dari keamanan database adalah meminimalisasi kehilangan yang disebabkan oleh kejadian-kejadian yang telah diperkirakan, dalam suatu metode optimalisasi biaya tanpa terlalu membatasi pengguna.

2.2.1.1 Backup Menurut Connolly-Begg (2005, p550), backup adalah proses pembuatan salinan database dan arsip secara berkala ke dalam suatu media penyimpanan. Sebuah DBMS harus menyediakan fasilitas backup untuk membantu recovery kerusakan database yang akan terjadi. Selalu disarankan untuk membuat salinan backup dari database dan log file pada interval yang tetap dan memastikan bahwa salinan tersebut ada di lokasi yang aman. Pada saat terjadi kerusakan yang menyebabkan database tidak dapat digunakan, salinan backup dan detilnya yang disimpan di dalam log file digunakan untuk mengembalikan database ke kondisi konsisten terakhir yang paling mungkin.

2.2.1.2 Recovery Menurut Connolly-Begg (2005, p605), recovery adalah proses mengembalikan database ke kondisi semula sebelum terjadi kegagalan pada database. Database recovery adalah sebuah service yang disediakan oleh DBMS untuk memastikan bahwa database dapat diandalkan dan tetap dalam kondisi yang konsisten pada saat terjadi kerusakan.

36 Jika kerusakan terjadi antara write ke buffer dan mengosongkan buffer ke secondary storage, recovery manager harus menentukan status dari transaksi yang melakukan write pada saat terjadi kerusakan. Jika transaksi telah melakukan commit, recovery manager harus melakukan kembali perubahan yang dilakukan oleh transaksi itu ke database (juga dikenal dengan roll-forward). Di sisi lain, jika transaksi belum di-commit pada saat terjadi kerusakan, recovery manager akan melakukan undo (rollback) perubahan apa saja yang dilakukan transaksi itu terhadap database. Sebuah DBMS harus menyediakan fasilitas berikut ini untuk mendukung recovery. •

Mekanisme backup, yang membuat salinan backup dari database secara periodik.

•

Fasilitas logging, yang mencatat status dari transaksi dan perubahan database.

•

Fasilitas checkpoint, yang memungkinkan perubahan pada database yang sedang berjalan dibuat permanen.

•

Recovery

manager,

yang

mengembalikan database

memperbolehkan

sistem

untuk

ke state yang konsisten setelah terjadi

kerusakan.

2.2.1.3 RAID (Redundant Array of Independent Disks) Menurut Connolly-Begg (2005, p552), RAID adalah sebuah teknologi yang menggunakan sejumlah besar susunan disk independen yang diorganisir

37 untuk meningkatkan kehandalan dan kinerja sistem. Kinerja ditingkatkan melalui data striping, yaitu data disegmentasi menjadi beberapa partisi yang sama besar (striping unit) yang secara transparan didistribusikan ke beberapa disk. Hal ini terlihat seperti sebuah disk tunggal yang besar dan cepat dimana sebenarnya data didistribusikan ke beberapa disk yang lebih kecil. Pembagian data meningkatkan performa input output secara keseluruhan melalui beberapa input output yang berjalan secara paralel. Pada waktu yang sama pembagian data juga menyeimbangkan kapasitas diantara disk-disk. Kehandalan ditingkatkan melalui penyimpanan informasi secara redundan melalui disk-disk yang menggunakan skema paritas atau sebuah skema pembetulan kesalahan seperti kode Reed-Solomon. Dalam sebuah skema paritas, masing-masing byte mempunyai sebuah bit paritas yang menyimpan apakah bit di dalam byte yang bernilai 1 berjumlah genap atau ganjil. Jika jumlah bit dalam byte rusak, paritas baru dari suatu byte akan menjadi tidak sesuai dengan paritas yang telah disimpan. Sama halnya apabila paritas yang disimpan rusak, tidak akan sesuai dengan data dalam byte tersebut. Skema pembetulan kesalahan menyimpan dua atau lebih bit tambahan, dan dapat menyusun kembali data asli jika sebuah bit rusak. Skema-skema ini dapat digunakan melalui pembagian byte antar disk. Ada beberapa pengaturan disk yang berbeda dengan menggunakan RAID, yang disebut tingkatan RAID. Macam-macam tingkatan RAID antara lain : •

RAID 0 – Non-redundant (tidak berulang). Tingkat ini menjaga agar tidak terjadi perulangan data dan juga memiliki performa penulisan

38 (write) karena data-data tidak perlu diduplikasi. Pembagian data dilakukan pada tingkatan blok. •

RAID 1 – Mirrored. Tingkat ini menjaga dua salinan data yang identik antar disk yang berbeda. Untuk menjaga konsistensi pada saat terjadi kerusakan disk, penulisan pada disk tidak boleh dijalankan secara bersamaan. Ini adalah solusi penyimpanan yang paling mahal.

•

RAID

0+1

–

Non-redundant

dan

Mirrored.

Tingkat

ini

menggabungkan antara pembagian data (striping) dengan duplikasi data (mirroring). •

RAID 2 – Memory-Style Error-Correcting Codes. Pada tingkat ini, unit pembagi adalah sebuah bit tunggal dan kode Hamming digunakan sebagai skema pengulangan.

•

RAID 3 – Bit-Interleaved Parity. Tingkat ini menyediakan perulangan dengan menyimpan informasi paritas dalam susunan array pada disk tunggal. Informasi paritas ini dapat digunakan untuk mengembalikan data pada disk lain ketika terjadi kegagalan. Tingkat ini menggunakan tempat penyimpanan yang lebih sedikit dibandingkan RAID 1 tetapi disk paritas dapat menjadi bottleneck.

•

RAID 4 – Block-Interleaved Parity. Pada tingkat ini, unit pembagi adalah sebuah blok disk – sebuah blok paritas yang berada pada disk yang terpisah untuk menghubungkan blok-blok dari sejumlah disk lain. Jika satu dari disk tersebut gagal / tidak berjalan, blok paritas dapat

39 digunakan dengan blok yang berhubungan dengan disk lain untuk mengembalikan blok dari disk yang gagal tersebut. •

RAID 5 - Block-Interleaved Distributed Parity. Tingkat ini menggunakan data paritas untuk perulangan melalui cara yang sama dengan RAID 3 namun membagi data paritas antara semua disk, sesuai dengan cara sumber data dibagi. Ini mengurangi bottleneck pada disk paritas.

•

RAID 6 – P+Q Redundancy. Tingkat ini mirip dengan RAID 5 tetapi data perulangan tambahan dijaga untuk melindungi dari kegagalan beberapa disk. Kode pembetulan kesalahan digunakan juga disamping penggunaan paritas.

2.2.2

Resiko dan Ancaman

2.2.2.1

Pengertian Resiko Menurut Peltier (2005, p21), resiko adalah kemungkinan sebuah

ancaman tertentu memanfaatkan kelemahan sistem tertentu yang dapat diserang. Menurut Alberts dan Dorofee (2003, p171), resiko adalah kemungkinan terkenanya bencana atau kerugian; sebuah potensi dari konsekuensi negatif yang tidak diinginkan dari suatu kejadian. Resiko ini menunjuk pada situasi dimana seseorang dapat melakukan sesuatu yang tidak diinginkan atau sebuah kejadian alam yang dapat menyebabkan akibat yang tidak diinginkan, mengakibatkan dampak negatif.

40 2.2.2.2

Pengertian Ancaman Menurut Connolly-Begg (2005, p543), ancaman adalah situasi atau

kejadian apapun, baik disengaja maupun tidak disengaja, yang dapat memberikan pengaruh buruk pada sistem, dimana berakibat pada perusahaan. Menurut Peltier (2005, p21), ancaman adalah sebuah kejadian yang berpotensi menyebabkan akses, modifikasi, penyingkapan yang terlarang atau perusakan sumber informasi, aplikasi atau sistem.

2.2.2.3 Disaster Menurut Maiwald-Sieglein (2002, p218), suatu bencana (disaster) dapat didefinisikan sebagai kejadian tentang segala peristiwa yang menyebabkan suatu gangguan penting pada kemampuan teknologi informasi. Itu adalah suatu peristiwa yang mengganggu yang proses bisnis normal dan mengakibatkan kerugian keuangan yang dapat diukur.

2.2.2.4

Analisis Resiko Menurut Peltier (2005, p2, p100), analisis resiko adalah proses

identifikasi aset dan ancaman, membuat prioritas dari ancaman terhadap kelemahan sistem, dan mengidentifikasi perlindungan yang tepat. Analisis resiko tidak dilakukan untuk memenuhi kebutuhan audit. Hal ini juga tidak dilakukan karena diperintahkan untuk keamanan informasi. Analisis resiko juga tidak dilakukan untuk memenuhi permohonan hukum dan perundangundangan.

41 Analisis resiko mendukung tujuan bisnis atau misi perusahaan. Analisis resiko adalah sebuah komponen penting dalam pengaturan organisasi yang sukses. Ini adalah sebuah proses yang harus dimulai dari permulaan proyek dan berlanjut sampai aplikasi atau sistem telah selesai dan keuntungan yang diharapkan telah tercapai. Analisis resiko harus fokus pada area yang beresiko paling tinggi dengan cakupan pertimbangan, dengan pengawasan yang berkelanjutan dari area lain proyek untuk mengidentifikasi resiko baru atau resiko yang meningkat. Kesuksesan dari strategi analisis resiko bergantung pada : •

komitmen dari pimpinan yang lebih berpengalaman

•

kemampuan dan pengalaman dari tim manajemen resiko dalam mengidentifikasi resiko-resiko dan pengembangan pengendalian resiko yang efektif

•

tim manajemen resiko dan unit bisnis yang bekerja bersama untuk mengidentifikasi dan mengatur resiko aset informasi.

•

proses analisis resiko berjalan terus menerus

•

kegunaan dari proses analisis resiko yang konsisten

•

laporan secara berkala mengenai kinerja keamanan yang disesuaikan dengan kebutuhan organisasi.

2.2.2.4.1

Analisis Resiko Kuantitatif

Menurut Peltier (2005, p19), analisis resiko kuantitatif mencoba untuk menentukan nilai-nilai dalam bentuk angka yang objektif secara

42 independen (misalnya nilai keuangan) kepada komponen-komponen dari analisis resiko dan potensi tingkat kerugian. Kelebihan analisis resiko kuantitatif adalah sebagai berikut. •

Hasilnya berdasarkan proses dan ukuran yang objektif.

•

Perlu usaha yang besar untuk menentukan nilai aset dan pengurangan resiko.

•

Usaha perkiraan cost-benefit dipandang penting.

•

Hasilnya dapat ditunjukkan dalam bahasa manajemen (seperti nilai keuangan, persentase, dan kemungkinan). Kekurangan analisis resiko kuantitatif adalah sebagai berikut.

•

Proses kalkulasinya lebih kompleks.

•

Hanya dapat bekerja dengan baik dengan automated tool yang sudah dikenal dan dasar pengetahuan yang berhubungan.

•

Membutuhkan usaha awal yang banyak.

•

Pada umumnya tidak ditujukan untuk tingkat personal.

•

Orang-orang yang terlibat tidak dapat dengan mudah dilatih selama proses.

•

Sulit untuk mengubah arah.

2.2.2.4.2

Analisis Resiko Kualitatif

Menurut Peltier (2005, p20), analisis resiko kualitatif tidak berusaha untuk menentukan nilai-nilai dalam bentuk angka kepada komponenkomponen analisis resiko. Analisis resiko kualitatif bergantung pada

43 skenario atau dengan pertanyaan “bagaimana jika”. Analisis resiko kualitatif pada hakekatnya bersifat subjektif. Kelebihan analisis resiko kualitatif adalah sebagai berikut. •

Perhitungannya sederhana (tidak ada perhitungan).

•

Tidak perlu menentukan nilai keuangan dari aset.

•

Tidak perlu mengkuantisasi frekuensi ancaman.

•

Lebih mudah, dapat melibatkan staf non-security dan non-teknikal.

•

Menyediakan fleksibilitas dalam pemrosesan dan pembuatan laporan.

Kekurangan analisis resiko kualitatif adalah sebagai berikut. •

Bersifat subjektif.

•

Hasilnya semata-mata bergantung pada kualitas tim manajemen resiko.

•

Tidak perlu banyak usaha untuk menentukan nilai keuangan dari aset yang menjadi target.

•

2.2.2.5

Tidak ada dasar untuk analisis cost-benefit dari pengurangan resiko.

Manajemen Resiko Menurut Peltier (2005, p224), manajemen resiko adalah proses

mengidentifikasi resiko, ukuran-ukuran pengurangan resiko, penentuan anggaran dari implementasi keputusan yang berhubungan dengan penerimaan, penghindaran, atau pengalihan resiko. Tahap akhir dari manajemen resiko

44 termasuk di dalamnya proses menentukan prioritas, anggaran, implementasi, dan menjaga ukuran pengurangan resiko yang tepat dalam siklus periode yang berlangsung terus-menerus dari analisis, penilaian, dan manajemen atau administrasi.

2.2.3 Oracle High Availability 2.2.3.1 Pengertian Availability Menurut Chan (2006, p1-1), ketersediaan (availability) adalah ukuran dimana sebuah aplikasi, service atau fungsionalitas tersedia sesuai dengan keinginan pengguna. Sifat-sifat utama sebuah solusi yang memiliki tingkat ketersediaan tinggi antara lain : •

Ketahanan uji Perangkat keras yang tahan uji adalah salah satu komponen dari solusi ketersediaan tinggi. Perangkat lunak yang tahan uji – termasuk di dalamnya database, web server dan aplikasi.

•

Kemampuan recovery Ada banyak pilihan untuk recovery jika terjadi sebuah gangguan. Adalah suatu hal yang penting untuk menentukan tipe gangguan yang mungkin terjadi dalam lingkungan high availability yang ada dan bagaimana cara recovery yang tepat dari gangguan tersebut dalam waktu yang disesuaikan dalam SLA.

•

Pendeteksian kesalahan tepat pada waktunya

45 Jika sebuah komponen di arsitektur gagal menjalankan fungsinya, maka pendeteksian cepat adalah komponen penting lain dalam pemulihan dari kemungkinan gangguan yang tidak diperkirakan. •

Operasi yang kontinuitas Akses kontinuitas pada data adalah hal yang sangat penting ketika sedang dilakukan proses pemeliharaan.

2.2.3.2 Penyebab Ketidaktersediaan Data Menurut Chan (2006, p1-3), penyebab ketidaktersediaan data dapat digambarkan dengan diagram berikut : Penyebab Ketidaktersediaan Data

Tidak Direncanakan

Gangguan pada komputer

Gangguan pada Storage

Kesalahan manusia

Kerusakan Data

Terencana

Gangguan pada lokasi

Perubahan sistem

Perubahan Data 

Gambar 2.5 Diagram Penyebab Ketidaktersediaan Data

Penjelasan untuk definisi gangguan pada diagram di atas : •

Gangguan pada komputer Sebuah gangguan yang terjadi ketika sistem yang berjalan pada database menjadi tidak tersedia karena sistemnya mati atau tidak dapat diakses.

46

•

Gangguan pada storage Sebuah gangguan yang terjadi ketika storage yang menangani beberapa atau semua isi database menjadi tidak tersedia karena sistem storage mati atau tidak dapat diakses

•

Kesalahan manusia Sebuah gangguan yang terjadi ketika tindakan yang tak disengaja atau jahat dilakukan sehingga menyebabkan data dalam database menjadi rusak secara logika dan tidak dapat digunakan.

•

Kerusakan data Sebuah gangguan yang terjadi ketika sebuah komponen perangkat lunak dan keras menyebabkan data yang rusak dibaca atau ditulis ke dalam database. Tingkatannya pun bervariasi mulai dari kerusakan sebagian kecil dari database (sebuah blok tunggal) hingga ke bagian besar dari database yang membuatnya tidak dapat digunakan lagi).

•

Gangguan pada lokasi Sebuah gangguan yang terjadi ketika sebuah kejadian menyebabkan semua atau sebagian penting dari sebuah aplikasi berhenti beroperasi atau menjadi lambat sehingga menjadi bagian yang tidak berguna. Sebuah gangguan pada lokasi berdampak pada semua proses pada data center atau sejumlah aplikasi yang didukung oleh data center.

47 •

Perubahan sistem Sebuah gangguan yang terjadi ketika proses pemeliharaan dan penyebaran baru sedang dilakukan secara rutin dan berkala. Perubahan sistem ini mencakup berbagai perubahan terencana ke lingkungan operasi yang terjadi di luar struktur data organisasi di database.

•

Perubahan data Sebuah gangguan yang terjadi ketika ada perubahan pada struktur logika atau fisik organisasi dari objek pada database Oracle dengan tujuan utama untuk meningkatkan kinerja atau pengontrolan.

2.2.3.3 Kerangka Analisis Penentuan Kebutuhan Sistem High Availability Menurut Chan (2006, p3-1) Elemen-elemen untuk kerangka analisis ini adalah sebagai berikut : •

Analisis dampak bisnis Sebuah analisis dampak bisnis yang tepat mengidentifikasi proses bisnis dalam sebuah organisasi, menghitung resiko kehilangan yang dapat dihitung untuk gangguan teknologi informasi yang terencana dan tidak terencana yang mempengaruhi masing-masing dari proses bisnis dan menggambarkan secara garis besar dampak dari gangguan-gangguan ini. Hal ini juga memperhitungkan fungsi-fungsi bisnis yang penting, orang dan sumber daya, peraturan pemerintah, dan ketergantungan dengan pihak internal atau eksternal bisnis. Analisis ini dilakukan dengan menggunakan data yang secara subjektif dan objektif dikumpulkan dari

48 wawancara dengan pihak karyawan yang berpengetahuan dan berpengalaman, melihat kembali praktik bisnis yang sudah ada, laporan keuangan, pencatatan sistem teknologi informasi dan yang lainnya. •

Kerugian akibat ketidaktersediaan sistem Sebuah analisis dampak bisnis yang baik juga memperkirakan kerugian yang terjadi akibat ketidaktersediaan sistem baik karena gangguan yang terencana maupun tidak terencana pada sistem teknologi informasi yang mendukung proses-proses bisnis yang ada.

•

Recovery Time Objective (RTO) Recovery time objective adalah jumlah maksimum waktu suatu proses bisnis berbasis teknologi informasi boleh berhenti sebelum perusahaan menderita kerugian material yang berarti. RTO menandai adanya toleransi downtime suatu proses bisnis atau suatu perusahaan secara umum. Kebutuhan RTO sebanding dengan sifat kritis dari bisnis tersebut. Sebuah organisasi memiliki kebutuhan RTO yang bermacammacam sesuai dengan proses bisnisnya yang beraneka ragam.

•

Recovery Point Objective (RPO) Recovery point objective adalah jumlah maksimum data dalam suatu proses bisnis berbasis teknologi informasi yang boleh hilang sebelum menyebabkan kerugian kepada perusahaan. RPO menandai adanya toleransi kehilangan data dari suatu proses bisnis atau suatu perusahaan secara umum. Kehilangan data ini sering diukur dalam kaitan dengan waktu, sebagai contoh, kehilangan data selama lima jam atau dua hari.

49

2.2.3.4 Oracle Data Guard Menurut Ray (2006, p5), Oracle Data Guard adalah infrastruktur perangkat lunak yang melakukan proses pengaturan, pengawasan dan otomatisasi melalui pembuatan, pemeliharaan dan pengawasan satu atau lebih database

yang berada dalam posisi siap siaga (standby database) untuk

melindungi data perusahaan dari kegagalan, bencana, kesalahan, dan kerusakan-kerusakan yang mengancam. Data Guard menjaga standby database sebagai salinan data transaksi yang konsisten dari primary database. Standby database ini dapat ditempatkan pada lokasi berada beribu-ribu mil dari data center utama, atau dapat ditempatkan di kota yang sama, kampus yang sama, atau bahkan di bangunan yang sama. Jika primary database menjadi tidak tersedia baik direncanakan maupun tidak direncanakan, Data Guard dapat mengganti standby database manapun menjadi primary database, sehingga mempersingkat downtime dan mencegah kehilangan data.

50

  Gambar 2.6 Arsitektur Oracle Data Guard

2.2.3.4.1 Keuntungan Data Guard Data Guard menawarkan keuntungan sebagai berikut. •

Disaster recovery dan high availability – Data Guard menyediakan suatu disaster recovery yang menyeluruh dan efisien serta solusi high availability. Kemampuan failover yang otomatis dan switchover yang mudah diatur mengijinkan pertukaran peran yang cepat antara primary database dan standby database, memperkecil downtime dari primary database untuk downtime yang direncanakan maupun yang tidak direncanakan.

•

Perlindungan data menyeluruh – Suatu standby database juga menyediakan suatu perlindungan yang efektif untuk menghadapi kesalahan pemakai dan kerusakan data. Kerusakan fisik pada level

51 penyimpanan (storage) pada primary database tidak dikirimkan kepada standby database. Dengan cara yang sama, masalah kesalahan pemakai atau kerusakan logika yang menyebabkan kerusakan permanen pada primary database dapat dipecahkan. Akhirnya, redo data divalidasi pada saat diterima di standby database dan saat di-apply pada standby database. •

Pemanfaatan sumber daya sistem yang efisien – Suatu physical standby database dapat digunakan untuk melakukan proses backup dan

pembuatan

laporan

yang

read-only,

dengan

demikian

mengurangi beban kerja primary database serta mengurangi siklus CPU dan I/O. Pada database Oracle 10g release 2, physical standby database dapat juga dengan mudah dikonversi menjadi physical standby database dan database untuk read / write. Suatu logical standby database mengijinkan tabelnya tersedia untuk akses readonly saat di-update dari primary database. Suatu logical standby database juga mengijinkan para pemakai untuk melakukan operasi manipulasi data pada tabel yang tidak di-update dari primary database. •

Fleksibilitas dalam proteksi data untuk mengimbangi antara kebutuhan ketersediaan (availability) dengan performa – Data Guard menawarkan mode perlindungan maksimum (maximum protection), ketersediaan maksimum (maximum availability) dan performa maksimum (maximum performance) untuk membantu perusahaan

52 menyeimbangkan data protection terhadap kebutuhan performa sistem. •

Perlindungan dari kegagalan jaringan komunikasi – Jika jaringan komunikasi rusak antara primary database dan satu atau lebih standby database, redo data tidak bisa dikirim dari primary database ke standby database. Ketika jaringan komunikasi telah diperbaiki, redo data yang hilang secara otomatis dideteksi oleh Data Guard dan archived log yang perlu secara otomatis dikirimkan ke standby database. Standby database disinkronisasi kembali dengan primary database, dengan tidak ada intervensi manual oleh admin.

•

Pengaturan yang sederhana dan terpusat – Data Guard Broker mengotomatiskan tugas pengaturan dan pengawasan berbagai database pada suatu pengaturan Data Guard. Admin dapat menggunakan baik Oracle Enterprise Manager maupun commandline khusus Broker (DGMGRL).

•

Integrasi dengan database Oracle – Data Guard tersedia sebagai suatu fitur yang terintegrasi dengan database Oracle (Enterprise Edition) tanpa biaya tambahan.

Berikut ini adalah tabel keuntungan menggunakan Oracle Data Guard dengan penanganan terhadap tipe gangguan dan waktu recovery :

53 Waktu Tipe Gangguan

Keuntungan

Recovery

Gangguan pada

Fast-start failover dan fast

Maksimum 5

komputer

connection failover

menit

Gangguan pada

Fast-start failover dan fast

Maksimum 5

storage

connection failover

menit

Kerusakan data

Validasi otomatis redo block

Maksimum 5

sebelum mereka di-apply,

menit

menjalankan fast failover ke standby database yang tidak rusak Gangguan pada

Fast-start failover dan fast

Maksimum 5

lokasi

connection failover

menit

Tabel 2.2 Keuntungan Oracle Data Guard Beserta Perkiraan Waktu Recovery

54 2.2.3.4.2 Arsitektur Proses Data Guard

 

Gambar 2.7 Arsitektur Proses Data Guard pada Oracle Database 10g Release 2

Seperti ditunjukkan pada gambar tersebut, Data Guard menggunakan beberapa proses dari Oracle database instance untuk mencapai otomasi penting bagi disaster recovery dan ketersediaan tinggi (high availability). Pada primary database, Data Guard menggunakan proses Log Writer (LGWR) atau beberapa proses archiver (ARCH) untuk mengumpulkan transaksi redo data. Untuk memastikan isolasi dari gangguan jaringan, proses log writer menggunakan proses background khusus, yang disebut proses Logwriter Network Server (LNS), untuk mengirim redo data kepada standby database secara synchronous atau asychronous. Proses archiver mengirim redo data kepada standby database secara langsung. Primary database juga mempunyai proses Fetch Archive Log (FAL) untuk

55 menyediakan mekanisme client-server bagi pengiriman archived log ke standby langsung setelah jaringan komunikasi antara primary database dan standby terputus, untuk sinkronisasi kembali dan resolusi gap otomatis. Pada standby database, Data Guard menggunakan satu atau lebih proses Remote File Server (RFS) untuk menerima redo data dari primary database dan menulis redo data pada standby redo log, Managed Recovery Process (MRP) untuk apply redo data kepada physical standby database, dan Logical Standby Process (LSP) untuk apply SQL redo data kepada logical standby database. Jika Data Guard Broker digunakan, Data Guard juga menggunakan proses Data Guard Monitor (DMON) untuk mengatur dan memonitor primary database dan standby database sebagai satu konfigurasi.

Archiving Redo Data dengan ARCn Secara default, redo transport service menggunakan proses ARC untuk melakukan proses archiving pada online redo log di primary database. Proses ARC hanya mendukung mode proteksi maximum performance pada konfigurasi Data Guard. Parameter LOG_ARCHIVE_MAX_PROCESSES menjelaskan jumlah maksimum dari proses ARC. Secara umum, 4 proses archiver dijalankan ketika primary database dinyalakan dan Oracle database secara dinamis mengatur jumlah proses archiver untuk menyeimbangkan dengan kinerja archiver. Semakin banyak jumlah proses ARC, beban kerja archiver akan semakin ringan namun waktu yang diperlukan untuk switchover dan failover akan semakin lama.

56

Gambar 2.8 Archiving pada Tujuan Lokal Sebelum ke Tujuan Jarak Jauh

Berdasarkan gambar di atas, proses archiving terjadi ketika sebuah pergantian log terjadi pada primary database : •

Pada primary database, setelah proses ARC0 berhasil melakukan archiving

pada

online

redo

log

lokal

ke

tujuan

lokal

(LOG_ARCHIVE_DEST_1), proses ARC1 mengirimkan redo log dari archived redo log lokal ke standby database tujuan (LOG_ARCHIVE_DEST_2). •

Pada database tujuan, proses RFS akan secara bergilir menuliskan redo data ke sebuah archived redo log dari standby redo log. Log apply service menggunakan Redo Apply (proses MRP) atau SQL

57 Apply (proses LSP) untuk meng-apply redo data tersebut pada standby database.

Archiving Redo Data dengan LGWR Service pengiriman redo dapat diaktifkan dengan menggunakan proses LGWR untuk mengirimkan redo data ke tujuan yang remote. Menggunakan proses LGWR berbeda dengan menggunakan proses ARCn karena sebagai ganti menunggu online redo log untuk melakukan switch pada primary database dan kemudian menulis semua archived redo log pada tujuan yang remote secara bersamaan, proses LGWR memilih standby redo log pada lokasi standby yang mencerminkan nomor sequence (dan ukuran) dari online redo log yang sedang aktif pada primary database. Kemudian, saat redo dibuat oleh primary database, redo tersebut juga dikirimkan ke tujuan yang remote. Transmisi ke tujuan dapat dilakukan secara synchronous atau asynchronous, berdasarkan apakah atribut SYNC atau ASYNC yang diatur pada parameter LOG_ARCHIVE_DEST_n. Proses LGWR. Proses LGWR asynchronous dibutuhkan untuk mode proteksi maximum protection dan maximum availability pada konfigurasi Data Guard.

•

Proses Archival LGWR SYNC Secara default proses archival LGWR menggunakan SYNC pada parameter LOG_ARCHIVE_DEST_n. Atribut NET_TIMEOUT direkomendasi untuk diatur, karena atribut ini mengontrol waktu

58 proses LGWR menunggu status dari proses network server sebelum memutuskan koneksi jaringan. Jika tidak ada respon dalam jangka waktu yang telah diatur pada NET_TIMEOUT, maka proses LGWR akan menampilkan pesan error. Gambar berikut menunjukkan konfigurasi Data Guard yang menggunakan proses LGWR untuk mengirimkan redo data secara synchronous ke sistem standby pada saat yang sama dengan proses menulis redo data ke online redo log pada primary database.

Gambar 2.9 Proses Archival LGWR SYNC dengan Standby Redo Log

59 Pada primary database, proses LGWR memberikan redo data ke satu atau lebih proses network server (LNSn), yang akan memulai I/O jaringan secara paralel ke banyak tujuan yang remote. Transaksi tidak di-commit pada primary database sampai redo data yang diperlukan untuk recover transaksi yang diterima oleh semua tujuan. Pada sistem standby, remote file server (RFS) menerima redo data melalui jaringan dari proses LGWR dan menulis redo data ke standby redo log. Log switch pada primary database memicu log switch pada standby database, menyebabkan prosesproses ARCn pada standby database melakukan archiving terhadap standby redo log menjadi archived redo log pada standby database. Kemudian, Redo Apply (proses MRP) atau SQL Apply (proses LSP) melakukan apply redo data pada standby database. Jika dalam mode real-time apply, Data Guard melakukan recover redo data secara langsung dari standby redo log yang sedang aktif saat sedang diisi oleh proses RFS.  

•

Proses Archival LGWR ASYNC Gambar berikut menunjukkan proses LNSn mengumpulkan redo data dari online redo log dan mengirimkannya ke Oracle Net kepada proses RFS pada standby database.

60

Gambar 2.10 Proses Archival LGWR ASYNC dengan Network Server (LNS)

Saat menggunakan LGWR ASYNC, proses log writer menulis ke online redo log, sementara proses network server (LNSn) secara asynchronous mengirim ke standby. Satu LNS untuk setiap tujuan (standby). Proses LGWR melanjutkan proses ke permintaan berikutnya tanpa menunggu jaringan I/O LNS sampai selesai. Jika service pengiriman redo mengirimkan redo data ke banyak tujuan, proses LNSn (satu untuk setiap tujuan) memulai I/O jaringan ke semua tujuan secara paralel. Saat online redo log telah penuh,

61 proses log switch terjadi dan proses archiver membuat archive dari log file lokal.

2.2.3.4.3 Komponen Teknologi Data Guard Data Guard Oracle terdiri dari suatu database produksi, juga dikenal sebagai primary database, dan satu atau lebih standby database, yang merupakan salinan data transaksi yang konsisten dari primary database. Data Guard menjaga konsistensi salinan data ini menggunakan redo data. Ketika transaksi terjadi di primary database, redo data dihasilkan dan ditulis pada redo log lokal. Dengan Data Guard, redo data ini juga dikirim ke lokasi standby database dan di-apply pada standby database, menjaga standby database tetap sinkron dengan primary database. Data Guard mengijinkan admin untuk memilih apakah redo data dikirim secara synchronous atau secara asynchronous ke lokasi standby database.

a.

Konfigurasi Data Guard Konfigurasi Data Guard terdiri dari satu primary database dan satu atau lebih standby database (bisa sampai sembilan). Primary database dan standby database dapat berjalan pada sebuah node atau dalam suatu lingkungan RAC. Standby database dihubungkan kepada primary database dengan jaringan standar berbasis TCP/IP (misalnya Local Area Network - LAN, Metropolitan Area Network - MAN, Wide Area Network - WAN) menggunakan Oracle Net Service. Tidak ada pembatasan di mana database ditempatkan, dengan

62 ketentuan bahwa database-database tersebut dapat berkomunikasi satu

sama

lain.

Bagaimanapun,

untuk

disaster

recovery,

direkomendasikan bahwa standby database menjadi host pada lokasi yang secara geografis terpisah dari lokasi primary database. Data Guard memerlukan arsitektur sistem operasi yang sama pada sistem utama dan sistem standby. Jika primary database berjalan di sistem operasi Linux pada arsitektur Intel, semua standby database harus pula berjalan pada Linux dan Intel. Versi Oracle Database Enterprise Edition yang sama harus diinstal pada primary database dan semua standby database, kecuali selama upgrade rolling database yang menggunakan logical standby database.

b. Mode Proteksi Data Guard menyediakan tiga high-level mode data protection untuk mengimbangi biaya data protection, ketersediaan (availability), performa, dan perlindungan transaksi. Untuk menentukan mode data protection yang sesuai, perusahaan harus menimbang kebutuhan bisnis mereka untuk data protection terhadap kebutuhan pemakai terhadap waktu respon sistem. Tabel berikut menguraikan secara singkat tiap mode dari perspektif resiko kerugian data.

63 Mode Data

Resiko kehilangan data

Mekanisme pengiriman

Protection

saat terjadi bencana

redo data

Maximum

Tidak ada kehilangan

Synchronous

Protection

data

(LGWR SYNC)

Maximum

Tidak ada kehilangan

Synchronous

Availibility

data

(LGWR SYNC)

Kehilangan data minimal Asynchronous (LGWR

Maximum biasanya hanya beberapa

ASYNC) or ARCH

Performance detik

Tabel 2.3 Mode Data Protection  

•

Maximum Protection Mode maximum protection menawarkan tingkatan data protection yang paling tinggi untuk primary database, memastikan solusi disaster recovery menyeluruh tanpa ada kehilangan data sama sekali. Ketika beroperasi dalam mode maximum protection, redo record secara synchronous dikirimkan oleh proses LGWR (melalui proses LNS) dari primary database kepada standby database, dan suatu transaksi tidak di-commit pada primary database sampai dapat dipastikan bahwa data transaksi telah tersedia pada sedikitnya satu standby server. Sangat direkomendasikan bahwa mode ini diatur dengan sedikitnya dua standby

64 database. Jika standby database terakhir menjadi tak tersedia, proses berhenti pada primary database. Hal ini memastikan tidak ada transaksi yang hilang saat primary database down setelah kehilangan koneksi dengan semua standby database nya. Oleh karena menggunakan transmisi synchronous, mode maximum protection ini dapat berdampak pada waktu respon primary database. Dampak ini dapat diperkecil dengan konfigurasi suatu jaringan cadangan dengan bandwidth yang cukup untuk load transaksi saat peak. Pasar saham, bursa uang, dan lembaga keuangan adalah contoh bisnis yang memerlukan mode maximum protection ini.

•

Maximum Availability Mode maximum availablility mempunyai tingkat yang lebih tinggi untuk ketersediaan data (data availability) pada primary database. Sama seperti mode maximum protection, redo data secara synchronous dikirimkan oleh LGWR dari primary database kepada standby database, dan transaksi tidak di-commit pada primary database sampai telah dipastikan bahwa data transaksi tersedia pada sedikitnya satu standby server. Bagaimanapun, dalam mode ini, tidak sama dengan mode maximum protection, jika standby database terakhir menjadi tak tersedia – misalnya oleh karena masalah

65 koneksi jaringan, proses berlanjut pada primary database. Standby

database

boleh

untuk

sementara

tertinggal

dibandingkan primary database, tetapi saat standby database tersedia lagi, database akan secara otomatis mensinkronkan dengan tidak ada data yang hilang, menggunakan archived log yang terkumpul pada primary database. Oleh karena transmisi redo synchronous, mode proteksi ini dapat berdampak pada waktu respon dan hasil dari input. Dampak ini dapat diperkecil dengan konfigurasi suatu jaringan cadangan dengan bandwidth yang cukup untuk load transaksi saat peak. Mode maximum availability cocok untuk bisnis yang menginginkan jaminan tidak ada kehilangan data sama sekali, tetapi tidak ingin primary database terkena dampak kerusakan jaringan atau standby server. Bisnis jenis ini mentoleransi kemungkinan kehilangan data, kegagalan dalam hitungan detik yang kemudian mempengaruhi primary database sebelum kerusakan jaringan atau standby server diperbaiki.

•

Maximum Performance Mode maximum performance adalah mode proteksi standar. Mode ini menawarkan lebih sedikit data protection primary database, tetapi menawarkan performa yang lebih

66 tinggi, dibanding mode maximum availability. Pada mode ini, ketika primary database memproses transaksi, redo data dikirimkan secara asynchronous kepada standby database oleh proses LGWR. Sebagai alternatif, proses Archiver (ARCH)

pada

primary

database

dapat

diatur

untuk

mengirimkan redo data pada mode ini. Pada berbagai kasus, operasi commit pada primary database tidak menunggu standby sampai menerima redo data. Bila ada standby database yang menjadi tak tersedia (unavailable), proses berlanjut pada primary database dan sedikit atau tidak ada efek pada performa. Pada saat terjadi kegagalan primary database, redo data yang belum dikirim kepada standby database hilang. Bagaimanapun, jika jaringan mempunyai throughput yang cukup untuk bertahan saat peak dalam lalu lintas redo data dan proses LGWR digunakan untuk mengirimkan redo kepada standby server, banyaknya transaksi yang hilang akan menjadi sangat kecil atau nol. Mode maximum performance harus digunakan ketika performa dan ketersediaan (availability) pada primary database lebih penting dibanding resiko kehilangan sejumlah kecil data. Mode ini juga cocok digunakan untuk pemakaian Data Guard melalui WAN, dimana latency yang melekat

67 pada jaringan tersebut dapat membatasi kesesuaian dari transmisi redo secara synchronous.

c.

Pengiriman Redo Data Selama pengiriman redo secara asynchronous menggunakan proses Log Writer (LGWR ASYNC), proses server jaringan (LNSn) yang melayani masing-masing standby database memancarkan redo data ke luar dari online redo log pada primary database, sebagai ganti menggunakan buffer ASYNC. Hal ini mengijinkan pengiriman redo secara asynchronous yang menggunakan LGWR tidak dibatasi oleh ukuran dari buffer ASYNC. Ukuran transmisi jaringan maksimum juga ditingkatkan dari 1 MB sampai 10 MB dengan demikian sangat meningkatkan pemanfaatan jaringan pada saat load jaringan banyak. Karena pengiriman menggunakan ARCH, sekarang mungkin untuk mempunyai beberapa proses archiver mengirim redo data secara paralel dari archived redo log tunggal kepada standby database. Ini ditetapkan melalui atribut MAX_CONNECTIONS yang baru pada parameter LOG_ARCHIVE_DEST_n. Jumlah maksimum proses ARCH yang diperbolehkan (yang ditetapkan melalui

parameter

inisialisasi

LOG_ARCHIVE_MAX_PROCESSES) juga telah ditingkatkan dari 10 sampai 30. Peningkatan ini memungkinkan perpindahan dari

68 archived redo data ke standby database selama aktivitas high peak, misalnya selama batch upload.

d. Redo Apply dan SQL Apply Suatu standby database pada awalnya diciptakan dari suatu backup salinan primary database. Saat dibuat, Data Guard secara otomatis menjaga standby database sebagai salinan transaksi yang konsisten dari primary database dengan mengirimkan redo data dari primary database kepada sistem standby dan kemudian meng-apply redo data pada standby database. Data Guard menyediakan dua cara untuk meng-apply redo data pada standby database dan menjaga tetap konsisten dengan primary database, dan cara ini sesuai dengan kedua jenis standby database yang didukung oleh Data Guard : -

Redo Apply, digunakan untuk physical standby database

-

SQL Apply, digunakan untuk logical standby database. Tidak ada perbedaan antara dua jenis standby database ini

pada saat transmisi redo data dari primary database. Saat redo data sampai ke standby server, bagaimana redo data di-apply pada standby database membedakan dua jenis standby database ini ke dalam 2 bagian :

69 •

Physical Standby Database – Redo Apply Physical standby database dijaga tetap sinkron dengan primary database dengan men-apply redo data yang diterima dari primary database menggunakan media recovery Oracle. Physical standby database secara fisik identik dengan primary database pada basis block-for-block, termasuk skema database dan indeks. Keuntungan dari physical standby database antara lain sebagai berikut : -

Disaster recovery dan ketersediaan yang tinggi Physical standby database memungkinkan suatu disaster recovery yang efisien dan sempurna serta memungkinkan solusi untuk ketersediaan database yang tinggi. Kemampuan switchover dan failover yang mudah diatur mengijinkan pertukaran peran sederhana antara primary database dengan physical standby database,

memperkecil

downtime

dari

primary

database. -

Data Protection - Dengan menggunakan physical standby database, Data Guard dapat memastikan tidak ada kehilangan data, bahkan saat menghadapi bencana tak terduga. Physical standby database mendukung semua tipe data serta operasi DDL dan DML yang digunakan oleh primary database. Physical standby database juga melindungi database

70 dari

kesalahan

pemakai

dan

kerusakan

data.

Kerusakan fisik data pada primary database tidak menyebabkan kerusakan pada standby database. Sama halnya dengan masalah kesalahan pemakai atau kerusakan secara logika yang menyebabkan kerusakan permanen pada primary database dapat dipecahkan. Redo data divalidasi ketika di-apply pada standby database. -

Pengurangan beban kerja primary database - Physical standby database dapat dibuka secara read-only untuk membuat

laporan

dan

query.

Di

samping

menggunakan Recovery Manager (RMAN), physical standby database dapat digunakan untuk membuat backup

primary

database,

dengan

demikian

mengurangi siklus CPU dan I/O pada sistem produksi. RMAN dapat melaksanakan backup selagi physical standby database sedang melakukan recovery, atau ketika dibuka secara read-only. -

Performance - Teknologi redo apply yang digunakan oleh

physical

standby

database

menerapkan

perubahan menggunakan mekanisme recovery lowlevel, yang mem-bypass semua tingkatan kode layer SQL dan oleh karena itu menjadi mekanisme yang paling efisien untuk penerapan perubahan. Hal ini

71 membuat

teknologi

redo

apply

menjadi

suatu

mekanisme yang sangat efisien untuk menyebarkan perubahan antar database.

•

Logical Standby Database – SQL Apply Suatu logical standby database adalah suatu database independen yang berisi data yang sama dengan primary database. Logical standby database di-update menggunakan perintah SQL, dan mempunyai keuntungan yaitu dapat digunakan secara bersamaan untuk recovery dan untuk tugas lain seperti pembuatan laporan dan query. Suatu logical standby database berisi informasi logika yang sama dengan primary database, walaupun struktur dan organisasi fisik data dapat berbeda. SQL Apply Technology menjaga logical standby database tetap sinkron dengan primary database dengan mengubah redo data yang diterima dari primary database ke dalam sintaks SQL dan kemudian menjalankan sintaks SQL pada standby database. Hal ini memungkinkan logical standby database dapat diakses untuk query dan pembuatan laporan pada waktu yang sama saat SQL sedang di-apply. Karena

logical

standby

database

di-update

menggunakan sintaks SQL, logical standby database tetap dalam mode read-write, dan tabel yang sedang di-update dari

72 primary database dapat digunakan secara serempak untuk tugas lain seperti pembuatan laporan, summation, dan query. Tugas ini dapat juga dioptimalkan dengan membuat indeks tambahan dan materialized view pada tabel tersebut. Suatu logical standby database dapat menjadi host bagi berbagai skema database, dan para pemakai dapat melakukan operasi manipulasi data normal pada tabel di dalam skema yang tidak di-update dari primary database.

Keuntungan Logical Standby Suatu logical standby database menyediakan manfaat disaster recovery, ketersediaan tinggi (high availability), dan perlindungan data yang serupa dengan physical standby database. Logical standby database juga memberikan manfaat khusus berikut : •

Penggunaan sumber daya perangkat keras standby yang efisien – Suatu logical standby database dapat digunakan untuk kegiatan bisnis lain sebagai tambahan terhadap kebutuhan disaster recovery. Logical standby database dapat host skema database tambahan di luar skema yang diproteksi dalam konfigurasi Data Guard, dan para pemakai dapat melakukan operasi DDL atau DML pada skema tersebut kapan saja. Karena tabel logical standby yang dilindungi oleh Data Guard

73 dapat disimpan di suatu layout fisik yang berbeda dibanding dengan primary database, indeks tambahan dan

materialized

meningkatkan

view

performa

dapat query

dibuat dan

untuk

penyesuaian

dengan kebutuhan bisnis tertentu. •

Pengurangan beban kerja pada primary database – Suatu logical standby database tetap terbuka (OPEN) pada waktu yang sama saat tabelnya di-update dari primary database, dan tabel itu tersedia untuk akses baca (read). Hal ini memungkinkan logical standby database untuk digunakan secara bersamaan untuk pembuatan laporan dan perlindungan data, dengan demikian membebas-tugaskan primary database dari pembuatan laporan dan tugas query, serta mengurangi siklus CPU dan I/O.

2.2.3.4.4

Menentukan Jenis Standby Database yang Sesuai

Menurut Chan (2006, p2-22), menentukan jenis standby database yang sesuai untuk diimplementasikan dapat dilakukan dengan meninjau beberapa bagian seperti : •

Memeriksa tipe data yang sedang digunakan dalam objek-objek database karena jenis logical standby database tidak mendukung semua tipe data dari objek database. Untuk memeriksa daftar tabel

74 apa saja yang tidak didukung oleh logical standby database dapat menggunakan perintah SQL berikut : SET PAGES 200 LINES 132 COL owner FORMAT a8 COL data_type FORMAT a15 COL table_name FORMAT a32 COL column_name FORMAT a25 COL attributes FORMAT a15 SELECT owner, table_name, reason FROM dba_streams_unsupported WHERE owner NOT IN (SELECT owner FROM dba_logstdby_skip WHERE statement_opt='internal schema' ) ORDER BY owner; Untuk memeriksa daftar tabel beserta jenis kolom dan tipe data yang tidak didukung oleh logical standby database dapat menggunakan perintah SQL berikut : COL owner FORMAT a9 COL data_type FORMAT a35 COL table_name FORMAT a35 SELECT owner, table_name, column_name, data_type FROM dba_tab_cols WHERE owner NOT IN (SELECT owner FROM dba_logstdby_skip WHERE statement_opt='internal schema' ) AND data_type NOT IN ('binary_double', 'binary_float', 'interval year to month','interval day to second', 'blob', 'clob','char', 'date','long', 'long raw', 'nchar', 'nclob','number', 'nvarchar2','raw','timestamp', 'timestamp(6)','timestamp(6) with time zone','timestamp(9)', 'timestamp with local timezone', 'timestamp with timezone', 'varchar','varchar2' ) ORDER BY 1,2;

75 Jika hasil yang ditampilkan berisi tabel-tabel yang bernilai penting dan tidak dapat diganggu nilai datanya, maka jenis physical standby database harus digunakan untuk database tersebut. Jika tidak ada hasil yang ditampilkan maka baik jenis physical maupun logical standby database dapat digunakan. •

Menentukan apakah standby database akan dapat diakses oleh pengguna selama perubahan sedang dijalankan. Jika standby database nantinya diinginkan untuk dapat diakses selama perubahan sedang dijalankan maka logical standby database dapat menjadi pilihan yang tepat. Namun jika standby database nantinya

tidak

perlu

diakses

oleh

pengguna

maka

dapat

menggunakan physical standby database. •

Menganalisis beban kerja dan waktu padat yang terjadi pada database. Standby database jenis logical akan mengakibatkan waktu kinerja pada database menjadi menurun dan mekanisme pemulihan yang lambat karena logical standby database meng-apply perubahanperubahan ke bentuk SQL.

2.2.3.4.5 Menentukan Jenis Mode Proteksi yang Sesuai Menurut Chan (2006, p2-24), Untuk menentukan jenis mode proteksi yang sesuai untuk standby database dapat menggunakan pertanyaan-pertanyaan seperti yang ada di tabel berikut :

76 Pertanyaan Apakah kehilangan data ditolerir jika lokasi primary database mengalami gangguan ?

Rekomendasi Ya : Dapat menggunakan semua jenis mode proteksi Tidak : Gunakan mode maximum protection atau maximum availability

Berapa banyak kehilangan data yang

Tidak ada : Gunakan mode proteksi

ditolerir jika sebuah lokasi mengalami

maximum protection atau

gangguan ?

maximum availability Beberapa : Gunakan mode proteksi maximum performance dengan LGWR ASYNC

Apakah potensi kehilangan data

Ya : Gunakan mode proteksi maximum

antara primary database dan standby

performance atau maximum

database dapat ditolerir ketika

availability

koneksi jaringan atau sebuah standby

Tidak : Gunakan mode proteksi

host tidak tersedia untuk sementara

maximum protection atau

waktu ?

maximum availability dengan beberapa standby database.

77 Seberapa jauh lokasi DRC seharusnya

Jarak antara lokasi dan infrastruktur

dari lokasi primary database ?

jaringan menentukan kelatenan jaringan dan bandwidth serta mode proteksi yang dapat digunakan. Untuk

suatu

jaringan

low-latency,

jaringan bandwidth tinggi, gunakan mode

maximum

protection

atau

maximum availability. Pada hal ini, dampak kinerjanya sedikit dan dapat mencapai ketidakhilangan data. Untuk

suatu

jaringan

high-latency,

gunakan mode maximum performance dengan mode transportasi ASYNC. Pada hal ini, dampak kinerja pada primary database sedikit dan dapat membatasi kehilangan data selama hitungan detik. Mode

maximum

maximum

availability

protection

transportasi

SYNC

digunakan,

tetapi

dan

dengan

jenis

masih

dapat

membutuhkan

prakiraan jika ada sesuatu yang melebihi kebutuhan kinerja.

78 Berapa bandwidth jaringan dan

Bandwidth yang digunakan haruslah

latency antar lokasi primary database

lebih besar dari ukuran pembuatan

dan DRC yang disarankan ?

maximum redo data. Untuk komunikasi 2 arah ukuran bandwidth-nya harus sebesar 50% dari kapasitas jaringan , tetapi tetap harus mempertimbangkan kebutuhan

jaringan

untuk

aplikasi

lainnya. Tabel 2.4 Menentukan Jenis Mode Proteksi yang Digunakan Standby Database

2.2.3.4.6 Primary Database Menurut Schupmann (2006, Glosarry-3), primary database adalah sebuah database produksi yang dari mana satu atau lebih standby database dibuat dan dijaga. Setiap standby database dihubungkan dengan hanya satu primary database. Sebuah primary database tunggal mendukung beberapa standby database. Data Guard broker monitor (DMON) memelihara master copy dari file konfigurasi biner dengan primary database, memastikan bahwa masing-masing salinan file standby database tetap up-to-date setiap kali perubahan dibuat. Broker mengacu pada database ini menggunakan nilai pada parameter inisialisasi DB_UNIQUE_NAME yang didefinisikan unik secara global.

79 2.2.3.4.7 Standby Database Menurut Cyran (2005, Glosarry-14), standby database adalah suatu salinan primary database yang dapat digunakan untuk perlindungan terhadap bencana. Standby database dapat di-update dengan archived redo log dari primary database dalam rangka menjaga tetap sama sengan primary database. Jika suatu bencana menghancurkan primary database, standby database dapat diaktifkan dan dijadikan primary database yang baru.

2.2.3.4.8 Oracle Data Guard Broker Menurut Schupmann (2006, p1-2), Oracle Data Guard broker adalah suatu framework manajemen terdistribusi yang mengotomatiskan dan memusatkan pembuatan, pemeliharaan, dan monitoring konfigurasi Data Guard. Daftar berikut menguraikan sebagian dari operasi diotomatiskan dan disederhanakan oleh broker : •

Membuat konfigurasi Data Guard yang menyertakan suatu primary database, standby database (physical atau logical) yang baru atau yang sudah ada, pengiriman redo, dan penerapan log.

•

Menambahkan standby database (physical atau logical) tambahan yang baru atau yang sudah ada pada konfigurasi Data Guard. Pada konfigurasi yang sama bisa terdapat sebuah primary database dan 1 sampai 9 standby database.

•

Mengatur konfigurasi Data Guard secara keseluruhan, mencakup semua database, pengiriman redo, dan penerapan log, melalui

80 suatu koneksi client ke database manapun di dalam konfigurasi itu. •

Mengatur mode proteksi untuk konfigurasi broker.

•

Melakukan switchover atau failover dengan perintah tunggal untuk memulai dan mengendalikan perubahan peran yang kompleks terhadap semua database di dalam konfigurasi itu.

•

Mengatur konfigurasi failover untuk terjadi secara otomatis ketika terjadi kerusakan primary database, meningkatkan ketersediaan tanpa intervensi manual.

•

Mengawasi status dari keseluruhan konfigurasi, mengambil informasi

diagnostik,

melaporkan

statistik

seperti

tingkat

penerapan log dan tingkat pembuatan redo, dan mendeteksi permasalahan yang cepat dengan tool pengawasan terpusat, pengujian, dan performa.

Data Guard Command-Line Interface (DGMGRL) DGMGRL memungkinkan administrator untuk mengendalikan dan mengawasi konfigurasi Data Guard dari prompt DGMGRL atau dalam script. Administrator dapat melakukan mayoritas kegiatan yang diperlukan untuk mengatur dan mengawasi database-database dalam konfigurasi menggunakan perintah DGMGRL. DGMGRL juga mencakup perintah untuk membuat proses observer yang mengawasi primary database dan standby database secara terus-

81 menerus dan mengevaluasi apakah failover diperlukan, dan kemudian memulai fast-start failover saat kondisi mengharuskan untuk melakukan failover.

Perintah

Deskripsi

ADD

Menambah standby database ke dalam konfigurasi broker.

CONNECT

Menghubungkan ke Oracle instance.

CREATE

Membuat konfigurasi broker.

DISABLE

Menonaktifkan konfigurasi, database, atau fast-start failover.

EDIT

Mengubah konfigurasi, database, atau instance.

ENABLE

Mengaktifkan konfigurasi, database, atau fast-start failover.

EXIT

Keluar dari program.

FAILOVER

Mengubah standby database menjadi primary database.

HELP

Menampilkan deskripsi dan sintaks untuk berbagai perintah.

QUIT

Keluar dari program.

REINSTATE

Mengubah database yang tidak aktif menjadi standby database yang aktif.

REM

Komentar yang diabaikan oleh DGMGRL.

REMOVE

Menghapus konfigurasi, database, atau instance.

SHOW

Menampilkan informasi dari konfigurasi, database, atau instance.

SHUTDOWN

Melakukan shut down terhadap Oracle instance yang sedang berjalan.

START

Menjalankan observer untuk fast-start failover.

STARTUP

Menjalankan database instance Oracle

82 STOP

Menghentikan observer untuk fast-start failover.

SWITCHOVER

Mengganti peran antara primary database dan standby database. Tabel 2.5 Perintah DGMGRL

2.2.3.4.9 Real-Time Apply Menurut Schupmann (2008, p6-2), Jika fitur real-time apply dinyalakan, maka log apply service dapat men-apply redo data langsung seketika diterima, tanpa menunggu standby redo log yang baru untuk diarchive. Ini dapat berdampak pada waktu proses switchover dan failover yang lebih cepat karena standby redo log telah di-apply pada standby database langsung ketika proses failover atau switchover dimulai. Standby redo log diperlukan untuk menggunakan real-time apply. Untuk dapat melakukan proses real-time apply ini, maka gunakan perintah ALTER DATABASE untuk mengaktifkan fitur real-time apply sebagai berikut : •

Untuk physical standby database, dengan perintah : SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE;

•

Untuk logical standby database, dengan perintah : SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

83

Gambar 2.11 Apply Redo Data ke Standby Database dengan Menggunakan Real-Time Apply

Gambar di atas mendeskripsikan konfigurasi Data Guard dengan sebuah tujuan lokal dan sebuah tujuan standby database. Ketika proses Remote File Server (RFS) menuliskan redo data ke standby redo log di standby database, log apply services dapat mengembalikan redo data dari standby redo log seiring dengan pengisian pada standby redo log.

2.2.3.4.10 Role Transition Menurut Shcupmann (2008, p1-5), database Oracle dapat beroperasi pada 2 jenis peran: primary dan standby. Oracle Data Guard memiliki

84 kemampuan Role Transition yang dapat mengubah peran database tersebut dengan operasi switchover atau failover. • Switchovers Menurut Schupmann (2008, p7-4), switchover secara khusus digunakan untuk mengurangi downtime primary database selama kondisi yang direncanakan, seperti upgrade sistem operasi atau perangkat keras, atau upgrade perangkat lunak database Oracle. Switchover berlangsung dalam dua tahap. Pada tahap pertama, primary database yang ada mengalami transisi peran menjadi standby. Pada tahap kedua, standby database mengalami transisi peran menjadi primary database.

• Failovers Failover secara khusus digunakan hanya ketika primary database menjadi tidak tersedia, dan tidak ada kemungkinan perbaikan dalam jangka waktu yang singkat. Tindakan spesifik yang dilakukan selama failover bermacam-macam didasarkan pada apakah physical atau logical standby database dilibatkan di dalam failover, status dari konfigurasi Data Guard ketika failover, dan pada sintaks SQL tertentu yang digunakan untuk failover.

2.2.3.4.11 Fast-Start Failover Menurut Meeks (2005, p3) Fast-start failover adalah sebuah fitur dari Oracle Data Guard 10g release 2 yang secara otomatis, cepat dan teruji

85 melakukan fail over ke sebuah standby database yang telah dirancang dan disinkronisasi ketika terjadi gangguan pada primary database tanpa membutuhkan campur tangan secara manual untuk melakukan failover. Fast-start failover digunakan pada konfigurasi Data Guard dengan pengaturan dari Data Guard Broker ataupun Oracle Enterprise Manager 10g Grid Control. Standby database tujuan akan menjadi primary database yang baru setelah proses fast-start failover dilakukan.

Ada 3 elemen penting dalam sebuah pengaturan fast-start failover seperti : • Primary database • Sebuah standby database tujuan • Fast-start failover observer

Gambar 2.12 Konfigurasi fast-start failover

Observer adalah sebuah proses terpisah yang tergabung dalam client DGMGRL yang secara terus menerus melakukan pengawasan pada primary database dan standby database tujuan untuk kondisi gangguan yang

86 memungkinkan. Berdasarkan gambar di atas ada 3 buah komponen yang saling berkaitan (primary, standby, dan observer) yang mana jika ada 2 komponen yang bisa berkomunikasi dengan satu sama lain, akan menentukan hasil dari fast-start failover. Sebagai contoh, jika primary database tidak dapat diakses, maka observer akan mengkonfirmasikannya dengan standby database tujuan bahwa primary database sedang berada dalam kondisi tidak dapat diakses sehingga standby database tujuan akan disinkronisasikan dengan primary database, dan jika demikian maka fast-start failover akan diinisiasikan dengan standby database tujuan. Jika kondisi demikian tidak terpenuhi maka fast-start failover tidak akan terjadi.

Ada 2 karakteristik penting dari fast-start failover yaitu : •

Dalam konfigurasi fast-start failover tidak diperbolehkan adanya lebih dari sebuah database yang berperan sebagai primary

•

Fast-start failover akan terjadi bila ada sebuah jaminan bahwa tidak ada data yang hilang.

Konfigurasi Fast-Start Failover Secara umum langkah-langkah konfigurasi fast-start failover adalah sebagai berikut : •

Sistem memiliki sebuah primary database dan paling tidak sebuah standby database yang diatur dalam mode maximum availability

87 dengan redo transport jenis LGWR SYNC. Baik primary maupun standby database berada dalam kondisi FLASHBACK DATABASE dan FLASH RECOVERY AREA yang sedang aktif. •

Membuat observer host di sistem yang berbeda dengan primary dan standby database dengan DGMGRL yang sudah terpasang dan harus memiliki koneksi Oracle Net ke primary dan standby database.

•

Menggunakan jenis real-time apply sehingga waktu failover dapat diminimalisasi dan standby database akan tetap sinkron dengan redo log terakhir yang diterima dari primary database.

•

Mengatur parameter FAST-START FAILOVER TARGET dengan menyediakan parameter DB_UNIQUE_NAME dari database yang diinginkan menjadi primary yang baru.

•

Mengatur FailoverThreshold yang berisi waktu dalam satuan detik dimana observer akan mencoba untuk berkomunikasi kembali dengan primary database sebelum melakukan failover.

•

Menggunakan

DGMGRL

atau

Enterprise

Manager

untuk

menyalakan fast-start failover dan observer.

Kejadian-kejadian Yang Menyebabkan Fast-Start Failover Kondisi-kondisi berikut akan menyebabkan fast-start failover dijalankan : •

Gangguan pada database instance.

•

Database berada dalam kondisi SHUTDOWN ABORT.

88 •

Data file berada dalam kondisi offline karena gangguan pada media input/output.

•

Ketika baik observer maupun standby database kehilangan koneksi jaringan ke primary database, dan ketika standby database berada dalam kondisi ‘synchronized’.

2.2.3.4.12 Oracle Recovery Manager Menurut Curtis (1998, p768), Oracle Recovery Manager (RMAN) adalah sebuah tampilan baris perintah yang mempunyai banyak fungsi untuk aktivitas backup dan recovery pada data server. RMAN menjaga hasil-hasil backup yang pernah dilakukan sebelumnya, termasuk tanggal dan waktu backup, file yang termasuk dalam backup, dan lokasi backup. RMAN dapat mengidentifikasi area masalah, memilih metode backup, dan melakukan recovery yang diperlukan.

2.2.3.4.13 Server Aplikasi Menurut Cyran (2005, p10-4), suatu server aplikasi menyediakan akses ke data untuk client. Server aplikasi bertindak sebagai suatu alat penghubung antara client dan satu atau lebih database server, yang menyediakan tambahan tingkat keamanan. Server aplikasi juga dapat melaksanakan sebagian dari proses query untuk client, dengan demikian memindahkan sebagian dari beban dari database server.

89 Server aplikasi menerima identitas dari client ketika sedang melakukan operasi pada database server untuk client itu. Hak server aplikasi terbatas untuk mencegahnya dari melakukan operasi tak dikehendaki dan tidak diperlukan selama operasi client.

2.2.3.4.14 Database server Menurut Cyran (2005, p10-4), suatu database server menyediakan data yang diminta oleh suatu server aplikasi atas nama seorang client. Database server mengerjakan semua dari proses query yang tidak dikerjakan oleh server aplikasi. Database server Oracle dapat memeriksa operasi yang dilakukan oleh server aplikasi atas nama client individu seperti halnya operasi yang dilakukan oleh server aplikasi itu sendiri. Sebagai contoh, suatu operasi client bisa merupakan suatu permintaan untuk informasi untuk ditampilkan pada client, sedangkan suatu operasi server aplikasi bisa merupakan suatu permintaan untuk suatu koneksi kepada database server.

2.2.3.4.15 Inisialisasi Parameter Data Guard Menurut Schupmann (2008, p13-1) inisialisasi instance parameter pada konfigurasi Data Guard dapat dideskripsikan melalui tabel di bawah ini : No. 1.

Nama parameter DB_NAME

Deskripsi Digunakan untuk mengidentifikasi nama primary

90 database 2.

3.

DB_UNIQUE_N

Digunakan

AME

database

LOG_ARCHIVE

Digunakan untuk mengidentifikasi berturut-turut

_CONFIG

nama primary dan standby database yang

untuk

mengidentifikasi

nama

digunakan dalam konfigurasi Data Guard. 4.

LOG_ARCHIVE

Parameter ini hanya berlaku jika menggunakan

_DEST_1

Oracle Enterprise Edition. Digunakan untuk mendeskripsikan tujuan dan atribut dari archived redo log. Atribut LOCATION digunakan untuk menuliskan alamat tujuan dari file sistem lokal pada atribut DB_UNIQUE_NAME digunakan untuk nama database yang dituju. Atribut

VALID_FOR

digunakan

untuk

menggambarkan pada kondisi apa redo transport service akan dijalankan ke alamat yang dituju berdasarkan

nilainya.

Jika

nilainya

ALL_LOGFILES maka baik online redo log maupun standby redo log akan di-archive

ke

alamat tujuan. Jika nilainya ALL_ROLES maka baik primary maupun standby database dapat digunakan untuk tujuan. 5.

LOG_ARCHIVE

Sama seperti penjelasan sebelumnya, namun di

_DEST_2

parameter ini ada beberapa atribut seperti SERVICE

yang

digunakan

untuk

mendeskripsikan service name dari database tujuan ke mana redo data akan dikirimkan yang dalam hal ini adalah primary database. Atribut DB_UNIQUE_NAME digunakan untuk nama database yang dituju.

91 Atribut LGWR menjelaskan bahwa pross LGWR yang digunakan untuk mengumpulkan redo data dan mengirimkannya ke tujuan standby database. Atribut ASYNC menggambarkan bahwa proses LGWR akan berjalan secara asynchronous ke tujuan. Atribut VALID_FOR digunakan untuk menggambarkan pada kondisi apa redo transport service akan dijalankan ke alamat yang dituju berdasarkan

nilainya.

Jika

nilainya

ONLINE_LOGFILES itu berarti alamat tujuan hanya berlaku ketika melakukan archive pada online redo log. Jika nilainya PRIMARY_ROLE maka alamat tujuan hanya berlaku ketika database dijalankan dalam primary role. 6.

LOG_ARCHIVE

Digunakan

_DEST_STATE

ketersediaan dari alamat tujuan log archive di

_1

primary database. Jika nilainya ENABLED maka

untuk

menjelaskan

kondisi

alamat tujuan ini dapat digunakan untuk operasi archiving

berikutnya

baik

secara

otomatis

menjelaskan

kondisi

maupun manual. 7.

LOG_ARCHIVE

Digunakan

_DEST_STATE

ketersediaan dari alamat tujuan log archive di

_2

standby database. Jika nilainya ENABLED maka

untuk

alamat tujuan ini dapat digunakan untuk operasi archiving

berikutnya

baik

secara

otomatis

jika

database

maupun manual. 8.

LOG_ARCHIVE

Parameter

_FORMAT

menggunakan

ini

digunakan redo

log

dalam

kondisi

ARCHIVELOG untuk mendeskripsikan format nama

dari

archived

redo

log.

Nilai

%s

memberikan nomor pada log sequence dan %t

92 memberikan nomor pada thread. 9.

LOG_ARCHIVE

Parameter ini mendeskripsikan jumlah proses

_MAX_PROCES

ARCH maksimum yang akan digunakan.

SES 10.

11.

12.

SERVICE_NAM

Parameter ini berisi nama service yang didukung

ES

oleh Oracle instance.

STANDBY_ARC

Parameter ini berisi alamat tujuan standby

HIVE_DEST

database untuk menyimpan archived redo log.

STANDBY_FIL

Parameter ini digunakan untuk menentukan

E_MANAGEMEN

apakah pengaturan data file berjalan secara

T

manual atau otomatis diatur oleh sistem. Jika nilainya AUTO maka ketika ada perubahan data file di primary database, perubahan yang sama juga akan dilakukan otomatis oleh sistem pada standby database.

13.

REMOTE_LOGI

Parameter ini mendeskripsikan apakah Oracle

N_PASSWORDF

akan memeriksa password file dan berapa banyak

ILE

database yang dapat menggunakan password file tersebut. Jika nilainya adalah EXCLUSIVE maka password file akan dapat digunakan hanya oleh sebuah database dan password file dapat berisi nama selain SYS dan INTERNAL.

14.

FAL_SERVER

Parameter ini berisi service name dari primary database yang sedang aktif.

15.

FAL_CLIENT

Parameter ini berisi service name dari standby database yang sedang aktif.

16.

DB_FILE_NAM

Parameter ini digunakan untuk menkonversi

E_CONVERT

nama sebuah data file baru pada primary database ke nama data file pada standby database. Isinya adalah alamat lokasi data file pada primary database diikuti alamat lokasi data

93 file pada standby database. 17.

LOG_FILE_NA

Parameter ini digunakan untuk menkonversi

ME_CONVERT

nama sebuah log file baru pada primary database ke nama log file pada standby database. Isinya adalah alamat lokasi log file pada primary database diikuti alamat lokasi log file pada standby database.

Tabel 2.6 Inisialisasi Parameter Data Guard

2.2.4

Analisis Cost and Benefit Menurut O’Brien (2003, p695), analisis cost and benefit adalah

mengidentifikasi keuntungan atau manfaat dan kerugian atau biaya dari solusi yang diusulkan. Menurut Peltier (2005, p96), analisis cost-benefit merupakan tahap yang paling penting dalam proses penilaian resiko manapun. Tiap kendali akan berharga sesuatu untuk perusahaan. Biaya itu mungkin saja berupa uang untuk membeli dan memasang kendali tersebut. Mungkin juga sumber daya manusia untuk mengembangkan dan mengimplementasi kendali tersebut, misalnya kebijakan dan standar. Pada setiap peristiwa, cara perusahaan mengerjakan bisnis akan diubah. Cara lain untuk melihat hal ini adalah bahwa budaya perusahaan akan mengalami perubahan. Dibutuhkan kesadaran dari karyawan akan adanya perubahan pada proses kerja. Proses analisis harus mengidentifikasi usaha-usaha perlindungan yang menawarkan perlindungan yang maksimum dengan biaya yang minimum. Dengan kata lain, lebih baik mengimplementasi kendali yang akan mempengaruhi lebih dari satu ancaman.