POST TEST OPTIMASI QUERY


1. Menurut anda pentingkan melakukan  optimasi 

     query dalam memanajemen  database?

     Penting Karena semua hal harus di lakukan dengan optimum

    2. Buat ringkasan dari materi SQL Tuning atau

     Optimasi Queri.

OPTIMASI QUERY
Dilakukan dengan mengetahui bagaimana rencana eksekusi query yang “baik” rencana dari optimasi

Optimasi Query adalah suatu proses untuk menganalisa query untuk menentukan sumber-sumber apa saja yang digunakan oleh query tersebut dan apakah penggunaan dari sumber tersebut dapat dikurangi tanpa merubah output. Atau bisa juga dikatakan bahwa optimasi query adalah sebuah prosedur untuk meningkatkan strategi evaluasi dari suatu query untuk membuat evaluasi tersebut menjadi lebih efektif. Optimasi query mencakup beberapa teknik seperti transformasi query ke dalam bentuk logika yang sama, memilih jalan akses yang optimal dan mengoptimumkan penyimpanan data.
Tujuan dari optimasi query adalah menemukan jalan akses yang termurah untuk meminimumkan total waktu pada saat proses sebuah query. Untuk mencapai tujuan tersebut, maka diperlukan optimizer untuk melakukan analisa query dan untuk melakukan pencarian jalan akses.


Query dapat dilakukandengan mengoptimalkan ekspresi Aljabar Relasional seperti :

  • [1]Selection (σ)
  • [1]Projection (̟)
  • [1]Cartesian Product / Cross Product (X)
  • [1]Union (∪)
  • [1]Set-Difference (-)


    Berikut tabel yang akan dibuat aljabar relasional dan optimasi querynya

    Tabel Pelanggan                                                    Tabel Harga                   
                             
    Tabel Daya Terpasang


    ALJABAR RELASIONAL

    SELECT nmpel
    FROM pelanggan,daya_terpasang
    WHERE pelanggan.idpel = daya_terpasang.idpel
    AND daya > 1300

    Π nmpel(σdaya >1300 Λ pelanggan.idpel=daya_terpasang.idpel(pelanggan X daya_terpasang))

Query Decomposition
  • Pada Lapis Pertama ini input adalah query dirubah menjadi Aljabar query.
  • Query Decomposition dibagi menjadi 4 bagian :
    • Normalisasi
      Proses untuk mengubah suatu tabel yang memiliki  masalah tertentu  ke dalam dua buah tabel    atau lebih, yang tidak lagi memiliki masalah tersebut (Abdul Kadir, 2002: 52).
    • Analisa semantikMendeteksi queri yang salah
    • Memperbaiki Query
    • [1]Menata ulang struktur dari query (restruktured)
      Gunakan aturan transformasi

 Aturan untuk operasi logika
[1] p1 ∧ p2 <=> p2 ^ p1
[1] p1 V p2 <=> p2 V p1
[1] p1 ^ ( p2 ^p3)
 (p1 ^ p2) ^p3
[1] p1 V (p2 Vp3)
( p1 V p2) Vp3
[1] p1 ^ (p2 Vp3)
(p1 ^ p2) V (p1 ^ p3)
[1] p1 V (p2 ^ p3)
 (p1 V p2) ^ (p1 V p3)
[1] ¬ ( p1 ^ p2)
 ¬p1 V ¬p2
[1] ¬ ( p1 V p2)
 ¬p1 ^ ¬p2
[1] ¬(¬p)
 p


CONTOH 1
Mencari nama pelanggan dengan ap ‘lenteng agung ‘
dengan daya 1300 atau 900 watt

SQL :
Select nmpel
From pelanggan p , daya_terpasang d
Where p.idpel = d.idpel
And ap = “lenteng agung”
And (daya = 1300 Or daya = 900)

Normalisasi:
p.idpel = d.idpel ∧ ap=“lenteng agung” ∧ (daya = 1300 V Daya =900)

ANALISA
Menemukan queri yang salah
Tipe yang tidak benar:
1. Jika ada atribut atau nama relasi tidak didefenisi dalam skema global
2. Ada operasi yang diaplikasikan ke atribut dengan tipe yang salah
 
KESALAHAN SEMANTIK
1. Ada komponen yang tidak memberikan konstribusi dalam hasil akhir
2. Hanya sebagian dari relational queris yang dapat di tes untuk koreksi
3. Untuk mendektesi : query graph dan Join Graph

                                







SQL Tuning
23 Mei 2010
visilubai Pemrograman Tinggalkan komentar
Definisi
Memperlancar SQL adalah sebagai banyak bagian dari kinerja aplikasi sebagai database merancang dan tuning. Tidak peduli bagaimana menyempurnakan database atau bagaimana suara struktur database, Anda tidak akan menerima hasil query tepat waktu yang diterima kepada Anda, atau bahkan lebih buruk lagi, pelanggan, jika Anda tidak mengikuti beberapa pedoman dasar.Mempercayai kami, jika pelanggan tidak puas, maka Anda bisa bertaruh atasan Anda tidak akan puas baik.
Tujuan
Anda sudah tahu tentang komponen utama dari bahasa database relasional dari SQL dan bagaimana berkomunikasi dengan database, sekarang saatnya untuk menerapkan pengetahuan Anda untuk hidup kinerja keprihatinan-nyata. Tujuan Hari 15 adalah untuk merekomendasikan metode untuk memperbaiki kinerja, atau pelurusan, pernyataan SQL. Pada akhir hari ini, Anda harus
  • Memahami konsep perampingan kode SQL Anda
  • Memahami perbedaan antara beban batch dan pengolahan transaksi dan pengaruhnya terhadap kinerja database
  • Mampu untuk memanipulasi kondisi dalam query Anda untuk mempercepat pengambilan data
  • database Jadilah akrab dengan dasar beberapa elemen yang mempengaruhi seluruh tuning
Berikut analogi untuk membantu Anda memahami frase merampingkan pernyataan SQL: Tujuan dari perenang kompetitif adalah untuk menyelesaikan peristiwa dalam waktu sedikit mungkin tanpa didiskualifikasi. Para perenang harus memiliki teknik yang dapat diterima, dapat torpedo diri mereka sendiri melalui air, dan penggunaan semua sumber daya fisik mereka seefektif mungkin.Dengan setiap stroke dan napas mereka mengambil, perenang kompetitif tetap efisien dan bergerak melalui air dengan sedikit hambatan yang sangat.
Lihatlah query SQL Anda dengan cara yang sama. Anda harus selalu tahu persis apa yang ingin Anda capai dan kemudian berusaha untuk mengikuti jalan sedikit perlawanan. Semakin banyak waktu yang Anda habiskan untuk merencanakan, semakin sedikit waktu Anda harus menghabiskan merevisi nanti. Tujuan Anda harus selalu untuk mengambil data yang akurat dan untuk melakukannya dalam waktu sesedikit mungkin. Seorang pengguna akhir menunggu di lambat permintaan seperti restoran lapar tak sabar menunggu makan lambat. Meskipun Anda dapat menulis permintaan yang paling dalam beberapa cara, susunan komponen dalam permintaan adalah faktor yang membuat perbedaan detik, menit, dan kadang-kadang jam saat Anda mengeksekusi querySQL. Memperlancar adalah proses menemukan pengaturan optimal unsur-unsur dalam permintaan Anda.
Selain perampingan pernyataan SQL Anda, Anda juga harus mempertimbangkan beberapa faktor lain ketika mencoba untuk meningkatkan kinerja database umum, misalnya, transaksi pengguna konkuren yang terjadi dalam database, tabel pengindeksan, dan turun database tuning-dalam.
CATATAN: Today’s contoh penggunaan pribadi Oracle7 dan alat-alat yang tersedia dengan sistem manajemen database relasional Oracle7.3;. Konsep dibahas saat ini tidak terbatas pada Oracle mereka dapat diterapkan untuk lain sistem manajemen database relasional.
Membuat Laporan SQL Anda Readable
Meskipun mudah dibaca tidak mempengaruhi kinerja aktual statemen SQL, praktek pemrograman yang baik panggilan untuk kode dibaca. Keterbacaan terutama penting jika Anda memiliki beberapa kondisi di klausa WHERE. Siapa pun membaca klausul harus dapat menentukan apakah tabel yang bergabung dengan benar dan harus mampu memahami urutan kondisi.
Cobalah untuk membaca pernyataan ini:
  SQL> SELECT EMPLOYEE_TBL.EMPLOYEE_ID, EMPLOYEE_TBL.NAME, EMPLOYEE_PAY_TBL.SALARY, EMPLOYEE_PAY_TBL.HIRE_DATE
    2 DARI EMPLOYEE_TBL, EMPLOYEE_PAY_TBL
    3 WHERE EMPLOYEE_TBL.EMPLOYEE_ID = EMPLOYEE_PAY_TBL.EMPLOYEE_ID DAN
    4 EMPLOYEE_PAY_TBL.SALARY> 30.000 ATAU (ANTARA EMPLOYEE_PAY_TBL.SALARY 25.000
    5 DAN 30.000 DAN EMPLOYEE_PAY_TBL.HIRE_DATE <SYSDATE - 365);
