Pages

Senin, 19 Mei 2014 di 06.28 Diposting oleh Rahardiyan Arya Yudha 0 Comments

Data Movement and Distribution

Loading and Unloading Data
Salah satu cara paling sederhana untuk DBA untuk memindahkan data dari satu tempat ke tempat lain adalah dengan menggunakan memuat dan membongkar utilitas yang datang dengan DBMS. Utilitas LOAD digunakan untuk mengisi tabel dengan data baru, dan utilitas UNLOAD digunakan untuk membaca data dari meja dan memasukkannya ke dalam sebuah file data.

The LOAD Utility
Sebuah utilitas LOAD digunakan untuk melakukan penyisipan massal dari data ke dalam tabel database. Hal ini biasanya dapat mendukung
• Menambahkan baris ke tabel, mempertahankan data saat ini, atau
• Mengganti semua baris yang ada dengan data baru.
Ketika loading data, DBA harus memperhitungkan banyak faktor untuk memastikan sukses. Adalah LOAD utilitas restartable dalam acara itu gagal? Meskipun dibutuhkan lebih banyak waktu untuk menerapkan proses load restartable, lebih mudah untuk mendukung. Untuk proses load menjadi restartable, DBA harus memastikan bahwa setiap berkas kerja yang digunakan dialokasikan dan utilitas LOAD dapat me-restart dari mana ia tinggalkan. Jika
Utilitas LOAD tidak restartable dan terjadi kesalahan yang menghentikan proses beban, DBA harus memilih satu dari dua pilihan:
1. Untuk menghapus data yang telah dimuat, dan mulai lagi dari awal, atau
2. Untuk menentukan apa yang sudah dimuat dan menghapus catatan-catatan dari input data file yang sedang dimuat.

Describing the Input File
Menggunakan utilitas LOAD untuk mengisi tabel membutuhkan file input yang berisi data. DBA harus menentukan tata letak file input ke utilitas LOAD untuk memungkinkannya untuk menerjemahkan data mentah menjadi format yang dibutuhkan untuk penyimpanan dalam database. Hal ini biasanya dilakukan dengan menetapkan tipe data dari setiap kolom bersama dengan awal dan posisi akhir dalam file di mana data yang ada. Beberapa utilitas LOAD juga menyediakan format tertentu yang dapat dimuat dengan spesifikasi terbatas seperti file dipisahkan koma atau file yang dibuat menggunakan UNLOAD atau utilitas EKSPOR.
Utilitas LOAD harus mampu menangani nulls. Nulls biasanya ditangani dengan byte indikator dan klausul khusus untuk memeriksa byte itu. Sebagai contoh, utilitas LOAD bisa menetapkan klausul seperti :

LOAD . . . STATUSPOSITION (20:25) CHAR(6) NULLIF(26)='F' . . .

Efficient Loading
Hal ini biasanya ide yang baik untuk membuat semua indeks diperlukan sebelum loading data ke dalam tabel. Utilitas LOAD biasanya lebih efisien dalam mengisi indeks selama proses beban daripada membuat indeks baru untuk meja penuh diisi. Tentu saja, DBA harus memverifikasi ini menjadi kasus untuk DBMS dan versi yang digunakan.
Jika utilitas LOAD mampu melakukan tugas secara paralel, DBA harus mengambil keuntungan dari ini ketika sejumlah besar data sedang dimuat. Utilitas LOAD mungkin mampu menerima beberapa file masukan untuk memuat bersamaan ke dalam segmen yang berbeda atau partisi meja, atau mungkin mampu membangun beberapa indeks secara paralel daripada membangun masing-masing secara berurutan. Operasi paralel seperti ini dapat meningkatkan jumlah CPU yang diperlukan untuk memuat data sekaligus mengurangi waktu yang telah berlalu keseluruhan untuk LOAD untuk menjalankan.

