7 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.
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 :
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
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.
• 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.
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 proses-proses 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
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
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
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
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 meng-apply 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
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. Server-managed 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
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
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.
• 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 = mweishan-dell)(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
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 Curtis-King (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
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 tersebut mewakili lokasi-lokasi yang menjadi pertimbangan perusahaan untuk meminimalisasi resiko, yang 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.
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 memperbolehkan sistem untuk mengembalikan database 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
(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.
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 perundang-undangan.
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
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 komponen-komponen 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.
• Tidak ada dasar untuk analisis cost-benefit dari pengurangan resiko.
2.2.2.5 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
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.
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 :
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.
Penyebab Ketidaktersediaan Data
Tidak Direncanakan Terencana
Gangguan pada komputer Gangguan pada Storage Kesalahan manusia Kerusakan Data Gangguan pada lokasi Perubahan sistem Perubahan Data
• 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
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 bermacam-macam 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.
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
read-only 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
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 command-line 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
Tipe Gangguan Keuntungan
Waktu Recovery
Gangguan pada komputer
Fast-start failover dan fast
connection failover
Maksimum 5 menit
Gangguan pada storage
Fast-start failover dan fast
connection failover
Maksimum 5 menit
Kerusakan data Validasi otomatis redo block sebelum mereka di-apply, menjalankan fast failover ke standby database yang tidak rusak
Maksimum 5 menit
Gangguan pada lokasi
Fast-start failover dan fast
connection failover
Maksimum 5 menit
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.
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
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
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.
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 proses-proses 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.
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.
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
Protection
Resiko kehilangan data saat terjadi bencana
Mekanisme pengiriman
redo data
Maximum
Protection
Tidak ada kehilangan data
Synchronous
(LGWR SYNC) Maximum
Availibility
Tidak ada kehilangan data
Synchronous
(LGWR SYNC) Maximum
Performance
Kehilangan data minimal biasanya hanya beberapa
detik
Asynchronous (LGWR
ASYNC) or ARCH 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
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