Berikut adalah permintaan yang sama diformat ulang untuk meningkatkan mudah dibaca:
 SQL> SELECT EMPLOYEE_ID E., E. NAME, P. GAJI, P. HIRE_DATE 2 DARI EMPLOYEE_TBL E, 3 P EMPLOYEE_PAY_TBL 4 WHERE EMPLOYEE_ID E. = P EMPLOYEE_ID 5 DAN GAJI P> 30.000 6 ATAU (ANTARA GAJI P. 25.000 DAN 30.000 7 DAN P. HIRE_DATE SYSDATE <- 365);
CATATAN: Perhatikan penggunaan alias tabel dalam permintaan sebelumnya. EMPLOYEE_TBL sejalan 2 telah diberi alias E, dan EMPLOYEE_PAY_TBL sejalan 3 telah ditetapkan alias P.Anda dapat melihat bahwa di jalur 4, 5, 6, dan 7, E dan P berdiri untuk nama tabel penuh. Alias kurang mengetik membutuhkan banyak daripada mengeja nama tabel lengkap, dan bahkan lebih penting, query yang menggunakan alias lebih terorganisir dan lebih mudah untuk dibaca daripada permintaan yang penuh dengan nama lengkap tidak perlu meja panjang.
Dua pertanyaan yang identik, tapi yang kedua adalah jelas jauh lebih mudah dibaca. Hal ini sangat terstruktur, yaitu komponen logis dari query telah dipisahkan oleh spasi dan tombol enter konsisten. Anda dapat dengan cepat melihat apa yang sedang dipilih (klausa SELECT), apa tabel sedang diakses (DARI klausa), dan kondisi apa perlu dipenuhi (klausa WHERE).
Tabel-Scan Penuh
Sebuah meja penuh scan terjadi ketika server database membaca setiap catatan dalam tabel dalam rangka untuk menjalankan pernyataan SQL. Kendali-tabel scan biasanya menjadi masalah ketika berhadapan dengan pertanyaan atau pernyataan SELECT. Namun, meja penuh scan juga dapat ikut bermain ketika berhadapan dengan update dan menghapus. Sebuah meja penuh scan terjadi ketika kolom di klausa WHERE tidak memiliki indeks yang terkait dengan mereka. Sebuah meja penuh scan seperti membaca buku dari depan sampai belakang, mencoba mencari kata kunci. Seringkali, Anda akan memilih untuk menggunakan indeks.
Anda dapat menghindari meja penuh scan dengan membuat indeks pada kolom yang digunakan sebagai kondisi di klausa WHERE sebuah pernyataan SQL. Indeks menyediakan jalur langsung ke data dengan cara yang sama suatu indeks dalam sebuah buku pembaca merujuk ke nomor halaman. Menambahkan indeks kecepatan akses data.
Meskipun biasanya programmer mengerut atas meja-scan penuh, mereka kadang-kadang sesuai. Sebagai contoh:
  • Anda sebagian besar memilih baris dari tabel.
  • Anda mengupdate setiap baris dalam sebuah tabel.
  • Meja kecil.
Dalam kasus pertama dua Indeks akan tidak efisien karena database server akan harus merujuk ke indeks, membaca meja, merujuk ke indeks lagi, membaca meja lagi, dan sebagainya. Di sisi lain, indeks yang paling efisien ketika mengakses data Anda adalah persentase kecil, biasanya tidak ada lebih dari 10 hingga 15 persen, dari total data yang terdapat dalam tabel.
Selain itu, indeks yang terbaik digunakan pada tabel besar. Anda harus selalu mempertimbangkan ukuran tabel saat Anda merancang tabel dan indeks. tabel pengindeksan Benar keakraban dengan melibatkan data, mengetahui kolom yang akan diakses paling, dan mungkin memerlukan eksperimen untuk melihat indeks karya terbaik.
CATATAN: Ketika berbicara tentang sebuah meja yang besar “,” besar adalah istilah relatif. Sebuah meja yang sangat besar untuk satu individu mungkin menit ke lain. Ukuran meja relatif ke ukuran tabel lain dalam database, untuk ruang disk yang tersedia, dengan jumlah disk yang tersedia, dan akal sehat sederhana. Jelas, 2GB meja besar, sedangkan meja 16KB kecil. Dalam lingkungan database dimana tabel ukuran rata-rata 100MB, 500MB meja dapat dianggap besar.
Menambahkan Indeks Baru
Anda akan sering menemukan situasi di mana pernyataan SQL sedang berjalan untuk jumlah yang tidak masuk akal waktu, meskipun kinerja laporan lain tampaknya dapat diterima, misalnya, ketika kondisi bagi perubahan pengambilan data atau ketika mengubah struktur tabel.
Kami juga telah melihat jenis perlambatan ketika layar atau jendela baru telah ditambahkan ke akhir aplikasi depan. Salah satu hal pertama yang harus dilakukan ketika Anda mulai memecahkan masalah adalah untuk mengetahui apakah meja target memiliki indeks. Dalam sebagian besar kasus kita lihat, tabel target memiliki indeks, namun salah satu kondisi baru dalam klausul WHEREmungkin kurang indeks. Melihat klausa WHERE dari pernyataan SQL, kita bertanya, Haruskah kita menambahkan indeks lain? Jawabannya mungkin ya jika:
  • Yang membatasi kondisi yang paling (s) mengembalikan kurang dari 10 persen dari baris dalam tabel.
  • Kondisi yang paling restriktif (s) akan sering digunakan dalam pernyataan SQL.
  • Kondisi (s) pada kolom dengan indeks akan kembali nilai-nilai yang unik.
  • Kolom ini sering dirujuk di ORDER BY dan GROUP BY klausa.