The UNLOAD Utility
Informasi dalam tabel database sering harus dipindahkan atau disalin ke lokasi lain. Sebagai contoh, Anda mungkin ingin memindahkan data ke database yang berbeda, dari tabel ke file sekuensial untuk pengolahan eksternal, atau mungkin ke sistem database relasional atau platform lain. Database tertentu memerlukan perubahan skema objek database yang akan turun dan diciptakan-dan ketika objek dijatuhkan, begitu juga data. Oleh karena itu, Anda perlu untuk membongkar data sebelum membuat perubahan objek database. Mungkin Anda hanya ingin mengekstrak subset dari baris dari tabel untuk digunakan sebagai data uji. Bahkan untuk membenahi objek database biasanya membutuhkan data yang akan diturunkan, dioptimalkan, kemudian reloaded.
Tujuan dari utilitas UNLOAD adalah untuk membaca data dari database dan menulis ke file output data. Tanpa utilitas UNLOAD, pengguna database terpaksa menggunakan pernyataan SQL SELECT yang dikeluarkan oleh fasilitas interaktif SQL, laporan penulis, atau program aplikasi untuk membongkar data. Namun,
metode ini rawan kesalahan dan lambat untuk sejumlah besar data. Selain itu, membutuhkan pengembang untuk kode program aplikasi untuk membuat file terlalu tidak fleksibel dan memakan sebagian besar kebutuhan untuk database produksi waktu. Dengan demikian, banyak DBMSs menyediakan utilitas UNLOAD untuk memberikan kemampuan kecepatan tinggi dan fleksibilitas untuk melakukan sebagian besar tugas data pergerakan massal yang dilakukan oleh DBA.
EXPORT and IMPORT
Mirip dengan utilitas UNLOAD, sebuah utilitas EKSPOR membaca data dari meja dan menempatkannya ke file eksternal. Utilitas IMPOR akan membaca file eksternal yang dibuat oleh utilitas EKSPOR dan memasukkan data ke dalam tabel.
Impor dan ekspor fasilitas biasanya bekerja sama dengan lebih dari sekedar data, meskipun. Kadang-kadang file data EKSPOR berisi skema untuk meja bersama dengan data. Dalam kasus tersebut, utilitas IMPOR dapat membuat tabel dan mengimpor data menggunakan hanya file data EKSPOR. Kadang-kadang file EKSPOR berisi lebih dari hanya satu meja. Beberapa fasilitas EKSPOR memungkinkan DBA untuk menentukan tabel tunggal, dan kemudian ikuti hubungan untuk tabel yang untuk mengekstrak semua file yang terkait dan data.
Beberapa fasilitas IMPOR / EKSPOR menyediakan fitur UNLOAD seperti untuk sampel, bagian, dan membatasi data yang diekspor (dan impor). Bedanya, meskipun, adalah kemampuan untuk melakukan fungsi-fungsi seperti di beberapa tabel dan memelihara data referentially utuh.

Tidak setiap DBMS menawarkan impor dan ekspor utilitas. Beberapa vendor pihak ketiga (terutama Princeton Sc) menyediakan produk impor dan ekspor.

di 05.03 Diposting oleh Rahardiyan Arya Yudha 0 Comments

Data and Storage Management

Semua DBMS mengandalkan data file untuk menyimpan data dan file-file. Semuanya ini berada pada media penyimpanan, atau perangkat. Dnegan demikian storage manajemen merupakan bagian penting dari operasi database yang diperlukan oleh DBA.