Komposit indeks juga dapat digunakan. Sebuah indeks komposit indeks pada dua atau lebih kolom dalam sebuah tabel. Indeks ini dapat lebih efisien daripada-kolom indeks tunggal jika diindeks kolom sering digunakan bersama sebagai kondisi di klausa WHERE dari pernyataan SQL. Apabila kolom diindeks digunakan secara terpisah juga sama, terutama dalam permintaan lain, satu-kolom indeks mungkin lebih sesuai dan. Anda Gunakan pertimbangan menjalankan tes pada data Anda untuk melihat jenis pakaian terbaik indeks database yang mana.
Pengaturan Unsur dalam sebuah Permintaan
Pengaturan terbaik dari unsur-unsur dalam permintaan Anda, khususnya pada klausa WHERE, benar-benar tergantung pada urutan langkah-langkah proses dalam pelaksanaan tertentu. Penyusunan kondisi tergantung pada kolom yang diindeks, serta kondisi yang akan mengambil paling sedikit catatan.
Anda tidak harus menggunakan kolom yang diindeks pada klausa WHERE, tetapi jelas lebih bermanfaat untuk melakukannya. Cobalah untuk mempersempit hasil dari pernyataan SQL dengan menggunakan indeks yang mengembalikan jumlah baris yang paling sedikit. Kondisi yang mengembalikan catatan paling sedikit dalam sebuah tabel dikatakan dalam kondisi yang paling ketat.Sebagai pernyataan umum, anda harus menempatkan membatasi kondisi yang paling terakhir dalam klausa WHERE. (Query optimizer’s Oracle membaca klausa WHERE dari bawah ke atas, sehingga dalam arti tertentu, Anda akan menempatkan pembatasan kondisi yang paling pertama.)
Ketika optimizer membaca membatasi kondisi yang paling pertama, ia mampu mempersempit hasil set pertama sebelum melanjutkan ke kondisi berikutnya. Kondisi berikutnya, bukannya melihat seluruh meja, harus melihat pada subset yang dipilih oleh kondisi yang paling selektif. Akhirnya, data yang diambil lebih cepat. Yang selektif kondisi yang paling mungkin tidak jelas dalam permintaan kompleks dengan kondisi beberapa, subqueries, perhitungan, dan beberapa kombinasi dari DAN, ATAU, dan SEPERTI.
TIP: Selalu cek dokumentasi database Anda untuk melihat bagaimana SQL diproses dalam pelaksanaan Anda.
Tes berikut adalah salah satu dari banyak kami telah menjalankan untuk mengukur perbedaan waktu berlalu antara dua unik diatur query dengan konten yang sama. Contoh-contoh ini menggunakan sistem manajemen database relasional Oracle7.3. Ingat, pengoptimasi dalam implementasi ini membaca klausa WHERE dari bawah ke atas.
Sebelum membuat pernyataan SELECT, kami memilih jumlah baris yang berbeda pada setiap kondisi yang kita rencanakan untuk digunakan. Berikut adalah nilai-nilai yang dipilih untuk setiap kondisi:
Kondisi
Nilai yang berbeda
calc_ytd = '-2109490,8'
13.000 +
dt_stmp = '01-September-96 '
15
output_cd = '001 '
13
activity_cd = 'IN'
10
status_cd = 'A'
4
function_cd = '060 '
6
CATATAN: Yang membatasi kondisi yang paling juga kondisi dengan nilai yang paling berbeda.
Pada contoh berikut tempat yang terbatas kondisi yang paling pertama di klausa WHERE:
INPUT:
  SQL> SET WAKTU ON
    2 SELECT COUNT (*)
    3 DARI FACT_TABLE
    4 WHERE CALC_YTD = '-2109490,8'
    5 DAN DT_STMP = '01-September-96 '
    6 DAN OUTPUT_CD = '001 '
    7 DAN ACTIVITY_CD = 'IN'
    8 DAN STATUS_CD = 'A'
    9 DAN FUNCTION_CD = '060 ';
OUTPUT:
  COUNT (*)
  --------
         8
  1 baris yang dipilih.
  Berlalu: 00:00:15.37
Contoh ini menempatkan membatasi kondisi yang paling terakhir di klausa WHERE:
INPUT / OUTPUT:
  SQL> SET WAKTU ON
    2 SELECT COUNT (*)
    3 DARI FACT_TABLE
    4 WHERE = FUNCTION_CD '060 '
    5 DAN STATUS_CD = 'A'
    6 DAN ACTIVITY_CD = 'IN'
    7 DAN OUTPUT_CD = '001 '
    8 DAN DT_STMP = '01-September-96 '
    9 DAN CALC_YTD = '-2109490,8';

  COUNT (*)
  --------
         8
  1 baris yang dipilih.
  Berlalu: 00:00:01.80
ANALISIS:
Perhatikan perbedaan waktu berlalu. Cukup mengubah urutan kondisi sesuai dengan tabel statistik yang diberikan, pertanyaan kedua berlari hampir 14 detik lebih cepat dari yang pertama.Bayangkan perbedaannya pada query yang terstruktur buruk yang berlangsung selama tiga jam!
Prosedur
Untuk query yang dijalankan secara teratur, cobalah untuk menggunakan prosedur. Prosedur adalah kelompok berpotensi besar pernyataan SQL. (Lihat Hari 13, “Topik Lanjutan SQL.”)
Prosedur yang dikompilasi oleh mesin database dan kemudian dieksekusi. Tidak seperti pernyataan SQL, database engine tidak perlu mengoptimalkan prosedur sebelum dijalankan,. Prosedur sebagai lawan dari individu banyak pertanyaan, mungkin lebih mudah bagi pengguna untuk memelihara dan lebih efisien untuk database.
Menghindari ATAU
Hindari menggunakan operator OR logis dalam query jika mungkin. ATAU pasti melambat hampir semua query terhadap tabel ukuran besar. Kami menemukan bahwa DI pada umumnya jauh lebih cepat daripada OR. Saran ini tentu saja tidak setuju dengan dokumentasi yang menyatakan bahwa pengoptimalan mengkonversi DI argumen untuk kondisi OR. Namun demikian, di sini adalah contoh query menggunakan OR beberapa s:
INPUT:
 SQL> SELECT * 2 FROM WHERE 3 FACT_TABLE STATUS_CD = 'A' 4 ATAU STATUS_CD 'B =' 5 ATAU STATUS_CD 'C =' 6 OR STATUS_CD = 'D' 7 OR STATUS_CD = 'E' 8 OR STATUS_CD = 'F' 9 ORDER BY STATUS_CD;
Berikut ini adalah permintaan yang sama menggunakan substr dan IN:
INPUT:
  SQL> SELECT *
    2 DARI FACT_TABLE
    3 STATUS_CD DI MANA ('A', 'B', 'C', 'D', 'E', 'F')
    4 ORDER BY STATUS_CD;
ANALISIS:
Coba uji sesuatu yang serupa untuk diri sendiri. Meskipun buku merupakan sumber yang sangat baik untuk standar dan arah, Anda akan menemukan seringkali berguna untuk datang ke kesimpulan sendiri pada hal-hal tertentu, seperti kinerja.
Berikut ini adalah contoh lain menggunakan substr dan IN. Perhatikan bahwa permintaan pertama SEPERTI menggabungkan dengan OR.
INPUT:
  SQL> SELECT *
    2 DARI FACT_TABLE
    3 WHERE PROD_CD LIKE 'AB%'
    4 ATAU PROD_CD LIKE 'AC%'
    5 ATAU PROD_CD LIKE 'BB%'
    6 ATAU PROD_CD LIKE '% BC
    7 ATAU PROD_CD LIKE '% CC'
    8 ORDER BY PROD_CD;
  SQL> SELECT *
    2 DARI FACT_TABLE
    3 WHERE substr (PROD_CD, 1,2) IN ('AB', 'AC', 'BB', 'SM', 'CC')
    4 ORDER BY PROD_CD;