Storage Management Basics
Belum tentu storage manajement yang baik pada suatu perusahaan akan baik pula jika dipakai oleh perusahaan lain. Jadi DBA harus mengevaluasi banyak produk, teknologi dan vendor yang menyediakan solusi penyimpanan jika di[erlukan.
Untuk teknologi storage manajement yang dominan adalah disk drive, namun karena rentan terhadap error dan sebagainya, maka digantikan oleh Moderent DBMS Disk Usage, salah satunya adalah RAID(Redudant Arrays of Inexpensive Disk) yaitu menggabungkan beberapa disk drive menjadi seakan-akan 1 disk drive. Dengan Motode ini bisa mengatasi MTBF(Meantime Bettwen Failure).
Tujuan yang harus dipertimbangkan saat membangun storage sistem :
·         Mencagah kehilangan data yang paling prioritas
·         Memastikan bahwa kapasitas yang tersedia memadai dan solusi untuk penyimpanan dapat dengan mudah memenuhi kebutuhan penyimpanan yang terus bertambah
·         Memilih solusi yang menyediakan akses cepat ke data
·         Memilih solusi penyimpanan yang dapat diperbaiki dengan cepat ketika terjadi error
·         Memilih solusi penyimpanan dimana anda dapat menambahkan atau mengganti disk tanpa outage.
  

File and Data Set
Ada banyak masalah penyimpanan yang harus diselesaikan oleh DBA sebelum membuat DataBase.
DBA dapat memilih untuk menggunakan beberapa perangkat penyimpanan untuk file-file yang berbeda :
·         Sejajarkan persyaratan kenerja file dengan perangkat disk yang sesuai
·         Index terpisah dari data karena alas an kinerja.
·         Mengisolasi log transaksi pada perangkat yang terpisah dan sangat cepat
·         Isolasi sementara dan file bekerja pada volume tunggal

·         Sebarkan data di beberapa perangkat untuk memfasilitasi akses parallel

File Placement on Disk

DBA harus menentukan penempatan optimal file pada perangkat disk. Pada saat ini, DBA dapat mencapai keuntungan kinerja hanya dengan memindahkan file dari satu perangkat disk fisik yang lain . Salah satu teknik yang umum adalah untuk menempatkan file indeks dan file data pada perangkat disk yang terpisah . Dengan memisahkan indeks dari data yang diindeks , operasi I / O dapat dibuat lebih efisien karena fisik read - write lengan perangkat disk tunggal tidak perlu memindahkan beberapa kali . Untuk alasan yang sama , menempatkan data yang diakses oleh operasi yang sama pada perangkat disk fisik terpisah adalah teknik penempatan file lain yang umum dan menyediakan jenis yang sama keuntungan kinerja sebagai memisahkan indeks dari data.

Tentu saja, penempatan file yang tepat menjadi kurang menguntungkan dengan munculnya perangkat penyimpanan modern. Jika DBMS menggunakan perangkat penyimpanan modern yang menciptakan disk virtual dengan menyebarkan data di beberapa disk fisik ( RAID ) penempatan berkas eksplisit adalah buang-buang waktu . Bahkan jika DBA menetapkan dua perangkat disk yang berbeda , array disk fisik akan menempatkan file di beberapa disk . Jadi , sebagai DBA , jangan buang waktu pada penempatan file yang tepat bila menggunakan teknologi penyimpanan array yang modern seperti RAID .

Terlepas dari jenis penyimpanan yang digunakan , pastikan untuk menempatkan log transaksi pada perangkat yang terpisah dari database untuk backup log transaksi secara independen dari database . Ini adalah ide yang baik karena meningkatkan pemulihan secara keseluruhan .

Tempatkan log transaksi pada perangkat yang terpisah dari database .

Setiap DBMS menyediakan pilihan penyimpanan yang berbeda . Microsoft SQL Server menawarkan filegroups , DB2 untuk OS/390 menyediakan STOGROUPS , dan Sybase menawarkan Segmen (lihat "Segmen Sybase " sidebar ) . Pastikan untuk memahami mekanisme DBMS Anda gunakan untuk berinteraksi dengan subsistem penyimpanan dan disk untuk membuat file database . File database tidak benar dibuat bisa menjadi penyebab signifikan dari kinerja yang buruk .

Beberapa organisasi memilih untuk menerapkan sistem yang dikelola penyimpanan, atau SMS. Dengan SMS, lokasi sebenarnya dari file dan data set ditentukan oleh sistem, bukannya DBA atau administrator storage. Dengan teknologi disk yang efisien baru yang tersedia, SMS adalah pilihan yang lebih layak daripada di masa lalu. 

Raw Partitions vs File Systems

Sebuah partisi mentah adalah jenis yang disukai perangkat fisik untuk memilih ketika deploying database pada database server berbasis UNIX . Sebuah partisi mentah hanyalah sebuah perangkat disk mentah tanpa sistem operasi atau sistem file yang diinstal .

Partisi mentah disukai karena cara UNIX buffer menulis ketika sistem file digunakan . Ketika menulis buffer oleh sistem operasi , DBMS tidak dapat mengetahui apakah data telah fisik disalin ke disk atau tidak . Ketika DBMS menulis data dari cache ke disk , UNIX dalam semua kemungkinan , tidak akan. Jika terjadi kegagalan , data dalam database menggunakan file sistem disk mungkin tidak 100 % dapat dipulihkan . Ini harus dihindari .

Jika partisi baku yang digunakan, data akan secara fisik ditulis ke disk tanpa intervensi sistem operasi . Selain itu, ketika menggunakan partisi mentah , DBMS adalah lebih mampu untuk memastikan bahwa ruang yang cukup tersedia dan menulis halaman alokasi sesuai kebutuhan . Bila menggunakan file disk , UNIX tidak akan preallocate ruang yang dibutuhkan ; itu malah akan membuat file jarang. Hanya halaman alokasi ditulis . Jika aplikasi lain yang bersaing untuk ruang fisik yang sama , Anda mungkin tidak memiliki banyak ruang untuk menyimpan data database seperti yang Anda percaya Anda lakukan .
Kelemahan ke perangkat baku adalah sulitnya melacak file database . Karena file yang tidak dialokasikan dengan menggunakan sistem operasi atau file sistem , tidak mungkin untuk melacak mereka menggunakan sistem operasi dan file sistem perintah . Namun, pihak ketiga perangkat lunak manajemen penyimpanan ini bisa digunakan untuk berkeliling masalah ini .

Kelemahan ke perangkat baku adalah sulitnya melacak file database .

Pada UNIX , pastikan untuk selalu menggunakan partisi baku untuk log transaksi , bahkan jika Anda menggunakan sistem file untuk file database . Hal ini biasanya bijaksana untuk menggunakan partisi mentah untuk database produksi , juga. Namun, jika integritas tidak menjadi masalah ( misalnya , dalam lingkungan pengembangan ) , database dapat dibuat pada sistem file disk demi kesederhanaan.

Temporary Database Files

DBMSs modern memberikan kemampuan untuk membuat objek database sementara yang ada hanya selama lingkup transaksi tertentu. Benda-benda ini berisi data sementara yang bersifat sementara dan tidak memerlukan penyimpanan persisten jangka panjang. Namun, objek database ini masih memerlukan beberapa bentuk penyimpanan persisten jangka pendek untuk digunakan selama keberadaan mereka.

Sementara objek database memerlukan beberapa bentuk penyimpanan persisten jangka pendek.

Tergantung pada DBMS, DBA perlu menetapkan perangkat disk dan jumlah penyimpanan untuk digunakan oleh objek database sementara.

Space Management

Sebagai modifikasi yang diterapkan pada tabel database , database akan tumbuh dalam ukuran . Ingat juga, bahwa database tidak hanya bagian data ( tabel dan indeks ) , tetapi juga bagian log . Adalah bijaksana untuk secara berkala dan konsisten memantau penggunaan ruang database . Hal ini dapat dilakukan dengan menggunakan alat-alat dan utilitas yang disediakan dengan DBMS , perangkat lunak manajemen penyimpanan , atau alat database pihak ketiga . Sebagai DBA , Anda harus dapat melacak berikut :
·         Jumlah luasan sekunder
·         fragmentasi perangkat
·         informasi penggunaan Fragment
·         Ruang bebas yang tersedia
·         Segmen atau partisi ukuran
·         Tabel dan indeks dialokasikan per segmen
·         Jumlah tempat khusus yang saat ini tidak terpakai
·         Obyek mendekati " keluar dari ruang " Kondisi





di 04.12 Diposting oleh Rahardiyan Arya Yudha 0 Comments

Database Security


Database security merupakan suatu proteksi terhadap pengrusakan data dan pemakaian data oleh pemakai yang tidak punya kewenangan.

Tingkatan Pada Keamanan Database :
Fisikal > lokasi-lokasi dimana terdapat sistem komputer haruslah aman secara fisik terhadap serangan perusak.
Manusia > wewenang pemakai harus dilakukan dengan berhati-hati untuk mengurangi kemungkinan adanya manipulasi oleh pemakai yang berwenang
Sistem Operasi > Kelemahan pada SO ini memungkinkan pengaksesan data oleh pihak tak berwenang, karena hampir seluruh jaringan sistem database menggunakan akses jarak jauh.
Sistem Database > Pengaturan hak pemakai yang baik.

Tingkatan Pada Keamanan Database 
Keamanan Data :
1. Otorisasi :
Pemberian Wewenang atau hak istimewa (prrvilage) untuk mengakses sistem atau obyek database.
Kendali otorisasi/hak akses dapat dibangun pada perangkat lunak dengan 2 fungsi : Mengendalikan sistem atau obyek yang dapat diakses dan Mengendalikan bagaimana pengguna menggunakannya.
Sistem administrasi yang bertanggungjawab untuk memberikan hak akses dengan membuat account pengguna.
2. Tabel View :
Merupakan metode pembatasan bagi pengguna untuk mendapatkan model database yang sesuai dengan kebutuhan perorangan. Metode ini dapat menyembunyikan data yang tidak digunakan atau tidak perlu dilihat oleh pengguna.
Contoh pada Database relasional, untuk pengamanan dilakukan beberapa level :
a. Relasi : pengguna diperbolehkan atau tidak diperbolehkan mengakses langsung suatu relasi.
b. View : pengguna diperbolehkan atau tidak diperbolehkan mengakses data yang terapat pada view.
c. Read Authorization : pengguna diperbolehkan membaca data, tetapi tidak dapat memodifikasi.
d. Insert Authorization : pengguna diperbolehkan menambah data baru, tetapi tidak dapat memodifikasi data yang sudah ada.
e. Update Authorization : pengguna diperbolehkan memodifikasi data, tetapi tidak dapat menghapus data.
f. Delete Authorization : pengguna diperbolehkan menghapus data.
Untuk Modifikasi data terdapat otorisasi tambahan :
a). Index Authorization : pengguna diperbolehkan membuat dan menghapus index data.
b). Resource Authorization : pengguna diperbolehkan membuat relasi-relasi baru.
c). Alteration Authorization : pengguna diperbolehkan menambah/menghapus atribut suatu relasi.
d). Drop Authorization : pengguna diperbolehkan menghapus relasi yang sudah ada.
3. Backup data dan recovery :
Backup : proses secara periodik untuk mebuat duplikat ari database dan melakukan logging file (atau program) ke media penyimpanan eksternal.
Jenis Pemulihan :
- Pemulihan terhadap kegagalan transaksi : Kesatuan prosedur alam program yang dapat mengubah / memperbarui data pada sejumlah tabel.
- Pemulihan terhadap kegagalan media : Pemulihan karena kegagalan media dengan cara mengambil atau memuat kembali salinan basis data (backup)
- Pemulihan terhadap kegagalan sistem : Karena gangguan sistem, hang, listrik terputus alirannya.
Fasilitas pemulihan pada DBMS :
a. Mekanisme backup secara periodik
b. fasilitas logging dengan membuat track pada tempatnya saat transaksi berlangsung dan pada saat database berubah.
c. fasilitas checkpoint, melakukan update database yang terbaru.
d. manager pemulihan, memperbolehkan sistem untuk menyimpan ulang database menjadi lebih konsisten setelah terjadinya kesalahan.
4. Kesatuan data dan Enkripsi :
a. Enkripsi : keamanan data
b. Integritas : metode pemeriksaan dan validasi data (metode integrity constrain), yaitu berisi aturan-aturan atau batasan-batasan untuk tujuan terlaksananya integritas data.
c. Konkuren : mekanisme untuk menjamin bahwa transaksi yang konkuren pada database multi user tidak saling menganggu operasinya masing-masing. Adanya penjadwalan proses yang akurat (time stamping).