ANALISIS:
Contoh kedua tidak hanya menghindari OR, tetapi juga menghilangkan kombinasi dari OR dan operator SEPERTI. Anda mungkin ingin mencoba misalnya ini untuk melihat apa perbedaan kinerja waktu-nyata adalah untuk data Anda.
OLTP versus OLAP
Ketika tuning database, Anda harus terlebih dahulu menentukan apa database digunakan untuk. Sebuah pengolahan analisis online (OLAP) database adalah sebuah sistem yang berfungsi untuk menyediakan kemampuan permintaan kepada pengguna akhir untuk tujuan umum informasi dan statistik. Data yang diambil dalam jenis lingkungan sering digunakan untuk laporan statistik yang membantu dalam proses pengambilan keputusan perusahaan. Jenis sistem juga disebut sebagai sistem pendukung keputusan (DSS). Sebuah proses transaksi online (OLTP) database adalah sebuah sistem yang utama berfungsi untuk menyediakan lingkungan bagi-masukan pengguna akhir dan juga mungkin melibatkan query terhadap-hari informasi hari. sistem OLTP digunakan untuk memanipulasi informasi dalam database setiap hari gudang data. dan DSSS mendapatkan data mereka dari database transaksi online dan kadang-kadang dari sistem OLAP lainnya.
OLTP Tuning
Sebuah database transaksional adalah sebuah sistem yang sangat rumit diakses dalam bentuk transaksi dan permintaan terhadap-hari informasi hari. Namun, sebuah OLTP biasanya tidak memerlukan areal yang luas semacam, paling tidak sejauh yang diperlukan dalam lingkungan OLAP. Kebanyakan OLTP transaksi cepat dan tidak melibatkan banyak penyortiran.
Salah satu masalah terbesar dalam database transaksional adalah segmen rollback. Jumlah dan ukuran segmen rollback sangat bergantung pada berapa banyak pengguna secara bersamaan mengakses database, serta jumlah pekerjaan di setiap transaksi. Pendekatan yang terbaik adalah memiliki beberapa segmen rollback di lingkungan transaksional.
Keprihatinan lain di lingkungan transaksi adalah integritas transaksi log, yang ditulis untuk setelah setiap transaksi. Log ini ada untuk tujuan pemulihan. Oleh karena itu, setiap implementasi SQL membutuhkan cara untuk membuat cadangan log untuk digunakan dalam titik “pada waktu pemulihan.” SQL Server menggunakan perangkat sampah; Oracle menggunakan modus database yang dikenal sebagai modus ARCHIVELOG. Transaksi log juga melibatkan pertimbangan kinerja karena back up log membutuhkan overhead tambahan.
OLAP Tuning
OLAP tuning sistem, seperti sebuah gudang data atau mendukung sistem pengambilan keputusan, jauh berbeda dengan tuning database transaksi. Biasanya, diperlukan lebih banyak ruang untuk menyortir.
Karena tujuan dari jenis sistem adalah untuk mengambil keputusan membuat data yang berguna, Anda dapat berharap banyak pertanyaan yang kompleks, yang biasanya melibatkan pengelompokan dan penyortiran data. Dibandingkan dengan database transaksi, sistem OLAP biasanya mengambil lebih banyak tempat untuk area ruang semacam tetapi kurang untuk daerah rollback.
Kebanyakan transaksi dalam sistem OLAP terjadi sebagai bagian dari proses batch. Daripada memiliki beberapa daerah rollback masukan pengguna, Anda mungkin resor untuk satu daerah rollback besar untuk beban, yang dapat diambil offline selama kegiatan sehari-hari untuk mengurangi overhead.
Beban Batch Versus Pengolahan Transaksional
Faktor utama dalam kinerja database dan pernyataan SQL adalah jenis pemrosesan yang terjadi dalam database. Salah satu jenis pengolahan OLTP, dibahas tadi pagi. Ketika kita berbicara tentang proses transaksi, kami akan merujuk ke dua jenis: user input dan beban batch.
input pengguna Reguler biasanya terdiri dari pernyataan SQL seperti INSERT, UPDATE, dan DELETE. Jenis transaksi ini sering dilakukan oleh pengguna akhir, atau pelanggan. Pengguna akhir biasanya menggunakan aplikasi front-end seperti PowerBuilder untuk berinteraksi dengan database, dan karena itu mereka mengeluarkan pernyataan SQL jarang terlihat. Namun demikian, SQL kode telah dihasilkan untuk pengguna akhir oleh aplikasi depan.
Fokus utama Anda saat mengoptimalkan kinerja database harus menjadi pengguna-akhir transaksi. Setelah semua, “pelanggan tidak” sama dengan “ada database,” yang pada gilirannya berarti bahwa Anda berada di luar pekerjaan. Selalu mencoba untuk membuat pelanggan Anda senang, meskipun ekspektasi mereka terhadap sistem / database kinerja kadang-kadang mungkin tidak masuk akal. Salah satu pertimbangan dengan-masukan pengguna akhir adalah jumlah pengguna secara bersamaan. Database pengguna bersamaan yang Anda miliki, semakin besar kemungkinan penurunan kinerja.
Apa yang dimaksud dengan beban batch? Sebuah beban tumpukan batch melakukan transaksi terhadap database sekaligus. Misalnya, Anda tahun pengarsipan’s data terakhir ke tabel sejarah besar. Anda mungkin perlu memasukkan ribuan atau bahkan jutaan, dari baris data ke dalam tabel sejarah Anda. Anda mungkin tidak ingin melakukan tugas ini secara manual, sehingga Anda cenderung untuk menciptakan sebuah pekerjaan batch atau script untuk mengotomatisasi proses ini. (Berbagai teknik tersedia untuk memuat data dalam batch sumber daya. Batch) muatan terkenal untuk database dan sistem perpajakan. Sumber daya ini termasuk akses database meja, katalog mengakses sistem, segmen rollback database, dan area ruang semacam; sumber daya sistem dapat mencakup CPU yang tersedia dan berbagi memori. Banyak faktor lain yang terlibat, tergantung pada sistem operasi Anda dan server database.
Kedua-pengguna akhir transaksi dan beban batch diperlukan untuk database yang paling berhasil, tetapi sistem Anda bisa mengalami masalah kinerja yang serius jika kedua jenis tanduk kunci pengolahan. Oleh karena itu, Anda harus tahu perbedaan antara mereka dan menjaga mereka dipisahkan sebisa mungkin. Misalnya, Anda tidak akan ingin memuat sejumlah besar data ke dalam database ketika aktivitas pengguna tinggi. Tanggapan database sudah mungkin lambat karena jumlah pengguna secara bersamaan. Selalu mencoba untuk menjalankan beban batch ketika aktivitas pengguna adalah minimal. Banyak toko cadangan kali di malam hari atau dini hari untuk memuat data dalam batch untuk menghindari gangguan dengan pemrosesan harian.
Anda harus selalu merencanakan waktu untuk beban batch besar, berhati-hati untuk menghindari penjadwalan mereka saat database ini diharapkan akan tersedia untuk penggunaan normal.Gambar 15,1 melukiskan update batch berat berjalan bersamaan dengan proses beberapa pengguna, semua bersaing untuk sumber daya sistem.
Gambar 15,1.
Sistem sumber daya contention.
Seperti yang Anda lihat, banyak proses yang bersaing untuk sumber daya sistem. Update batch berat yang dilakukan melempar geser monyet dalam perhitungan. Alih-alih sumber daya sistem tersebar agak merata di antara para pengguna, pembaruan batch tampak memonopoli mereka. Situasi ini hanyalah permulaan pertengkaran sumber daya. Sebagai transaksi batch dilanjutkan, akhirnya proses pengguna dapat dipaksa keluar dari gambar. Kondisi ini bukan cara yang baik dalam berbisnis. Bahkan jika sistem hanya memiliki satu pengguna, pendapat yang signifikan untuk itu pengguna bisa terjadi.
Masalah lain dengan proses batch adalah bahwa proses itu mungkin memegang kunci di atas meja seorang pengguna mencoba untuk mengakses. Jika ada kunci di atas meja, pengguna akan menolak akses sampai mengunci dibebaskan oleh proses batch, yang dapat jam. Proses Batch harus dilakukan ketika sumber daya sistem terbaik mereka jika mungkin. Jangan membuat transaksi pengguna bersaing dengan batch. Tidak ada yang memenangkan permainan itu.
Mengoptimalkan Beban Data oleh Dropping Indeks
Salah satu cara untuk mempercepat update batch dengan menjatuhkan indeks. Bayangkan meja sejarah dengan ribuan barisan. Itu tabel sejarah juga cenderung memiliki satu atau lebih indeks.Ketika Anda memikirkan indeks, Anda biasanya memikirkan akses tabel lebih cepat, tetapi dalam hal beban batch, Anda bisa mendapatkan keuntungan dengan menjatuhkan indeks (es).
Ketika data beban Anda ke dalam tabel dengan indeks, Anda biasanya dapat mengharapkan banyak menggunakan indeks, terutama jika Anda memperbarui persentase tinggi baris dalam tabel.Lihatlah dengan cara ini. Jika Anda mempelajari buku dan menyoroti poin-poin penting untuk referensi di masa mendatang, Anda mungkin merasa lebih cepat untuk menelusuri buku dari awal sampai akhir daripada menggunakan indeks untuk mencari poin kunci Anda. (Menggunakan indeks akan efisien jika Anda hanya menyoroti sebagian kecil dari buku itu.)
Untuk memaksimalkan efisiensi beban batch / update yang mempengaruhi persentase tinggi baris dalam sebuah tabel, Anda dapat mengambil tiga langkah dasar untuk menonaktifkan indeks:
1. Drop indeks yang sesuai (es).
2. Load / update data meja.
3. Membangun kembali meja indeks.
A COMMIT Menyimpan Sering DBA yang Jauh
Ketika melakukan transaksi batch, Anda harus tahu seberapa sering untuk melakukan “komit 11.” Seperti yang Anda pelajari pada hari, “Transaksi Pengendalian,” COMMIT finalizes pernyataan transaksi. A COMMIT menyimpan transaksi atau menulis perubahan ke meja yang berlaku (s). Di belakang layar, namun lebih banyak yang terjadi. Beberapa daerah di database dicadangkan untuk menyimpan menyelesaikan transaksi sebelum perubahan benar-benar ditulis ke meja target. Oracle panggilan ini rollback segmen daerah. Ketika Anda mengeluarkan pernyataan COMMIT,transaksi yang terkait dengan sesi SQL Anda di segmen rollback diperbarui dalam tabel target. Setelah update terjadi, isi dari segmen rollback dihapus,. ROLLBACK Perintah di sisi lain, membersihkan isi segmen rollback tanpa memperbarui tabel target.
Seperti yang Anda bisa menebak, jika Anda tidak pernah mengeluarkan perintah COMMIT atau ROLLBACK, transaksi terus membangun dalam segmen rollback. Selanjutnya, jika data Anda yang memuat dalam ukuran lebih besar daripada ruang yang tersedia di segmen rollback, database dasarnya akan berhenti dan larangan aktivitas transaksi lebih lanjut. Tidak mengeluarkan perintahCOMMIT adalah perangkap pemrograman umum; COMMIT reguler s membantu memastikan kinerja yang stabil dari seluruh sistem database.
Manajemen segmen rollback adalah penting database administrator dan kompleks (DBA) tanggung jawab karena mempengaruhi transaksi dinamis segmen rollback, dan pada gilirannya, mempengaruhi kinerja keseluruhan database serta laporan SQL individu. Jadi, ketika Anda yang memuat sejumlah besar data, pastikan untuk mengeluarkan perintah COMMIT secara teratur.Periksa dengan DBA Anda untuk nasihat tentang seberapa sering untuk melakukan saat transaksi batch. (Lihat Gambar 15,2.)
Gambar 15,2.
Daerah rollback.
Seperti yang dapat Anda lihat pada Gambar 15.2, bila pengguna melakukan transaksi, perubahan tersebut disimpan di daerah rollback.
Membangun kembali Tabel dan Indeks dalam Lingkungan Dinamis
Database lingkungan yang dinamis merujuk ke database besar yang berada dalam keadaan konstan berubah. Perubahan yang kita mengacu kepada yang sering update batch dan pengolahan transaksi harian terus-menerus. Dynamic database OLTP biasanya memerlukan sistem yang berat, tetapi juga dapat merujuk pada DSSS atau gudang data, tergantung pada volume dan frekuensi beban data.
Hasil perubahan tinggi volume konstan untuk database adalah pertumbuhan, yang pada gilirannya menghasilkan fragmentasi. Fragmentasi dapat dengan mudah keluar dari tangan jika pertumbuhan ini tidak dikelola dengan baik. Oracle mengalokasikan rupa awal untuk tabel ketika mereka diciptakan. Bila data yang dimuat dan mengisi meja tingkat awal, tingkat berikutnya, yang juga dialokasikan bila meja diciptakan, diambil.
Ukuran tabel dan indeks pada dasarnya adalah sebuah fungsi DBA dan drastis dapat mempengaruhi kinerja pernyataan SQL. Langkah pertama dalam manajemen pertumbuhan adalah proaktif. Biarkan ruang untuk tabel untuk tumbuh dari hari pertama, dalam alasan. Juga berencana untuk defragment database secara teratur, bahkan jika hal itu berarti mengembangkan rutinitas mingguan. Berikut adalah langkah-langkah dasar konseptual yang terlibat dalam defragmenting tabel dan indeks dalam sistem manajemen database relasional:
1. Dapatkan cadangan yang baik dari tabel (s) dan / atau indeks (es).
2. Drop tabel (s) dan / atau indeks (es).
3. Membangun kembali tabel (s) dan / atau indeks (es) dengan alokasi ruang baru.
4. Mengembalikan data ke dalam tabel yang baru dibangun (s).
5. Re membuat indeks (es) jika perlu.
6 pengguna. Memulihkan hak akses peran / di meja jika diperlukan.
7. Simpan cadangan dari meja Anda sampai Anda benar-benar yakin bahwa tabel yang baru dibangun dengan sukses. Jika Anda memilih untuk membuang cadangan dari tabel asli, pertama-tama Anda harus membuat cadangan tabel baru setelah data telah sepenuhnya pulih.
PERINGATAN: Jangan pernah membuang cadangan tabel Anda sampai Anda yakin bahwa tabel baru dibangun dengan sukses.
Contoh berikut menunjukkan penggunaan praktis dari mailing list tabel dalam lingkungan database Oracle.
INPUT:
  CREATE TABLE MAILING_TBL_BKUP AS
  SELECT * FROM MAILING_TBL;