Senin, 12 Mei 2014 di 04.42 Diposting oleh Rahardiyan Arya Yudha 0 Comments

Resume Disaster Planning

The Need for Planning
Disaster recovery planning, juga disebut contingency planning, adalah proses mempersiapkan
aset organisasi anda dan operasi dalam kasus bencana.
Tapi apa itu bencana? Sungard Recovery
Services (1995) memberikan definisi yang baik dari bencana: apapun yang tidak direncanakan, kehilangan data dari aplikasi bisnis karena kurangnya kemampuan pemrosesan komputer selama lebih dari periode 48-jam.
Definisi Anda sendiri mungkin lebih atau kurang ketat berkaitan dengan rentang waktu, tetapi dasar
definisi adalah satu suara.
Anda harus mengenali potensi bencana dan memahami konsekuensinya. Bagaimana bencana ini mungkin mempengaruhi bisnis Anda adalah satu-satunya tujuan perencanaan pemulihan bencana. Jika bisnis Anda adalah di pantai, maka kemungkinan badai, banjir, dan tornado meningkat. Jika bisnis Anda terletak di utara, badai salju dan cuaca dingin yang parah akan menimbulkan lebih banyak risiko.
Pemulihan bencana database harus menjadi komponen integral dari rencana pemulihan bisnis Anda secara keseluruhan. Sebuah rencana pemulihan bencana harus dalam lingkup global. Ini harus menangani masalah bisnis seperti lokasi alternatif untuk melakukan bisnis, metode komunikasi untuk menginformasikan karyawan lokasi dan prosedur baru, dan langkah-langkah publisitas untuk menginformasikan kepada pelanggan bagaimana untuk bertransaksi bisnis dengan perusahaan pasca bencana. Ini harus mengembalikan infrastruktur TI. Akhirnya, dan yang paling penting untuk diskusi kita, komponen dari rencana itu harus untuk pemulihan database dan operasi DBMS.

 Risk and Recovery