OUTPUT:
  Tabel Dibuat.
INPUT / OUTPUT:
 mailing_tbl drop tabel; Tabel Turun TABLE. CREATE MAILING_TBL (INDIVIDUAL_ID VARCHAR2 (12) TIDAK NULL, INDIVIDUAL_NAME VARCHAR2 (30) TIDAK NULL, ALAMAT VARCHAR (40) TIDAK NULL, KOTA VARCHAR (25) TIDAK NULL, NEGARA VARCHAR (2) NOT NULL , ZIP_CODE VARCHAR (9) TIDAK NULL,) tablespace TABLESPACE_NAME PENYIMPANAN (AWAL NEW_SIZE, NEXT NEW_SIZE); Tabel dibuat mailing_tbl_bkup. INSERT INTO * MAILING_TBL pilih dari; 93.451 baris INDEKS dimasukkan. CREATE TABLE SURAT MAILING_IDX ON (INDIVIDUAL_ID) tablespace TABLESPACE_NAME PENYIMPANAN (AWAL NEW_SIZE, NEXT NEW_SIZE); Indeks Dibuat.. hibah pilih pada mailing_tbl kepada publik; Grant Pengganti meja mailing_tbl_bkup drop; Tabel Turun.
ANALISIS:
Membangun kembali tabel dan indeks yang telah berkembang memungkinkan Anda untuk mengoptimalkan penyimpanan, yang meningkatkan kinerja secara keseluruhan. Ingatlah untuk drop tabel cadangan hanya setelah Anda memverifikasi bahwa tabel yang baru telah berhasil diciptakan. Juga perlu diingat bahwa Anda dapat mencapai hasil yang sama dengan metode lain. Periksa pilihan yang tersedia bagi Anda di dokumentasi database Anda.
Tuning database
Tuning database adalah proses fine-tuning database kinerja server. Sebagai pendatang baru SQL, Anda mungkin tidak akan terkena tuning database kecuali Anda adalah seorang DBA DBA baru atau pindah ke lingkungan database relasional. Apakah Anda akan mengelola database atau menggunakan SQL pada aplikasi atau program, Anda akan mendapatkan keuntungan dengan mengetahui sesuatu tentang proses tuning-database. Kunci keberhasilan setiap database bagi semua pihak untuk bekerja sama. Beberapa tips umum untuk tuning database ikuti.
  • Minimalkan ukuran keseluruhan yang dibutuhkan untuk database. Ini bagus untuk memungkinkan ruang untuk pertumbuhan ketika mendesain database, tapi jangan pergi ke laut. Jangan mengikat sumber daya yang Anda mungkin perlu untuk mengakomodasi pertumbuhan database.
  • Percobaan dengan variabel waktu-slice proses pengguna. Variabel ini mengatur jumlah waktu database server scheduler mengalokasikan untuk pengguna setiap proses.
  • Optimalkan jaringan paket ukuran yang digunakan oleh aplikasi. Semakin besar jumlah data yang dikirim melalui jaringan, semakin besar ukurannya jaringan paket seharusnya. Tanyakan database dan dokumentasi jaringan untuk rincian lebih lanjut.
  • Store transaksi log pada hard disk yang terpisah. Untuk setiap transaksi yang terjadi, server harus menulis perubahan transaksi log. Jika Anda menyimpan log file-file pada disk yang sama seperti Anda menyimpan data, Anda dapat menciptakan hambatan kinerja. (Lihat Gambar 15.3.)
  • Stripe sangat besar tabel di beberapa disk. Jika pengguna mengakses bersamaan sebuah meja besar yang banyak tersebar di disk, ada kurang banyak kesempatan harus menunggu sumber daya sistem. (Lihat Gambar 15.3.)
  • Toko semacam database daerah, sistem kawasan katalog, dan daerah kembalikan pada hard disk yang terpisah. Ini adalah semua wilayah di database yang paling sering akses pengguna. Dengan menyebarkan daerah-daerah tersebut selama beberapa disk drive, Anda memaksimalkan penggunaan sumber daya sistem 15.3. (Lihat Gambar.)
  • Tambah CPU. Fungsi ini administrator sistem dapat secara drastis meningkatkan kinerja database. Menambahkan CPU dapat mempercepat pemrosesan data karena alasan yang jelas. Jika Anda memiliki beberapa CPU pada mesin, maka Anda mungkin dapat menerapkan strategi pemrosesan paralel,. Database Anda Lihat dokumentasi lebih untuk informasi paralel pada pemrosesan jika tersedia dengan implementasi Anda.
  • Tambah memori.  Secara umum, lebih banyak lebih baik.
  • Toko tabel dan indeks pada hard disk yang terpisah. Anda harus menyimpan indeks dan tabel terkait pada disk drive yang pernah terpisah bila memungkinkan. Susunan ini memungkinkan meja untuk dibaca pada saat yang sama indeks ini direferensikan pada disk lain. Kemampuan untuk menyimpan objek pada beberapa disk tergantung pada berapa banyak disk yang terhubung ke controller. (Lihat Gambar 15.3.)
Gambar 15.3 memperlihatkan contoh sederhana tentang bagaimana Anda dapat memisahkan wilayah utama dari database Anda.
Gambar 15.3.
Menggunakan disk yang tersedia untuk meningkatkan kinerja.
Skenario di Gambar 15.3 menggunakan empat perangkat: disk01 melalui disk04. Tujuan database berat dalam penyebaran daerah Anda dan benda-benda adalah untuk menjaga area penggunaan yang tinggi dari masing-masing lain.
  • Disk01 – Sistem Katalog menyimpan informasi tentang tabel, indeks, pengguna, statistik, database file, ukuran, informasi pertumbuhan, dan data terkait lainnya yang sering diakses oleh persentase yang tinggi dari transaksi.
  • Disk02 – Transaksi log diperbarui setiap kali perubahan dibuat untuk suatu tabel (insert, update, atau menghapus). Transaksi log adalah faktor besar dalam sebuah basis data transaksi online.Mereka tidak menjadi perhatian besar dalam lingkungan hanya membaca, seperti sebuah gudang data atau DSS.
  • Disk03 – segmen Rollback juga signifikan di lingkungan transaksi,. Namun jika ada sedikit aktivitas transaksional (insert, update, menghapus), segmen rollback tidak akan sering digunakan.
  • Disk04 – Agak Database daerah, di sisi lain, digunakan sebagai area sementara untuk memproses pernyataan SQL ketika menyortir data, seperti dalam sebuah OLEH GROUP atau klausa ORDER BY. Urutkan daerah biasanya menjadi masalah dalam sebuah gudang data atau DSS. Namun, penggunaan wilayah semacam juga harus dipertimbangkan dalam lingkungan transaksional.