Mengelompokkan aplikasi ke dalam kelompok berikut untuk menentukan aplikasi yang memiliki dampak terbesar jika mereka tidak tersedia :
· Very critical applications.
Aplikasi yang paling kritis dalam organisasi Anda akan memerlukan data berjalan pada saat pemulihan. Aplikasi ini yang paling sulit yang mengembangkan disaster plan  karena langkah-langkah lebih banyak diperlukan untuk off-site backup dan recovery. Selain itu, aplikasi yang paling kritis di toko Anda akan menjadi yang pertama yang harus dibuat operasional pada situs pemulihan. Cobalah untuk membatasi jumlah aplikasi yang ditunjuk sebagai sangat kritis; ada lebih dari setengah lusin atau lebih akan diatur dalam situasi bencana.
·Business-critical applications.
Aplikasi bisnis yang penting bagi organisasi Anda.Dan harus menjadi kelompok berikutnya yang pulih setelah very critical applications. Sebuah Business-critical applications yang sering memerlukan data saat ini, tetapi mungkin tidak tersedia di lokasi terpencil dalam beberapa hari pertama. Sebagai contoh, perhatikan aplikasi untuk
penyedia layanan telepon. Sistem yang memberikan layanan telepon akan menjadi aplikasi yang sangat kritis; tagihan pelanggan akan aplikasi bisnis penting.
·         Business-critical applications
Business-critical applications membedakan diri dari Business-critical applications dengan kedekatan atau kebutuhan mata uang data. Kelompok aplikasi ini, meskipun penting, tidak perlu tersedia segera. Namun, jika bencana berlangsung selama seminggu atau lebih, bisnis membutuhkan aplikasi. Aplikasi kritis tidak boleh dipulihkan sampai aplikasi yang sangat kritis dan kritis-bisnis up. Persyaratan aplikasi ini bervariasi dari up-to-date data mungkin hari-tua atau minggu tua.
·     Required Applications
Required Applications tidak terlalu penting tetapi harus didukung sehingga mereka dapat dipulihkan di lokasi terpencil jika diperlukan. Data dari cadangan yang tersedia terakhir biasanya cukup untuk mendukung aplikasi tersebut.
·         Noncritical applications

Aplikasi noncritical tidak perlu didukung dalam hal bencana. Sangat sedikit aplikasi jatuh ke dalam kategori ini-jika aplikasi tidak penting, mengapa itu dikembangkan di tempat pertama?

The Written Plan
Menuliskan prosedur dan kebijakan khusus yang harus diikuti untuk pemulihan bencana off-site memiliki beberapa manfaat :
·   Hal ini menyarankan Anda untuk merumuskan tindakan eksplisit yang harus diambil jika terjadi bencana.
·   Ini membuat Anda menjadikan tindakan ini menjadi langkah-langkah berurutan yang spesifik.
·   Memaksa Anda untuk lebih spesifik tentang alat-alat yang akan digunakan dan informasi cadangan yang tepat untuk diperlukan.
·   Dokumen lokasi di mana semua informasi yang diperlukan disimpan dan bagaimana itu harus tersedia di situs recovery.
·   Memberikan cetak biru bagi orang lain untuk mengikuti, dalam kasus mereka yang paling akrab dengan rencana tidak tersedia.

Senin, 07 April 2014 di 18.28 Diposting oleh Rahardiyan Arya Yudha 0 Comments



Resume Pertemuan VII
Application Performance


Application Performance, berfokus pada tuning dan mengoptimalkan kode aplikasi dan SQL, serta memastikan aplikasi berinteraksi dengan DBMS secara tepat dan efisien.
Beberapa hal yang harus kita perhatikan ketika kita men-Desain aplikasi :
  1. Jenis SQL
  2. Bahasa Pemrograman
  3. Desain Transaksi dan Pengolahan
  4. Mengunci Strategi
  5. COMMIT strategi
  6. Batch Strategi
  7. Pemrosesan Online
Untuk berfungsi dengan baik, optimasi harus mengevaluasi dan menganalisa berbagai faktor:
1.      CPU and I/O
Berdasarkan informasi CPU, optimasi dapat di perkiraan dari waktu CPU yang dibutuhkan untuk menjalankan query menggunakan setiap jalur akses yang dioptimalkan secara analisis.

2.      Database Statistics
Sebuah DBMS relasional menyediakan program utilitas atau perintah untuk mengumpulkan statistik tentang obyek database dan menyimpannya untuk digunakan oleh optimizer (atau oleh DBA untuk memantau kinerja).

3.      Query Analysis
Selama analisis query, optimizer analisis aspek pernyataan SQL dan sistem database, seperti:
Ø  Jika ada Indeks yang dapat digunakan
Ø  Berapa banyak predikat (klausa WHERE)
Ø  Fungsi yang harus dijalankan
Ø  Apakah SQL menggunakan OR atau AND
Ø  Bagaimana DBMS memproses setiap komponen dari pernyataan SQL
Ø  Berapa banyak memori yang telah ditugaskan untuk cache data dan digunakan oleh tabel dalam pernyataan SQL
Ø  Berapa banyak memori yang tersedia untuk menyortir jika query membutuhkan semacam sebuah perintah

4.      Density
Density adalah persentase rata-rata nilai-nilai duplikat yang disimpan dalam kolom kunci indeks dan dicatat sebagai persentase.

5.      Joins
Ketika beberapa tabel diakses, optimizer angka keluar bagaimana untuk menggabungkan tabel dengan cara yang paling efisien. Menggabungkan informasi dari beberapa tabel dikenal sebagai bergabung. Ketika menentukan jalur akses untuk bergabung, optimizer harus menentukan urutan di mana tabel akan bergabung, menghitung estimasi biaya keseluruhan dari setiap jalur akses, dan memilih bergabung metode untuk query tertentu.