TIP: Juga perhatikan bagaimana aplikasi tabel dan indeks telah ditempatkan pada setiap disk. Tabel dan indeks harus tersebar sebanyak mungkin.
Pendapatan Internet Layanan Internet bahwa dalam indeks 15,3 Gambar Dan disimpan tabel PADA perangkat berbeda yang. Nama dan Kembali ada posting juga dapat berlangganan My bagaimana “Tabel Besar” Danijel mungkin indeks bergaris melintasi doa perangkat Danijel lebih.Teknik Suami membagi tabel menjadi segmen Yang Kecil Yang lebih dapat diakses secara bersamaan. Striping tabel atau indeks di beberapa perangkat adalah cara untuk mengontrol fragmentasi. Dalam skenario ini, tabel dapat dibaca sementara indeks yang sesuai mereka direferensikan, yang meningkatkan kecepatan akses data secara keseluruhan.
Contoh ini sangat sederhana. Tergantung pada fungsi, ukuran, dan isu-isu yang terkait dengan sistem database Anda, Anda mungkin menemukan metode yang sama untuk mengoptimalkan sumber daya sistem yang bekerja yang lebih baik. Di dunia yang sempurna di mana uang ada kendala, konfigurasi terbaik adalah dengan memiliki disk entitas yang terpisah untuk setiap database utama, termasuk meja besar dan indeks.
Catatan: DBA dan administrator sistem harus bekerja sama untuk menyeimbangkan database alokasi ruang dan mengoptimalkan memori yang tersedia pada server.
Tuning database sangat tergantung pada sistem database tertentu yang Anda gunakan. Jelas, tuning database memerlukan lebih dari sekedar mempersiapkan pertanyaan dan membiarkan mereka terbang. Di sisi lain, Anda tidak akan mendapatkan pahala banyak untuk tuning database ketika aplikasi SQL tidak menyempurnakan itu sendiri. Profesional database lagu yang selama hidup sering mengkhususkan pada satu produk database dan belajar sebanyak mungkin tentang fitur dapat dan keanehan. Meskipun tuning database sering dilihat sebagai tugas menyakitkan, dapat menyediakan lapangan kerja yang sangat menguntungkan bagi orang-orang yang benar-benar memahaminya.
Hambatan Kinerja
Kita telah menyebutkan beberapa perangkap yang tak terhitung jumlahnya kemungkinan yang dapat menghambat kinerja umum database. Ini biasanya kemacetan umum yang melibatkan tingkat pemeliharaan sistem, pemeliharaan database, dan manajemen pengolahan pernyataan SQL.
Bagian ini merangkum kendala paling umum di dalam sistem dan waktu respon database.
Tidak membuat penggunaan perangkat yang tersedia di server – Sebuah perusahaan pembelian beberapa disk drive karena suatu alasan. Jika Anda tidak menggunakannya sesuai dengan menyebarkan terpisah database komponen penting, Anda membatasi kemampuan kinerja.Memaksimalkan penggunaan sumber daya sistem adalah sama pentingnya dengan memaksimalkan penggunaan kemampuan database server.
Tidak sering melakukan COMMIT s – Gagal untuk menggunakan s COMMIT atau ROLLBACK periodik selama beban batch s berat akhirnya akan mengakibatkan kemacetan database.
Membiarkan batch beban mengganggu pemrosesan harian – Menjalankan beban batch selama waktu ketika database diharapkan akan tersedia akan menyebabkan masalah untuk semua orang. Proses batch akan berada dalam pertempuran terus-menerus dengan pengguna akhir sumber daya sistem.
Karena ceroboh saat membuat laporan SQL – sembarangan membuat laporan kompleks SQL akan lebih dari mungkin berkontribusi ke waktu respons di bawah standar.
TIP: Anda dapat menggunakan berbagai cara untuk mengoptimalkan struktur pernyataan SQL, tergantung pada langkah-langkah yang diambil oleh server database selama proses statemen SQL.
Menjalankan beban batch dengan indeks tabel – Anda bisa berakhir dengan beban batch yang berjalan sepanjang hari dan malam semua, sebagai lawan dari beban batch yang selesai dalam beberapa jam. Indeks memperlambat batch beban yang mengakses persentase tinggi baris pada tabel.
Setelah pengguna konkuren terlalu banyak memori yang dialokasikan – Sebagai jumlah database secara bersamaan dan pengguna sistem tumbuh, Anda mungkin perlu mengalokasikan memori untuk proses berbagi. Lihat administrator sistem Anda.
Membuat indeks pada kolom dengan nilai-nilai unik beberapa – Pengindeksan pada kolom seperti GENDER, yang hanya memiliki dua nilai yang unik, sangat tidak efisien. Sebaliknya, cobalah untuk indeks kolom yang akan kembali persentase rendah baris dalam query.
Membuat indeks pada meja kecil – Pada saat indeks direferensikan dan data membaca, meja penuh bisa memindai telah selesai dilaksanakan.
Tidak sistem pengelolaan sumber daya secara efisien – pengelolaan Miskin sumber daya sistem dapat hasil dari menyia-nyiakan ruang selama inisialisasi database, pembuatan meja, fragmentasi tidak terkontrol, dan sistem yang tidak teratur / pemeliharaan database.
Bukan ukuran tabel dan indeks benar – perkiraan Miskin untuk tabel dan indeks yang tumbuh pesat dalam lingkungan database yang besar dapat mengakibatkan masalah fragmentasi yang serius, yang jika tidak cenderung, akan snowball menjadi masalah yang lebih serius.
Built-In Peralatan Tuning
Periksa dengan Anda DBA atau database vendor untuk menentukan apa alat yang tersedia bagi Anda untuk mengukur kinerja dan tuning. Anda dapat menggunakan alat-tuning kinerja untuk mengidentifikasi kekurangan dalam jalur akses data, di samping itu, alat ini kadang-kadang dapat menyarankan perubahan untuk meningkatkan kinerja SQL pernyataan tertentu.
Oracle memiliki dua alat populer untuk mengelola kinerja pernyataan SQL. Alat ini menjelaskan rencana dan tkprof. Alat ini menjelaskan rencana mengidentifikasi jalur akses yang akan diambil saat pernyataan SQL dijalankan. tkprof mengukur kinerja oleh waktu yang telah berlalu selama setiap tahap proses pernyataan SQL. Oracle Corporation juga menyediakan alat-alat lain yang membantu dengan pernyataan SQL dan analisis database, tetapi dua disebutkan di sini adalah yang paling populer. Jika Anda hanya ingin mengukur waktu yang telah berlalu dari query di Oracle, Anda dapat menggunakan SQL * Plus perintah SET WAKTU ON.
WAKTU SET ON dan perintah SET lainnya yang tercakup dalam lebih mendalam pada Hari 20, “SQL * Plus.”
Sybase SQL Server memiliki alat untuk laporan diagnostik SQL. Pilihan tersebut dalam bentuk perintah SET yang dapat Anda tambahkan untuk pernyataan SQL Anda. (Perintah-perintah ini mirip dengan perintah Oracle’sSET). Beberapa perintah umum yang SHOWPLAN SET ON, SET STATISTIK IO ON, dan SET STATISTIK ON TIME. Perintah-perintah ini SET menampilkan output tentang langkah-langkah yang dilakukan dalam query, jumlah membaca dan menulis yang dibutuhkan untuk melakukan query, dan laporan-parsing informasi umum. SQL Server perintah SET tercakup pada Hari 19, “Transact-SQL: Sebuah Pengantar.”
Ringkasan
Dua unsur utama pelurusan, atau tuning, secara langsung mempengaruhi kinerja pernyataan SQL: tuning tuning aplikasi dan database. Masing-masing memiliki peran sendiri, tapi tidak dapat secara optimal disetel tanpa yang lain. Langkah pertama menuju kesuksesan adalah untuk tim teknis dan insinyur sistem untuk bekerja sama untuk menyeimbangkan sumber daya dan mengambil keuntungan penuh dari database fitur yang membantu meningkatkan kinerja.Banyak fitur tersebut dibangun ke dalam perangkat lunak database yang disediakan oleh vendor.
Aplikasi pengembang harus tahu data. Kunci untuk desain database yang optimal adalah pengetahuan menyeluruh data aplikasi. Pengembang dan programer produksi harus tahu kapan menggunakan indeks, kapan harus menambah indeks, dan kapan harus memungkinkan untuk menjalankan pekerjaan batch. Selalu merencanakan dan beban batch batch processing tetap terpisah dari pengolahan transaksi harian.
Database dapat disetel untuk meningkatkan kinerja aplikasi individu yang mengaksesnya.Database administrator harus peduli dengan operasi sehari-hari dan kinerja database. Selain tuning cermat yang terjadi di belakang layar, DBA biasanya dapat memberikan saran kreatif untuk mengakses data lebih efisien, seperti misalnya memanipulasi indeks atau membangun kembali pernyataan SQL. DBA juga harus akrab dengan alat-alat yang dapat segera tersedia dengan software database untuk mengukur kinerja dan memberikan saran untuk tweaker pernyataan.
Sumber ; http://www.webbasedprogramming.com


    3. Buat kesimpulan dari materi SQL Tuning atau

      Optimasi Queri
  1. Hindari mismatch tipe data untuk pengindeksan kolom
Kebanyakan orang menggunakan tanda kutip tunggal (dalam kondisi filter) terlepas dari tipe data yang mereka query. Hal Ini membuat oracle melakukan internal typecast ke tipe data yang dibutuhkan.
Sebelum Optimasi
Setelah Optimasi
select name,age,city,state
from employee
where employee_id=’1000′;
select name,age,city,state
from employee
where employee_id=1000;
Waktu yang dibutuhkan : 2.3 sec
Waktu yang dibutuhkan : 0.3 sec
  1. Hindari fungsi pada kolom yang diindeks
Biasanya, kita melakukan identifikasi kolom yang paling sering di query kemudian dibuat index pada kolom tersebut. Tapi query kita menggunakan fungsi pada kolom yang terindeks. Hal ini akhirnya akan membatalkan tujuan menciptakan indeks pada kolom tersebut.
Sebelum Optimasi
Setelah Optimasi
select name,age,city
from employee
where substr(employee_name,1,3)=’kar’;
select name,age,city
from employee
where employee_name like ‘kar%’;
Waktu yang dibutuhkan : 2.8 sec
Waktu yang dibutuhkan : 0.3 sec
Jika kita terpaksa harus mengunakan fungsi pada query tersebut maka kita bisa membuat function based index pada kolom tersebut.
  1. Menentukan kondisi pada WHERE bukan pada HAVING