6.      Join Order & Access Path Join
Di masing-masing ulasan Optimasi bergabung dalam query dan analisis statistik yang tepat untuk menentukan urutan optimal di mana tabel harus diakses untuk mencapai bergabung. ( Join Order)
Beberapa jenis Umum Akses Data adalah tabel scan ( Access Path Join), seperti Table Scans.

7.      Indexed Access
Dari sekian banyak keputusan yang harus dibuat oleh optimasi, salah satu yang paling penting bagi kinerja query adalah apakah indeks akan digunakan untuk memenuhi permintaan??.
Ada dua tipe dasar indeks scan: Indeks pencocokan scan dan scan indeks nonmatching.

8.      Hashed Access & Paralel Access
Mengelompokkan data dengan algoritma kedalam tabel yang telah ditentukan. ( Hashed Access )
Optimasi dalam relasional ,dapat memilih untuk menjalankan query secara paralel. Ketika permintaan paralelisme dipanggil oleh DBMS, beberapa tugas secara simultan dipanggil untuk mengakses data. ( Paralel Access )

9.      Additional optimization consideration
   Ø  View access
Ketika optimazer menentukan access dari queri view maka ditentukan juga cara                        mengatasi tampilan SQL
   Ø   Query rewrite
Menulis ulang queri dg formulasi yang berbeda dan menentukan access path       yang lebih baik
   Ø  Rule-based Optimization
Mendasarkan keputusan dengan perhitungan estimasi biaya
   Ø  Reviewing access path
Meninjau pernyataan SQL dan memperbaikinya sesuai dengan sifat access path
   Ø  Forcing access paths
Jalur akses khusus yang disediakan oleh DBMS

10.  SQL Coding & Tuning For Efficiency
DBA bertanggung jawab untuk memastikan bahwa langkah-langkah berikut akan terjadi untuk setiap pernyataan SQL dalam suatu organisasi, yakni :
Ø  Mengidentifikasi persyaratan data bisnis.
Ø  Pastikan bahwa data yang dibutuhkan tersedia di dalam database yang ada.
Ø  Menerjemahkan kebutuhan bisnis ke dalam SQL.
Ø  Uji SQL untuk akurasi dan hasil.
Ø  Review jalur akses untuk kinerja.
Ø  Tweak SQL untuk jalur akses yang lebih baik.
Ø  Petunjuk optimasi Code.
Ø  Ulangi langkah 4 sampai 7 sampai kinerja dapat diterima.
Ø  Ulangi langkah 8 kapanpun masalah kinerja timbul atau versi DBMS baru dipasang.
Ø  Ulangi seluruh proses setiap kali perubahan kebutuhan bisnis.

Senin, 31 Maret 2014 di 09.36 Diposting oleh Rahardiyan Arya Yudha 0 Comments


Resume Pertemuan VI
System & Database Performance

Definisi Sistem (Menurut Para Ahli)
1.    Menurut Ludwig Von Bartalanfy
Sistem merupakan seperangkat unsur yang saling terikat dalam suatu antar relasi diantara unsur-unsur tersebut dengan lingkungan.
2. Menurut Anatol Raporot
           Sistem adalah suatu kumpulan kesatuan dan perangkat hubungan satu sama lain.
Jadi Defini Sistem adalah sekumpulan unsur / elemen yang saling berkaitan dan saling mempengaruhi dalam melakukan kegiatan bersama untuk mencapai suatu tujuan.

Definisi Performance (Kinerja)
·         Kinerja merupakan seperangkat hasil yang dicapai dan merujuk pada tindakan pencapaian serta pelaksanaan sesuatu pekerjaan yang diminta (Stolovitch and Keeps: 1992).
·         Kinerja sebagai kualitas dan kuantitas dari pencapaian tugas-tugas, baik yang dilakukan oleh individu, kelompok maupun perusahaan (Schermerhorn, Hunt and Osborn: 1991).

System Performance
System Performance (Kinerja Sistem) adalah kemampuan kerja dari sekumpulan elemen yang saling berkaitan untuk mencapai suatu tujuan.


System Performance Database
System Performance Database (Kinerja Sistem Basis Data) ialah kemampuan kerja dari sekumpulan komponen basis data yang saling berkaitan atau berhubungan untuk mencapai suatu tujuan dari basis data itu sendiri.



Tujuan Database
Setiap manajemen dalam merancang dan menyusun database harus mempunyai tujuan, yaitu:
  1. Membuat agar user mudah mendapatkan data.
  2. Menyediakan tempat penyimpanan data yang relevan.
  3. Menghapus data yang berlebihan.
  4. Melindungi data dari kerusakan fisik.

Faktor Yang Mempengaruhi Kinerja Database :
5 faktor yang mempengaruhi Kinerja Database :
  1. Workload (Beban Kerja) : Seperti transaksi online, analisis data warehouse, dan sistem command yang datang beberapa kali.
  2. Throughput : Merupakan kemampuan sebuah computer dalam memproses data.
  3. Resources (Sumber Daya) : Contohnya : Software and Hardware.
  4. Optimization (Optimasi) : Optimasi database, memformula query.
  5. Contention (Kres) : Yaitu kondisi di mana dua atau lebih komponen dari beban kerja sedang mencoba untuk menggunakan satu sumber daya dengan cara yang bertentangan.

Sumber : http://sitimukaromah4.wordpress.com/

Database Performance Tuning
Adalah aktivitas dan prosedur yang dirancang untuk mempercepat respon sistem database

Teknik Tuning dan Optimizing
1.    Partitioning
·      Mempartisi database dapat mempercepat pencapaian proses paralel
·      Proses paralel merupakan proses untuk menggunakan perintah jamak untuk mengakses database
·      Proses paralel digunakan untuk mengurangi elapsed time  query database

2.    Raw Partition VS File System
·      Raw partition lebih sering digunakan daripada menyimpan data di cache file system
·      Karena cache DBMS akan langsung menuliskan data tanpa intervensi dari file system
·      Tidak dianjurkan untuk menambahkan cache DBMS dengan cache yang lain



3.    Indexing
·      Index digunakan untuk :
a.    Menemukan baris untuk nilai tertentu pada sebuah atau banyak kolom
b.    Mempermudah operasi JOIN
c.    Menghubungkan data antara tabel
d.    Agregasi data
e.    Mengurutkan data sesuai perintah query
·      Dengan index mempermudah proses pengolahan data

4.    Denormalisasi
·      Kebalikan dari normalisasi
·      Salah satu teknik untuk meningkatkan performa dengan menambahkan data yang redundant atau dengan mengelompokkan data
·      Dapat diterapkan dengan:
a.    Prejoined table
b.    Report table
c.    Mirror table
d.    Split table
e.    Combined tables
f.     Speed tables
Storing redundant data
Storing repeating groups
Storing derivable data

5.    Clustering
Tabel yang sudah dikelompokkan akan menyimpan data secara fisik di dalam sebuah disk sesuai dengan kolomnya masing-masing



6.    Free Space
·      Terkadang disebut dengan Fill Factor
·      Merupakan ruang kosong yang disediakan untuk menambah data baru
·      Parameter yang biasa digunakan adalah PCTFREE dan FREEPAGE
·      Tugas DBA adalah memastikan jumlah ruang kosong yang tepat untuk setiap tabel

7.    Compression
·      Untuk meringkas database
·      Dapat mengurangi penggunaan ruang penyimpanan data
·      Keuntungan : menghemat ruang penyimpanan dan mengurangi waktu pemrosesan data
·      Kekurangan : Biaya tambahan untuk melakukan compress dan decompress data
·      Tidak semua table perlu dicompress

8.  File Placement and Allocation
Yang harus diperhatikan ketika mengalokasikan data :
a.    Jika memungkinkan memisahkan data dengan index
b.    Memisahkan file untuk tabel yang sering diakses bersama
c.    Jika data dari tabel disimpan di dalam halaman yang berbeda, diutamakan untuk memisahkan disk penyimpan untuk mempermudah dan mengoptimalkan operasi yang parallel

9.  Page size
·      Beberapa DBMS membatasi jumlah page yang digunakan untuk menyimpan data

·      Karena itu DBA harus dapat menghitung jumlah halaman yang dibutuhkan berdasarkan jumlah baris data, jumlah baris per halaman, dan jumlah ruang kosong yang dibutuhkan

10.    Reorganization
·      Memaksimalkan availabilitty dan reliability data
·      Me-reorganisasi database berarti merestrukturisasi objek database, memaksimalkan availability dan kecepatan, serta  mengefisiensi fungsi database



Source : - http://sitimukaromah4.wordpress.com/
-http://www.google.com/url?sa=t&rct=j&q=pengertian+database+performance&source=web&cd=1&cad=rja&uact=8&ved=0CCcQFjAA&url=http%3A%2F%2Fyesinovia.files.wordpress.com%2F2012%2F03%2F7-database-performance-tuning.ppt&ei=u5M5U6n6MYmDiQe904CYBA&usg=AFQjCNHB-I_i8wUnW4HENbSrH3hgGg7yPw&sig2=3n2MCtZGNh6r4QduQvIXjg

Langganan: Postingan (Atom)

    About Me

    Rahardiyan Arya Yudha
    Lihat profil lengkapku

    Followers