Sebelum Optimasi
Setelah Optimasi
select name,
count(1)
from employee
group by name
having name=’karthi’;
select name,
count(1)
from employee
where name=’karthi’
group by name;
Waktu yang dibutuhkan = 2.2 sec
Waktu yang dibutuhkan = 0.3 sec
Ini bukanlah sebuah error. Jika filter dilakukan sebelum pengelompokan, maka semua data yang tidak perlu akan dikelompokan dan akhirnya data yang dibutuhkan akan difilter. Menerapkan filter sebelum pengelompokan akan menghindari sortasi dan pengelompokkan yang tidak perlu.
  1. Penggunaan join untuk mengganti inner query
Sebelum Optimasi
Setelah Optimasi
select employee_name
from employee where employee_id in ( select employee_id from defaulters)
select employee_name
from employee e,
defaulters d
where e.employee_id=d.employee_id
Waktu yang dibutuhkan : 14.1 sec
Waktu yang dibutuhkan : 5.5 sec
Hal ini sebenarnya dianggap sebagai praktek yang buruk pada penulisan SQL, menulis hasil inner query pada tiap-tiap baris hasil query tabel utama.
Sebelum Optimasi
Setelah Optimasi
select so.documnet_number
count(1)
from activation a,
serv_ord so,
task t
where
t.documnet_number=
so.document_number
and  so.serv_item_id=a.serv_item_idgroup by so.document_number
select so.documnet_number
count(1)
from task t,
serv_ord so,
activation a,
where
t.documnet_number=
so.document_number
and  so.serv_item_id=a.serv_item_idgroup by so.document_number
Waktu yang dibutuhkan : 10 Sec
Waktu yang dibutuhkan : 2.1 Sec
  1. Menentukan tabel dengan ukuran paling kecil, pada urutan terakhir pada query join.
    Seperti yang kita lihat, menggunakan join menghasilkan hasil yang lebih baik daripada inner query. Kita harus mengurutkan tabel sedemikian rupa sehingga tabel terkecil akan ditentukan pada akhir di SQL, sehingga waktu oracle untuk membandingkan baris akan berkurang.
  2. Mengganti NOT IN dengan NOT EXISTS
Hal ini sama halnya dengan menghindari subquery
Sebelum Optimasi
Setelah Optimasi
Select count(1)
from task t
where t.document_number not in (
select tt.document_number from task_bkp)
select count(1)
from task t
where not exists
(select tt.document_number from task_bkp)
Waktu yang dibutuhkan : 500 Sec
Waktu yang dibutuhkan : 6 Sec
  1. Menggunkan FORALL sebagai pengganti FOR
Ini adalah salah satu fitur yang berguna, yang tersedia di oracle untuk memasukan bulk record.
Sebelum Optimasi
Setelah Optimasi
DECLARE
TYPE NumTab IS TABLE OF NUMBER(5) INDEX BY BINARY_INTEGER;
TYPE NameTab IS TABLE OF CHAR(15) INDEX BY BINARY_INTEGER;
pnums NumTab;
pnames NameTab;
BEGIN
FOR j IN 1..20000 LOOP — load index-by tables
pnums(j) := j;
pnames(j) := ‘Part No. ‘ || TO_CHAR(j);
END LOOP;
FOR i IN 1..20000 LOOP — use FOR loop
INSERT INTO parts VALUES (pnums(i), pnames(i));
END LOOP;
END;
DECLARE
TYPE NumTab IS TABLE OF NUMBER(5) INDEX BY BINARY_INTEGER;
TYPE NameTab IS TABLE OF CHAR(15) INDEX BY BINARY_INTEGER;
pnums NumTab;
pnames NameTab;
BEGIN
FOR j IN 1..20000 LOOP — load index-by tables
pnums(j) := j;
pnames(j) := ‘Part No. ‘ || TO_CHAR(j);
END LOOP;
FORALL I in 1 .. 20000 — use FORALL
INSERT INTO parts VALUES (pnums(i), pnames(i));
END;
Waktu yang dibutuhkan: 11.0 Sec
Waktu yang dibutuhkan: 0.5 sec
FORALL akan mengurangi waktu pengulangan pada PL/SQL dan SQL.
  1. Penggunaan BULK COLLECT
BULK COLLECT adalah suatu fitur yang disediakan oleh Oracle untuk menghindari penggunaan loop dalam pengumpulan data dari table. Untuk aplikasi pengolahan data berat, BULK COLLECT akan sangat berguna. Sebagai contoh, kita perlu memilih 1000 baris dari tabel dan memproses baris dan masukkan ke tabel lain, maka kita dapat menggunakan BULK COLLECT.
Sebelum Optimasi
Setelah Optimasi
Declare
Type bcode is table of products.barcode%TYPE;
i int;
barc bcode;
cursor cur_seq is
select barcode from products where rownum<100001;
begin
i:=0;
for cur_dta in cur_seq loop
i:=i+1;
barc:=cur_dta.barcode;
end loop;
end;
Declare
Type bcode is table of products.barcode%TYPE;
i int;
barc bcode;
begin
select barcode BULK COLLECT into barc from products where rownum<100001;
end;
Waktu yang dibutuhkan : 17sec
Waktu yang dibutuhkan : 1.41 sec
Ringkasan Optimasi
  • Gunakan kode seragam di seluruh aplikasi standar
  • Hindari ketidakcocokan jenis data untuk indeks kolom
  • Hindari fungsi pada kolom indeks
  • Pindahkan kondisi dari klausa HAVING ke klausa WHERE
  • Gunakan joins bukan nested selects, jika memungkinkan
  • Mengganti Not IN dengan Not EXISTS atau OUTER JOIN
  • Gunakan bulk inserts pada insert banyak records
  • Gunakan klausa BULK COLLECT pada fetching records


Comments

Post a Comment

Popular posts from this blog

Cara Pembuatan Company Profile yang mampu menarik banyak Klien

Image
  Cara Membuat dan Contoh Company Profile yang Menarik Di era yang serba mudah seperti sekarang ini, ada banyak orang yang memutuskan untuk memulai bisnis-bisnis pertama mereka. Mulai dari bidang sandang, pangan, hingga meliputi bidang sehari-hari. Di antara proses pembuatan bisnis dan perusahaan itulah kemudian banyak diantara tim-tim kecil mereka yang mulai melakukan proses brainstorming atau berdiskusi bersama-sama untuk mengonsep perusahaan baru mereka. Lebih jauh lagi salah satu hal yang seringkali dirancang, baik di awal-awal pendirian perusahaan ataupun di tengah-tengah berjalannya perusahaan rintisan ini, adalah soal proses pembuatan company profile. Tapi sebenasfdfrnya apakah Anda semua tahu apa itu company profile, bagaimana cara membuat company profile, dan bagaimana sih contoh company profile yang menarik baik bagi konsumen atau malah bagi investor. Penasaran? Apa itu Company Profile? Company profile merupakan salah satu cara perusahaan untuk memperkenalkan
Read more

Nodeflux Company

Image
  Nodeflux adalah startup Intelligent Video Analysis (IVA) asli Indonesia . Fokus utama nodeflux adalah computer vision. Di indonesia ada perusahaan IVA lain, tapi itu rata-rata cuma sebagai broker produk IVA luar atau produknya punya luar negeri. Nodeflux yang dirintis oleh Meidy Fitranto dan Faris Rahman, mereka menjadi pemenang bersama enam pemenang lain di masing-masing kategori pada 9th SATU Indonesia Award 2018 dari PT Astra International Tbk. Penghargaan ini diberikan pada akhir Oktober lalu di ajang IdeaFest 2018 yang dibuka oleh Presiden Joko Widodo. Nodeflux dipilih sebagai contoh generasi muda yang mengolah cipta, rasa, dan karsa menjadi sebuah karya berguna bagi peningkatan kualitas hidup masyarakat Indonesia di bidang teknologi. Salah satu solusi Nodeflux adalah teknologi pengenalan wajah (face recognition) yang dipasang di perangkat CCTV, yang terhubung dengan database pencarian sesuai fungsi. Misalnya, data kependudukan atau data catatan kriminal. Saat ini Nodeflux teru
Read more