SQL TUNING TERHADAP APLIKASI CUSTOMER RESPONSE SYSTEM PADA ASTRA CREDIT COMPANIES
Andy
1200991492
Ellen Suwandi
1200991536
Handy Wijaya
1200991662
Abstrak
Tujuan dari penelitian pada Astra Credit Companies adalah mengidentifikasi faktorfaktor penyebab tingginya response time dari aplikasi Customer Response System, dari sisi database, dan menyediakan solusi bagi masalah yang diidentifikasi melalui pendekatan SQL tuning yang terdiri dari empat metode, yaitu pembuatan SQL function, restrukturisasi SQL, indexing, dan partitioning. Metode-metode yang digunakan dalam penelitian terdiri dari pengumpulan data, analisis, perancangan, dan evaluasi. Pengumpulan data dilakukan dengan cara penelitian lapangan, yaitu dengan melakukan survey ke perusahaan untuk mengadakan wawancara dengan pihak terkait, mempelajari dokumen perusahaan, dan mempelajari sistem berjalan di perusahaan. Analisis, perancangan, dan evaluasi dilakukan dengan cara uji lab dan studi kepustakaan. Hasil yang dicapai dari metodologi yang digunakan di atas adalah setelah dilakukan SQL tuning,kinerja dari aplikasi Customer Response Systemmengalami peningkatan, yang terlihat dari menurunnya response time. Keempat metode SQL tuning yang digunakan berhasil menurunkan response time baik secara terpisah maupun dalam kombinasi. Berdasarkan hasil penelitian dapat disimpulkan bahwa diperlukannya sebuah usaha perbaikan performance, salah satunya dengan pendekatan SQL tuning, terhadap aplikasi Customer Response Systemuntuk memperkecil response time dari aplikasi tersebut.
Kata Kunci SQL Tuning, aplikasi, Customer Response System.
1. PENDAHULUAN 1.1 Latar belakang
Dunia saat ini telah memasuki era globalisasi yang menuntut perusahaan-perusahaan yang ada untuk mampu bertahan dan menjawab berbagai tantangan bisnis yang semakin kompleks.Agar dapat terus bersaing dan berkembang, perusahaan harus mampu memanfaatkan dan mengelola sumber daya yang ada secara efektif dan efisien. Salah satu sumber daya yang penting dalam mendukung kelancaran proses bisnis perusahaan, yaitu teknologi informasi. Perkembangan teknologi informasi telah memberikan kemudahan dan dampak positif yang besar dalam berbagai aspek kehidupan, termasuk di bidang bisnis. Sistem informasi yang berjalan memerlukan sebuah database yang berguna untuk menyimpan dan mengolah data mentah menjadi informasi yang berguna bagi perusahaan. Seiring dengan perkembangan bisnis dan berjalannya waktu, jumlah data atau transaksi dalam perusahaan akan semakin banyak. Idealnya, dengan meningkatnya jumlah data transaksi, rentang waktu yang diperlukan untuk memproses data tersebut tetap stabil atau meningkat secara tidak signifikan. Namun realitanya tidak selalu seperti itu. Yang sering terjadi adalah semakin besar jumlah data dalam suatu database, kecepatan pemrosesan data akan menurun karena waktu yang diperlukan untuk memproses data juga menjadi lebih lama. Dengan tersedianya berbagai jenis processor, memory, dan disk drive yang semakin canggih dan cepat, godaan untuk mengadakan perangkat keras baru untuk meningkatkan kinerja akan semakin besar. Namun, perbaikan kinerja dengan pengadaan perangkat keras dapat dikatakan sebagai pemecahan masalah jangka pendek. Apabila permintaan dan beban kerja terus meningkat, kemungkinan besar perusahaan akan segera menghadapi kembali permasalahan yang sama. Selain itu, pengadaan perangkat keras tidak selalu mampu mengatasi permasalahan performance pada sistem. Suatu sistem yang dirancang secara buruk akan menghasilkan performance yang buruk, sebanyak apapun perangkat keras yang ditambahkan. Dengan demikian, diperlukan suatu teknik yang dapat menjaga dan bahkan meningkatkan kinerja dari databaseagar kinerja sistem informasi secara keseluruhan dapat ditingkatkan. Teknik ini disebut dengan performance tuning. Performance tuningtelah dilakukan oleh banyak perusahaan yang memilikidatabasedalam skala besar untuk mengatasi permasalahan kinerja pada sistem yang timbul sebagai konsekuensi dari jumlah data perusahaan yang semakin besar. Astra Credit Companies merupakansalah satu perusahaan pelopor di bidang consumer finance. Astra Credit Companies melayani pembelian kendaraan bermotor secara kredit. Untuk mendukung layanan kepada pelanggan, ACC menyediakan fasilitasCall
Center. Call Center ACC ini memanfaatkan suatu sistem berbasis web yang dinamakan CRS (Customer Response System). Seiring berjalannya waktu, database dari aplikasi CRSjuga semakin besar. Ukuran database yang semakin besar ini disinyalir menjadi salah satu faktor penyebab menurunnyaperformance dari aplikasi CRS. Bukti dasar dari kinerja aplikasi yang memburuk, yaitu lamanya waktu page load dari beberapa halaman CRS, khususnya halaman-halaman yang berkaitan dengan produk-produk andalan Astra Credit Companies, yakni ACP dan Fastrack Financing.Oleh karena itu, pihak Astra Credit Companies merasa perlu melakukan tuning terhadap aplikasi CRS.
1.2 Ruang lingkup Berdasarkan hasil survei dan wawancara dengan pihak Astra Credit Companies, ruang lingkup dari penelitian ini akan dibatasi pada perbaikanperformance dari aplikasi bermasalah, yaitu aplikasi Customer Response System.Performance aplikasi diukur dari response time dari halaman-halaman web pada aplikasi. Fokus dari penelitian ini juga dipersempit untuk mencakup hanya halaman-halaman web aplikasi CRS yang berkaitan dengan dua produk favorit ACC, yakni ACP dan Fastrack Financing,yang memiliki response time paling tinggi. Dalam penulisan skripsi ini,pendekatan performance tuning yang digunakan adalah SQL tuning yang mencakup empat metode, yaitu pembuatan function, restrukturisasi SQL,indexing, danpartitioning. Pembuatan function dilakukan untuk memanfaatkan soft parsing pada query sehingga waktu pemrosesan query menjadi lebih cepat.Restrukturisasi SQL dilakukan denganmenulis ulang queryke bentuk lain yang lebih efektif.Indexing dilakukan pada kolom tabel yang sering dijadikan filter pada klausa where dengan tujuan untuk mempercepat pencarian data.Partitioning dilakukan untuk memecah tabel yang besar menjadi bagian-bagian yang lebih kecil sehingga jumlah data yang perlu diperiksa dalam pemrosesan suatu query dapat dibatasi.
1.3 Tujuan dan Manfaat Tujuan yang ingin dicapai dari penulisan skripsi ini, yaitu sebagai berikut: 1. Mengidentifikasi masalah berkaitan dengan lamanya response timedari halamanhalaman aplikasi Customer Response System yang berkaitan dengan produk ACP dan Fastrack Financing.
2. Menyediakan alternatif solusi pemecahan masalah yang diidentifikasi melalui performance tuning dengan pendekatan SQL tuning. Manfaat yang dapat diperoleh dari penulisan skripsi ini, yaitu sebagai berikut: 1. Meminimalkan response time dari halaman-halaman aplikasi Customer Reponse Systemyang berkaitan dengan produk ACP dan Fastrack Financinguntuk mendukung aktivitas pelayanan konsumen oleh agen teleservice dan telemarketing Astra Credit Companies. 2. Menekan biaya maintenance dan penambahan perangkat keras di masa yang akan datang dengan mengoptimalkan kinerja sistem yang ada melalui SQL tuning.
1.4 Metodologi Penulisan skripsi ini dilakukan dalam beberapa tahap sebagai berikut: 1. Pengumpulan Data •
Pengumpulan data dilakukan secara langsung di Astra Credit Companies selama 300 jam, yaitu setiap hari rabu dan kamis dari tanggal 14 September 2011 hingga 22 Desember 2011.
•
Melakukan wawancara dengan pihak-pihak terkait mengenai aplikasi Customer Response System dan proses bisnis berjalan untuk memperoleh pengetahuan awal mengenai masalah dan kebutuhan perusahaan.
•
Melakukan observasi terhadap database dan aplikasi Customer Response System yang sedang berjalan di perusahaan.
•
Melakukan pengukuran awal terhadap kinerja aplikasi Customer Response Sistem yang berjalan.
•
Melakukan studi literatur yang relevan terhadap penelitian sebagai landasan teori dalam penulisan skripsi ini.
2. Analisis •
Mengidentifikasi inti-inti permasalahan berdasarkan hasil observasi terhadap aplikasi Customer Response System dan kondisi database yang sedang berjalan.
•
Menentukan tujuan dan ruang lingkup penelitian berkaitan dengan metode SQL tuning yang akan digunakan dan batasan halaman-halaman aplikasi yang akan dilakukan tuning.
•
Melakukan uji lab terhadap beberapa metode tuning untuk memeriksa kesesuaian teori terhadap sistem yang berjalan.
3. Perancangan Pada tahap desain dan perancangan, penulis akanmerancang beberapa alternatif solusi bagi permasalahan yang telah diidentifikasi, berdasarkan metode SQL tuning yang telah ditetapkan pada tahap analisis, yaitu pembuatan function, restrukturisasi SQL,indexing, dan partitioning. 4. Evaluasi Pada tahap terakhir ini, penulis akan mengembangkan rancangan solusi ke dalam sistem dan melakukan pengukuran terhadap kinerja dari sistem yang baru (setelah dilakukan SQL tuning)untuk dibandingkan dengan kinerja dari sistem yang lama (sebelum dilakukan SQL tuning). Jika kinerja sistem baru lebih baik maka penelitian dikatakan telah berhasil.
1.5 Sistematika Penulisan Penulisan skripsi ini dijabarkan secara sistematis ke dalam beberapa bab yang akan dijelaskan lebih lanjut di dalam setiap bab. Adapun sistematika penulisan setiap bab adalah sebagai berikut: •
Bab 1 : Pendahuluan Pada bab ini diuraikan mengenai: -
Latar belakang pemilihan topik
-
Ruang lingkup penelitian
-
Tujuan yang ingin dicapai dari penelitian
-
Manfaat yang dihasilkan dari penelitian
-
Metodologi yang digunakan dalam penelitian mulai dari pengumpulan data hingga evaluasi
•
Sistematika penulisan skripsi
Bab 2 : Landasan Teori Bab ini berisi teori-teori yang melandasi penelitian. Teori-teori tersebut dibagi ke dalam dua kelompok besar, yaitu teori umum dan teori khusus. -
Teori umum, merupakan teori-teori yang mendefinisikan objek-objek umum dalam penelitian, seperti database, perangkat lunak, dan perangkat keras.
-
Teori khusus, merupakan teori-teori yang mendukung analisis dan perancangan solusi, misalnya teori mengenai indexing danpartitioning.
•
Bab 3 : Analisis dan Perancangan Bab ini terbagi menjadi tiga bagian antara lain: -
Analisis perusahaan, berisi informasi mengenai sejarah perusahaan, struktur organisasi perusahaan, dan pembagian tugas dan wewenang serta kondisi kerja di dalam perusahaan.
-
Analisis sistem yang berjalan, membahas gambaran kondisi sistem yang sedang berjalan dan permasalahan yang sedang dihadapi.
-
Perancangan SQL tuning, menjelaskan beberapa alternatif solusi yang dirancang penulis bagi permasalahan yang diidentifikasi.
•
Bab 4 : SQL Tuning dan Evaluasi Bab ini menguraikan tentang pelaksanaan dari rancangan SQL tuning serta evaluasi kinerja sistem yang lama dan yang baru.
•
Bab 5 : Simpulan dan Saran Bab terakhir ini berisi simpulan dari hasil penelitian yang telah dilakukan serta saran-saran yang disampaikan oleh penulis bagi perusahaan untuk pengembangan selanjutnya.
2. TEORI PENDUKUNG 2.1 Definisi aplikasi Menurut Connolly-Begg (2010, p67), aplikasi adalah sebuah program komputer yang berinteraksi dengan database dengan melakukan pengaksesan data melalui DBMS. Sedangkan menurut Indrajani (2009, p5), aplikasi adalah program untuk menentukan aktivitas pemrosesan informasi yang dibutuhkan untuk penyelesaian tugas-tugas khusus dari pemakai komputer.
2.2 Definisi database Definisi database menurut Connolly-Begg (2010, p65) adalah kumpulan data, beserta deskripsinya, yang saling berhubungan secara logis dan dirancang untuk memenuhi kebutuhan informasi oleh suatu organisasi. Sedangkan menurut Bryla-Loney (2008, p4),database adalah kumpulan data dalam disk yang terdapat dalam satu atau beberapa
filepada sebuah database server yang mengumpulkan dan mengelolainformasi yang saling berkaitan. Empat elemen database menurut Whitten-Bentley (2007, p520-p522), yaitu sebagai berikut: 1. Field Field merupakan unit terkecil dari data, yang memiliki arti, yang disimpan di dalam file atau database. Ada empat jenis field, yaitu sebagai berikut: a. Primary key, adalah field yang nilainya mengidentifikasikan satu dan hanya satu record di dalam sebuah file. Contohnya, CUSTOMER NUMBER secara unik mengidentifikasi satu record CUSTOMER di dalam database. Primary key dapat dibuat dengan mengkombinasikan dua atau lebih field, disebut sebagai concatenated key. b. Secondary key, merupakan identifier alternatif bagi database. Nilai dari secondarykey dapat mengidentifikasi satu record tunggal (seperti primarykey) atau himpunan record (misalnya semua ORDERS yang memiliki ORDER STATUS berupa “back ordered”). c. Foreign key, merupakan penunjuk ke record dari file lain di dalam database. Foreign key memungkinkan database untuk menghubungkan record-record dengan tipe tertentu ke record dengan tipe lain. Contohnya, ORDER RECORD
mengandung
“mengidentifikasi”
atau
foreign
key
“menunjuk
CUSTOMER ke”
record
NUMBER
untuk
CUSTOMER
yang
berhubungan dengan ORDER. Foreign di suatu tabel harus memiliki pasangan primary key di tabel yang berhubungan. Dengan demikian, CUSTOMER NUMBER di dalam tabel ORDERS harus memiliki pasangan CUSTOMER NUMBER yang sama di dalam tabel CUSTOMERS agar dapat terjadi relasi antara kedua tabel tersebut. d. Descriptive field, adalah field lain (bukan key) yang menyimpan data bisnis. Contohnya EMPLOYEE NAME, DATE HIRED, dan PAY RATE. 2. Record Record adalah kumpulan field yang disusun dalam format yang sudah ditentukan sebelumnya. Contohnya, suatu CUSTOMER RECORD dideskripsikan oleh fieldfield berikut: CUSTOMER (NUMBER, LAST-NAME, FIRST-NAME, ...) 3. File dan Tabel
Record-record sejenis disusun ke dalam kelompok yang disebut file. Dalam sistem database, file seringkali disebut tabel. File adalah kumpulan dari semua kejadian dari suatu struktur record. Tabel adalah database relasional yang ekuivalen terhadap file.
2.3 Structured query language (SQL) Menurut Williams-Sawyer (2011, p514),Structured Query Language (SQL) adalah sebuah bahasa query yang digunakan untuk mengakses dan memanipulasi data dari sebuah database management system.
2.3.1 Komponen – komponen SQL Dua komponen utama SQL, menurut Connolly-Begg (2010, p92), yaitu sebagai berikut: 1. Data Definition Language (DDL), merupakan sebuah bahasa yang memungkinkan DBA atau pemakai untuk mendeskripsikan dan membuat nama entitas, atribut, dan relasi yang dibutuhkan untuk sebuah aplikasi. 2. Data Manipulation Language (DML), merupakan sebuah bahasa yang menyediakan sebuah kumpulan operasi untuk mendukung operasi manipulasi dasar terhadap data di dalam database. Operasi DML bisanya mengandung hal-hal sebagai berikut: •
Menambahkan sebuah data baru ke dalam database
•
Memodifikasi data yang sudah tersimpan dalam database
•
Mengambil atau mengakses data yang sudah ada di database
•
Menghapus data yang sudah ada di dalam database
2.4 Performance tuning 2.4.1 Definisi performance tuning Menurut Alapati (2009, p1041),performance tuning merupakan usaha untuk meningkatkan kinerja atau memperbaiki kinerja yang memburuk. Sedangkan menurut Chan (2008, pp1-2),performance tuning merupakan kegiatan mengidentifikasi masalah yang paling signifikan dan melakukan perubahan-perubahan yang sesuai untuk mengurangi atau mengeliminasi efek dari masalah yang bersangkutan.
2.4.2 Manfaat performance tuning
Menurut Connolly-Begg (2010, p508), manfaat-manfaat yang diperoleh dari performance tuning, yaitu: •
Mengurangi kebutuhan untuk menambah perangkat keras baru.
•
Dapat mengurangi ukuran dari konfigurasi perangkat keras sehingga dapat menekan biaya dan jumlah perangkat keras yang diperlukan, dan dengan demikian dapat menurunkan biaya maintenance bagi perangkat keras.
•
Sistem yang berhasil dilakukan tuning akan menghasilkan response time yang lebih cepat dan throughput yang lebih baik. Sebagai hasilnya, user maupun organisasi menjadi lebih produktif.
•
Response time yang lebih cepat dapat meningkatkan moral dari staf.
Response time yang lebih cepat dapat meningkatkan kepuasan pelanggan.
2.4.3 Pendekatan performance tuning Menurut Chan (2008, pp1-1), terdapat tiga pendekatan dalam melakukan performance tuningpada Oracledatabase, yaitu sebagai berikut: 1. Performance planning Performance planning merupakan peningkatan performance dari Oracle database dengan memeriksa desain aplikasi dan menggunakan statistik untuk memantau performance aplikasi. 2. Instance tuning Instance tuning merupakan pendekatan performance tuning dengan memperbaiki pengaturan dari Oracle instance, seperti konfigurasi memori, konfigurasi I/O, penggunaan statistik performance otomatis, penggunaan diagnosa performance otomatis, dan penggunaan performance view. 3. SQL tuning SQL tuningdilakukan dengan mencari cara yang lebih efisien untuk memproses workload yang sama. Dalam SQL tuning, dimungkinkan untuk mengubah execution planpada perintah yang ada tanpa mengubah fungsionalitas yang ada untuk mengurangi pemakaian resource.
2.5 Response time Menurut Alapati (2009, p1162),response time adalah waktu yang dibutuhkan oleh Oracle untuk mengeksekusi sebuah query, ditambah waktu yang diperlukan proses tersebut untuk menunggu resource, seperti data buffer. Ruang lingkup utama yang menjadi fokus
dalam melakukan performance tuning adalah mengatasi permasalahan pada database yang berkontribusi terhadap responsetime yang tinggi.
2.6 SQL tuning Menurut Bryla-Loney (2008, p247), kunci dari melakukan SQL tuning adalah meminimalisir pencarian path yang digunakan database untuk mencari data. Menurut Chan (2008, pp11-5 – pp11-16), langkah-langkah dalam melakukan SQL tuning, antara lain sebagai berikut: 1. Memeriksa execution plan Langkah ini diperlukan untuk memeriksa apakah access path yang digunakan sudah optimal. Ketika memeriksa execution plan, beberapa hal yang perlu diperhatikan, antara lain sebagai berikut: •
Driving table merupakan tabel yang memiliki filter paling selektif.
•
View digunakan secara efisien. Perhatikan daftar SELECT untuk melihat apakah akses terhadap view diperlukan.
•
Apakah terdapat Cartesian product yang tidak diinginkan.
•
Apakah setiap tabel diakses secara efisien
Perhatikan predikat dalam perintah SQL dan jumlah baris di dalam tabel. Perhatikan langkah-langkah yang “mencurigakan”, seperti full table scan pada tabel dengan jumlah baris yang banyak, dengan predikat pada klausa where. Tentukan mengapa index tidak digunakan pada predikat yang selektif tersebut. Apabila kondisi-kondisi seperti itu belum optimal, maka pertimbangkan untuk melakukan restrukturisasi perintah SQL atau mengatur ulang index yang ada. 2. Melakukan restrukturisasi perintah SQL Seringkali, menulis kembali perintah SQL yang tidak efisien jauh lebih mudah dibandingkan memodifikasinya. Apabila Anda memahami tujuan dari suatu perintah SQL, maka Anda bisa dengan cepat dan mudah menulis sebuah perintah baru yang memenuhi persyaratan yang ditentukan. 3. Melakukan restrukturisasi index Beberapa hal yang dapat dilakukan, antara lain sebagai berikut: •
Menghapus index yang tidak selektif untuk mempercepat DML
•
Mempertimbangkan untuk menata ulang kolom-kolom dalam concatenated index yang ada
•
Menambahkan kolom kepada index untuk meningkatkan selektivitas
4. Memodifikasi atau menonaktifkan trigger Penggunaan trigger dapat menghabiskan sumber daya sistem. Apabila penggunaan trigger terlalu banyak, performance bisa menjadi lebih buruk sehingga Anda perlu melakukan modifikasi atau menonaktifkan beberapa trigger yang ada. 5. Melakukan restrukturisasi data Setelah melakukan restrukturisasi index dan perintah SQL, Anda dapat mempertimbangkan untuk merestrukturisasi data. •
Periksa kembali perancangan data Anda. Lakukan perubahan terhadap perancangan sistem jika hal tersebut dapat meningkatkan performance.
•
Pertimbangkan partitioning, apabila diperlukan.
2.7 Indexing 2.7.1 Pengertian index Menurut Connolly-Begg (2010, p242),index adalah sebuah struktur yang menyediakan akses ke baris-baris dari sebuah tabel berdasarkan nilai dari satu atau lebih kolom. Sedangkan menurut Bryla-Loney (2008, p17), index adalah sebuah struktur yang memungkinkan kita untuk mengakses data lebih cepat dalam sebuah tabel ketika suatu himpunan bagian dari kumpulan baris yang ada akan diambil atau diakses dalam tabel tersebut. Sebuah index menyimpan nilai dari kolom-kolom yang di-index, bersama dengan physical RowID dari baris yang memiliki nilai dari index tersebut. Apabila terdapat kecocokan antara nilai pencarian dengan nilai pada index, RowID pada index akan menunjuk ke suatu lokasi baris di dalam tabel.
2.7.2 Jenis-jenis index Menurut Alapati (2009, p297),index pada Oracle database dibagi menjadi tiga jenis, yaitu sebagai berikut: •
Unique dan nonunique index Unique index adalah index yang berdasarkan pada kolom yang nilainya unik. Ketika kita menempatkan unique constraint pada suatu kolom, Oracle akan secara oromatis membuatkan unique index pada kolom tersebut.
•
Primary dan secondary index Primary index adalah unique index pada suatu tabel yang harus selalu menyimpan suatu nilai, sehingga tidak boleh bernilai NULL. Secondary index adalah index lain pada tabel yang sama yang tidak harus bersifat unik.
•
Composite index Composite index, atau dikenal juga sebagai concatenated index, adalah index yang terdiri dari dua kolom atau lebih dari tabel yang sama. Composite index sangat berguna dalam meningkatkan pemilihan predikat dari klausa WHERE. Biasanya, jika penggunaan index individual menghasilkan pemilihan yang kurang baik, maka penggunaan composite index akan meningkatkan selektivitas.
2.7.3 Beberapa hal yang menyebabkan index tidak digunakan Menurut Niemec (2007, p40), terdapat beberapa situasi di mana logika dari klausa WHERE akan membuat Oracle tidak menggunakan index yang ada, antara lain sebagai berikut: a. Penggunaan operator NOT EQUAL (<> dan !=) Index hanya dapat digunakan untuk mencari data yang memang ada dalam sebuah tabel. Setiap kali operator-operator not equal digunakan dalam klausa WHERE, maka index pada kolom-kolom bersangkutan tidak dapat digunakan. b. Penggunaan IS NULL atau IS NOT NULL Ketika kita menggunakan IS NULL atau IS NOT NULL dalam klausa where, index pada kolom yang bersangkutan tidak akan digunakan karena nilai NULL tidak dikenali. Tidak ada nilai pada database yang sama dengan sebuah nilai NULL, bahkan NULL sendiri tidak dapat dibandingkan dengan nilai NULL lain. Untuk mencegah nilai-nilai NULL masuk ke sebuah kolom, kita dapat menggunakan NOT NULL ketika membuat atau melakukan alter pada tabel. c. Penggunaan function Selain function-based index, penggunaan fungsi-fungsi pada kolom-kolom yang memiliki index pada klausa WHERE dalam sebuah perintah SQL akan menyebabkan optimizer mengabaikan index yang ada. Beberapa fungsi yang umum digunakan yaitu TRIM, TRUNC, UPPER, LOWER, SUBSTR, TO_DATE, TO_CHAR, and INSTR. Semua fungsi ini akan menyebabkan nilai dari kolom bersangkutan berubah. Oleh karena itu, index dan kolom-kolom yang ditunjuk tidak akan digunakan.
2.8 Partitioning 2.8.1 Pengertian partitioning
Menurut Oracle Corporation (2011, pp1-1),partitioning adalah pemecahan tabel dan index yang berukuran besar ke dalam kelompok-kelompok yang lebih kecil, yang sifatnya
transparan
terhadap
aplikasi.
Sedangkan
menurut
Bryla-Loney
(2008,
p266),partitioning adalah pembagian data dari suatu tabel yang berukuran besar ke dalam beberapa subtabel. Menurut Alapati (2009, p1076), tabel yang dipartisi biasanya menghasilkan peningkatan yang besar bagi performance, dan tabel-tabel yang dipartisi lebih mudah dikelola. Dengan mempartisi suatu tabel menjadi beberapa subpartisi, kita pada dasarnya telah membatasi jumlah data yang perlu diperiksa untuk memenuhi query yang kita bangun. Apabila terdapat tabel-tabel berukuran besar, dengan jumlah record di atas 10 juta, pertimbangkan untuk mempartisi tabel-tabel tersebut.
2.8.2 Partition Key Menurut Oracle Corporation (2011,pp2-2),partitioning key adalah satu atau lebih kolom yang menentukan pada partisi mana setiap baris dalam tabel disimpan.Oracle secara otomatis mengarahkan operasi insert, update, dan delete ke partisi yang tepat dengan partitioning key.
2.8.3 Strategi partitioning Menurut Oracle Corporation (2011, pp2-6 – pp2-9), Oracle partitioning menawarkan tiga metode dasar dalam distribusi data sebagai strategi partitioning dasar yang mengontrol bagaimana data ditempatkan ke dalam partisi-partisi individual, yaitu range, hash, dan list. Dengan metode-metode distribusi data tersebut, strategi partitioning dapat dibagi ke dalam dua kategori, yaitu sebagai berikut: 1. Single-Level Partitioning Pada single-level partitioning, suatu tabel didefinisikan dengan menetapkan salah satu dari metode distribusi data berikut, dengan satu atau lebih kolom sebagai partitioningkey: a. Range partitioning Range partitioning memetakan data ke partisi berdasarkan rentang dari nilainilai partitioning key yang Anda tentukan untuk setiap partisi. Contohnya, pada suatu tabel dengan kolom Tanggal sebagai partitioning key, partisi
January-2010 akan berisi baris-baris dengan nilai partitioning key dari 01Jan-2010 hingga 31-Jan-2010. Setiap partisi memiliki klausa VALUES LESS THAN, yang menetapkan batas atas untuk partisi. Literal MAXVALUE dapat didefinisikan untuk partisi tertinggi. MAXVALUE merepresentasikan suatu nilai tak terbatas bagi nilai-nilai yang memungkinankan untuk partitioning key, termasuk nilai NULL. b. List partitioning List partitioning memungkinkan Anda untuk mengontrol secara eksplisit bagaimana baris-baris dipetakan ke dalam partisi dengan menetapkan suatu daftar nilai-nilai diskrit untuk partitioning key dalam deskripsi setiap partisi. Contohnya, pada suatu tabel dengan kolom Region sebagai partitioning key, partisi East Sales Region akan berisi nilai-nilai New York, Virginia, dan Florida. Partisi DEFAULT memungkinkan Anda untuk tidak menetapkan semua nilai-nilai yang memungkinkan pada suatu list-partitioned table dengan menggunakan partisi default, sehingga semua baris yang tidak terpetakan ke partisi lain tidak menyebabkan terjadinya error. c. Hash partitioning Hash partitioning memerakan data ke partisi berdasarkan algoritma hash yang diterapkan oleh Oracle kepada partitioning key yang Anda tetapkan. Algoritma hash mendistribusikan baris-baris dalam partisi secara merata, sehingga partisi memiliki ukuran yang kurang lebih sama. 2. Compositepartitioning Composite partitioning merupakan kombinasi dari metode-metode dasar distribusi data. Suatu tabel dipartisi dengan salah satu metode distribusi data. Masing-masing partisi tersebut kemudian dibagi lagi ke dalam beberapa subpartisi dengan metode distribusi data kedua.
2.9 Restrukturisasi SQL Menurut Chan (2008, pp11-7), restrukturisasi SQL adalah penulisan ulang suatu perintah SQL yang tidak efisien ke dalam bentuk lain yang lebih optimal. Menurut Chan (2008, pp11-7), beberapa restrukturisasi SQL yang umum dilakukan, antara lain: 1. Menulis predikat menggunakan AND dan =
Untuk meningkatkan efisiensi SQL, sebaiknya gunakan equijoin. Perintah-perintah yang melakukan equijoin pada kolom yang tidak dikenakan SQL function akan lebih mudah untuk dilakukan tuning. 2. Menghindari penggunaan SQL function untuk kolom pada klausa WHERE Penggunaan SQL function dengan suatu kolom tertentu sebagai parameternya akan menyebabkan
optimizer
mengabaikan
penggunaan
index
pada
kolom
bersangkutan. Hindari juga penggunaan konversi implisit. Sebagai contoh, misalkan kita ingin menggunakan index pada kolom charcol dengan tipe data VARCHAR2, namun klausa WHERE yang digunakan adalah seperti pada contoh berikut: AND charcol= numexpr
Di mana numexpr merupakan ekspresi dengan tipe data NUMBER, maka Oracle akan menerjemahkan ekspresi tersebut menjadi: AND TO_NUMBER(charcol)= numexpr
3. Menulis perintah SQL yang terpisah untuk tugas-tugas yang spesifik SQL bukan bahasa prosedural. Oleh karena itu, penggunaan sebuah SQL untuk melakukan banyak tugas yang berbeda-beda memberikan hasil yang tidak optimal. Apabila kita ingin menggunakan SQL untuk melakukan beberapa tugas, maka hindari menggunakan satu perintah untuk melakukan banyak tugas, melainkan pisahkan tugas-tugas tersebut ke dalam beberapa perintah yang berbeda. 4. Penggunaan EXIST dan IN untuk subquery Dalam kondisi-kondisi tertentu, penggunaan IN akan lebih baik dibandingkan EXISTS. Apabila predikat yang selektif berada pada subquery, maka sebaiknya gunakan IN. Apabila predikat yang selektif berada pada parent query, maka gunakan EXISTS. Pada situasi tertentu, Oracle dapat menulis ulang suatu subquery dengan klausa IN untuk memanfaatkan selektivitas yang ditetapkan di dalam subquery. Sebaliknya, penggunaan EXISTS bermanfaat apabila sebagian besar filter yang selekif berada pada parent query. Hal ini memungkinkan predikat-predikat selektif pada parent query diaplikasikan terlebih dahulu sebelum menyaring baris-baris berdasarkan kriteria EXISTS. 5. Subquery unnesting Seringkali, suatu query yang mengandung subquery yang kompleks dapat ditingkatkan kinerjanya dengan mengubah subquery menjadi join.
Sementara itu, menurut Alapati (2009, p1066-p1067), selain menghindari penggunaan SQL functions pada klausa WHERE dan penggunaan EXISTS dan IN untuk subquery, beberapa panduan lain dalam melakukan restrukturisasi SQL, antara lain sebagai berikut: 1. Menggunakan join yang tepat Beberapa hal yang perlu diperhatikan dalam melakukan joining tabel secara lebih efektif, antara lain: •
Menggunakan equijoin akan menghasilkan query yang lebih efisien. Jadi, usahakan untuk menggunakan equijoin apabila memungkinkan.
•
Melakukan operasi-operasi filtering lebih awal akan mengurangi jumlah baris untuk dilakukan join pada langkah selanjutnya. Gunakan tabel yang memiliki filter yang paling selektif sebagai driving table karena dengan demikian, jumlah baris yang diteruskan ke langkah berikutnya akan lebih sedikit.
•
Lakukan join dengan urutan tabel dari yang menghasilkan baris paling sedikit bagi langkah parent-nya.
2. Menggunakan perintah CASE Dalam melakukan kalkulasi beberapa agregat dari tabel yang sama, hindari menulis query yang terpisah untuk masing-masing agregat. Dengan query yang terpisah, Oracle harus membaca tabel secara keseluruhan untuk setiap query. Akan lebih efisien apabila Anda menggunakan perintah CASE karena perintah ini memungkinkan Anda untuk mengkomputasi beberapa agregat dari tabel yang bersangkutan dengan hanya sekali pembacaan pada tabel. 3. Meminimalisasi pengaksesan tabel Salah satu moto utama dalam penulisan query adalah “batasi jumlah pengaksesan data sesedikit mungkin”. Jadi, hindari SQL yang berulang kali mengakses suatu tabel untuk kolom yang berbeda-beda.
2.10 Explain Plan Menurut Bryla-Loney (2008, p250),explain plan adalah sebuah perintah yang akan mengevaluasi execution path untuk sebuah query dan akan menempatkan hasil evaluasinya ke dalam sebuah table di dalam database yang bernama PLAN_TABLE. Sedangkan menurut Alapati (2009, p1090),explain plan adalah sebuah tool yang membantu kita dalam melakukan SQL tuning denganmenyediakan execution plan dari sebuah SQL statement.
Menurut Smith (2010, p4), dalam white paper yang berjudul A Toad for Oracle, setiap langkah plan memiliki hal-hal berikut: 1. Nomor langkah plan 2. Metode akses yang digunakan Setiap execution plan step yang berbeda-beda merepresentasikan metode pengaksesan data yang juga berbeda-beda. Metode pengaksesan data yang ada tidak dapat secara langsung dikatakan baik atau buruk. Jika terdapat sebuah index, maka penggunaan index akan mempercepat pengaksesan data daripada melakukan full table scan. Meskipun demikian, jika memang tujuan sebuah query adalah melakukan pembacaan semua data dari sebuah tabel, maka penggunaan index menjadi kurang efisien. 3. Cost Cost merupakan sebuah ukuranrelatif yang akan dihasilkanoleh Oracle untuk merepresentasikan jumlah work yang diperlukan untuk menjalankan sebuah langkah spesifik. Jumlah cost dari semua langkah yang ada merepresentasikan cost yang dibutuhkan untuk mengeksekusi sebuah statement secara keseluruhan. Pada umumnya, sebuah plan dengan cost yang lebih rendah merepresentasikan suatu kinerja yang lebih baik daripada sebuah plan dengan cost yang lebih tinggi. Meskipun demikian, sering juga ditemukan bahwa plan yang memiliki cost yang tinggi memiliki kinerja yanglebih baik daripada plan dengan cost yang rendah. Menurut Alapati (2009, p1093), hal-hal yang perlu diingat dalam membaca explain plan, yaitu sebagai berikut: •
Setiap langkah dalam plan mengembalikan hasil dalam bentuk sekumpulan baris kepada langkah parent.
•
Bacalah plan dari dalam ke luar, dimulai dari baris yang memiliki indentasi paling dalam.
•
Apabila dua operasi berada pada level yang sama dalam hal indentasi, baca yang paling atas terlebih dahulu.
3. ANALISIS DAN PERANCANGAN 3.1 Masalah-masalah yang ditemukan berdasarkan hasil analisis Berdasarkan hasil wawancara dan observasi yang dilakukan, permasalahan yang dihadapi oleh ACC sehubungan dengan penggunaan aplikasi CRS adalah bahwa aplikasi CRS membutuhkan waktu yang relatif lama dalam merespon permintaan user. Dari
wawancara dan observasi, ditemukan pula bahwa tidak semua halaman dalam aplikasi CRS memiliki waktu respon yang relatif lama, melainkan hanya beberapa halaman saja, yaitu halaman utama dan halaman-halaman yang berkaitan dengan produk ACP (ACC Credit Protection) dan Fastrack Financing. Menurut pihak ACC, lamanya waktu respon dari aplikasi CRS ini memberikan efek negatif terhadap kinerja dan citra ACC. Bagi pihak telemarketing dan teleserviceyang mewakili ACC untuk berinteraksi langsung dengan customer, kecepatan aplikasi CRS dalam menampilkan informasi yang diperlukan selama proses interaksi sangatlah penting. Penundaan satu atau dua detik saja dapat mempengaruhi penilaian dan kepuasan pelanggan terhadap pelayanan dari ACC. Dari analisis yang dilakukan, penulis menemukan bahwa faktor-faktor yang menyebabkan lambatnya kinerja aplikasi CRS adalah sebagai berikut: a.
Penulisan aplikasi yang tidak efektif dan kurang reusable. Hal itu terlihat dari penulisan query yang sama secara berulang-ulang dalam satu halaman dan belum terlihat adanya penggunaan prosedur. Selain itu, query yang sama ditulis berulang kali tetapi dengan cara penulisan yang berbeda-beda, misalnya ada yang ditulis dengan huruf kapital semua, ada yang dengan huruf kecil semua, atau ada yang campuran huruf besar dan huruf kecil. Penulisan yang berbeda-beda seperti itu menyebabkan terjadi hard parsing berkali-kali untuk query yang sama.
b. Query yang digunakan masih belum optimal. Dengan jumlah data yang sangat besar, dibutuhkan query yang lebih efisien sehingga bisa lebih cepat dalam memproses dan menampilkan data. c. Penggunaan index yang belum efektif. Masih ada beberapa tabel yang diakses secara full table scan dikarenakan belum ada index yang dibuat pada tabel tersebut atau pada tabel yang bersangkutan tidak ada index yang sesuai untuk digunakan dalam memproses query. Selain itu, pada beberapa tabel, index yang ada kebanyakan masih berupa single-columnindex, sementara pada sebagian besar query yang ada, pengaksesan tabel cenderung dilakukan dengan predikat yang melakukan filter dari beberapa kolom. d. Ukuran tabel yang terlalu besar, terutama tabel TBL_BUCKET_TOCALL dan TBL_HISTORY_TMCALL. Ukuran tabel yang sangat besar akan memperlambat kinerja query, apalagi jika query hanya mengambil sebagian kecil dari data yang ada di dalam tabel.
3.2 Perancangan Alternatif solusi bagi pemecahan masalah Berdasarkan analisis yang dilakukan, penulis mengusulkan beberapa alternatif untuk melakukan perbaikan pada aplikasi CRS, sebagai berikut: 1. MembuatPL/SQL functionuntuk menggantikan query yang ditulis berulang kali di dalam aplikasi CRS. 2. Melakukan restrukturisasi SQL untuk meningkatkan kinerja dari query-query yang digunakan. 3. Membuat indexpada kolom predikat yang belum dibuatkan index dan membuat concatenated index untuk kolom-kolom dari sebuah tabel yang sering digunakan bersama sebagai predikat dalam query. 4. Melakukan partitioning pada tabel-tabel yang berukuran besar.
4. IMPLEMENTASI DAN EVALUASI SQL tuning dilakukan pada page-page halaman yang lambat dari aplikasi customer response system. Berikut adalah hasil implementasi dan evaluasi secara keseluruhan : Sebelum SQL Baris Restrukturisasi Tuning SQL (S) (msecs) frame_left.ASP 166 2755.000 199 369.667 109.333 207 103.667 41.333 274 7078.000 301.333 351 1052.000 114.667 528 5739.667 2078.333 ‐ 689 57.667 786 1849.667 979.000 922 5240.000 1015 1307.667 1460 161.000 ‐ 1629 214.000 1749 5047.000 1725 94.000 bucketACP.ASP 2760.667 171.667 229 frmResCallACP.ASP 47.000 731 62.667 789 234.000 1136 bucket_Top_UP_EF.ASP 208 6417.333 1443.000 detCustEF.ASP 68.000 168 78.333 230 26666.667 565 67.333 958 68.000 1131 bucket_Top_UP_EF_Query.ASP 201 1786.667 161.667
Setelah SQL Tuning (msec) Indexing (I)
1729.333 88.667 406.000 31.333 2333.333 292.000 234.667 67.333 151.333 370.000 -
Partitioning (P)
401.000 91.667 390.667 781.333 229.000 141.000 130.333 1760.667 47.000
S+I
78.000 120.000 224.333 -
S+P
62.333 130.333 510.667 -
I+P
109.333 42.000 119.667 765.333 146.000 67.333 47.000 67.667 -
S+I+P
31.667 86.667 130.000 -
-
-
-
-
-
57.000
41.667 57.333 -
-
-
-
-
2078.333
1531.333
83.333 -
62.333 68.000 8755.667 57.333 62.333
-
219.000
-
-
401.000
234.333 99.333
Gambar 4.1 Matriks keseluruhan hasil sql tuning
176.667 67.667 -
161.000 -
Gambar 4.2 Grafik hasil SQL Tuning page Frame_left.asp
Gambar 4.3 Grafik hasil SQL tuning page BucketACP.asp
Gambar 4.4 Grafik hasil SQL tuning page frmResCallACP.asp
Gambar 4.5 Grafik hasil SQL tuning page Bucket_top_up_ef.asp
Gambar 4.6 Grafik hasil SQL tuning page detCustEF.asp
Gambar 4.7 Grafik hasil SQL tuning page Bucket_top_up_ef_query.asp
5. SIMPULAN DAN SARAN 5.1 Simpulan Setelah melakukan analisis terhadap aplikasi Customer Response System pada Astra Credit Companies dan melakukan evaluasi pengaruh beberapa metode SQL tuning terhadap aplikasi CRS, maka dapat disimpulkan bahwa: 1. Masalah performance yang terjadi pada aplikasi CRS disebabkan oleh beberapa faktor, yaitu terdapat redundansi query,penulisan query yang belum optimal, penggunaan index yang belum efektif, dan ukuran tabel yang terlalu besar. 2. Setelah dilakukan SQL tuning, performance aplikasi CRS menjadi lebih baik, yang ditunjukkan oleh response time yang lebih cepat. Metode-metode SQL tuning yang digunakan sehingga performance aplikasi menjadi lebih cepat, yaitu menggantikan query yang redundan dengan function, melakukan restrukturisasi perintah SQL yang belum optimal, melakukan indexing pada kolom-kolom yang sering diakses pada sebuah tabel, dan melakukan partitioning terhadap tabel-tabel yang besar.
5.2 Saran Berdasarkan hasil analisis dan simpulan yang diperoleh, maka berikut ini adalah saran-saran yang dapat diberikan kepada perusahaan untuk pengembangan lebih lanjut dari aplikasi Customer Response System: 1. Melakukan tuning dengan metode-metode lain, seperti instance tuning, tuning terhadap jaringan, dan melakukan normalisasi terhadap struktur database,sehingga kinerja dari aplikasi CRS dapat lebih dioptimalkan. 2. Melakukan monitoring secara berkala terhadap distribusi data dalam tabel partisi dan melakukan restrukturisasi terhadap partisi dalam tabel apabila diperlukan. 3. Melakukan archiving terhadap database agar jumlah data tidak terlalu banyak sehingga performance dapat lebih ditingkatkan.
DAFTAR PUSTAKA Anonim1. (2011). Oracle Database VLDB and Partitioning Guide, 11g Release 2. Oracle Corporation, USA. Anonim 2. (2011). http://www.httpwatch.com/features.htm Alapati, R.S. (2009). Expert Oracle Database 11g Administration. Apress, New York. Bryla, B.,& Loney, K. (2008). Oracle Database 11g DBA Handbook. McGraw-Hill, USA. Chan, I. (2008). Oracle Database Performance Tuning Guide, 10g Release 2. Oracle USA, Inc, USA. Connolly, T.,& Begg, C. (2010). Database Systems: A Practical Approach to Design, Implementation,and Management. 5th Edition. Addison-Wesley, USA. Day, R. (2007). Oracle Database Heterogeneous Connectivity Administrator’s Guide, 11g Release 1 (11.1). Oracle USA, Inc, USA. Fauzi, R. (2011). Panduan Praktis Membuat Diagram UML dengan Microsoft Visio 2010. Microsoft User Group Indonesia, Jakarta. Feuerstein, S.,& Pribyl, B. (2009). Oracle PL/SQL Programming. Fifth Edition. O'Reilly, USA. Indrajani. (2009). Sistem Basis Data dalam Paket Five In One. PT Elex Media Komputindo, Jakarta. John, W.,& Roopeh, R.,& Bob, B. (2010). OCA/OCP Oracle Database 11g All-in-One EXAM Guide (Exams 1Z0-051, 1Z0-052, and 1Z0-053). McGraw-Hill, USA. Macdonald, M. (2010). Beginning ASP.NET 4 in C# 2010. Springer Science & Business Media, LLC, New York. Moore, S. (2009). PL/SQL Language Reference, 11g Release 1. Oracle Corporation, USA. Niemec, R. (2007). Oracle Database 10g Performance Tuning. McGraw-Hill, USA. Oxford University Press. (2012).Oxford Dictionaries The World’s Most Trusted Dictionaries. Diperoleh 11-16-2011 darihttp://oxforddictionaries.com/
Pearson Education Limited. (2011). Longman Dictionary of Contemporary English. Diperoleh 11-16-2011 dari http://www.ldoceonline.com/ Rainer, K. R., & Cegielski, C. G. (2011). Introduction to Information Technology: Enabling and Transforming Business. 3rd Edition. John Wiley and Sons, Asia. Sebesta, R. W. (2010). Concepts of Programming Languages. 9th Edition. Pearson Education, New Jersey. Smith, J. (2010). A Toad for Oracle White Paper. Quest Software, Inc. Whitten, J. L.,& Bentley, D. L. (2007). Systems Analysis and Design Methods. 7th Edition. McGraw-Hill, Singapore. Williams, B. K.,& Sawyer, Stacey, C. (2011). Using Information Technology: A Practical Introduction to Computers & Communications. 9th Edition. McGraw-Hill, New York.
RIWAYAT HIDUP PICTURE
PERSONAL INFORMATION Binusian ID
1200991492
Full Name
ANDY
E-mail Address
[email protected] Current Perumahan Palem Mutiara, Block C17-3. Cengkareng, Jak-Bar Jakarta 11730 DKI Jakarta , Indonesia Permanent Jalan Dokter Wahidin, Gang Sepakat 1, B2 Pontianak 78115 Kalimantan Barat , Indonesia
Phone Numbers Gender Birth Place / Date Nationality
Home : 62 - 21 - 54358073 Mobile : 62 - 878 - 78595973 Male PONTIANAK / 04 Jan 1990 Ind
onesia Marital Status Sing le Religion Bud dha FORMAL EDUCATION Mar 2008 - present
Bina Nusantara University , Jakarta , Indonesia Bachelor (S1) , Computer Science GPA: 3.88
Jul 2005 - Jun 2008
SMAK Santo Petrus , Pontianak , Indonesia Senior High , Not applicable GPA: 52
Jul 2002 - Jun 2005
SMPK Santo Petrus , Pontianak , Indonesia Junior High , Not applicable GPA: 28
INFORMAL EDUCATION Dec 2010 - Dec 2010 Indonesia
DB2 9.7 Bootcamp and Oracle to DB2 9.7 Migration C , Jakarta , IBM Workshop
Jul 2010 - Aug 2010
Bina Nusantara Laboratory Teaching Assistant Train , Jakarta , Indonesia Laboratory Teaching Assistant
Jul 2010 - Aug 2010
English for Teaching Purposes (ETP) , Jakarta , Indonesia English for Teaching Purposes
Oct 2007 - Jan 2008
Intensive IELTS preparation course , Pontianak , Indonesia IELTS preparation course
Feb 2004 - Oct 2007
SMART General English Course at SMART , Pontianak , Indonesia General English Course
WORKING EXPERIENCE Sep 2011 - Dec 2011
POSITION-COMPANY NAME Astra Credit Companies , Jakarta , Indonesia Internships JOB DESCRIPTION -Developing a documentation of currently active database structure in the form of Entity Relationship Diagram -Doing performance tuning on Customer Response System web-based application using Oracle 9i Database. -Giving monthly progress report to IT Division and Database Administrator.
PICTURE
PERSONAL INFORMATION Binusian ID
1200991536
Full Name
ELLEN SUWANDI
E-mail Address
[email protected] Current JL. KEBON JERUK RAYA NO. 9 JAKARTA 11530 DKI Jakarta , Indonesia Permanent JL. H.O.S COKROAMINOTO GG. BUNTU 008 PONTIANAK 78111 Kalimantan Barat , Indonesia
Phone Numbers Gender Birth Place / Date Nationality ia Marital Status Religion
Home : 62 - 561 - 731737 Mobile : 62 - 817 - 0004550 Female PONTIANAK / 02 Oct 1990 Indones Single Buddha
FORMAL EDUCATION Sep 2008 - present
Bina Nusantara University , Jakarta , Indonesia Bachelor (S1) , Computer Science GPA: 4.00
Jul 2005 - Jun 2008
SMAK SANTO PETRUS , PONTIANAK , Indonesia Senior High , Not applicable GPA: 56.1
Jul 2002 - Jun 2005
SMPK SANTO PETRUS , PONTIANAK , Indonesia Junior High , Not applicable GPA: 29.5
INFORMAL EDUCATION Jun 2003 - Jun 2007
UNIVERSAL ENGLISH COURSE , PONTIANAK , Indonesia ENGLISH LANGUAGE
Mar 1995 - Jun 2003
Central English Course , PONTIANAK , Indonesia ENGLISH LANGUAGE
Jun 2007 - Jun 2008
General English Course at SMART , PONTIANAK , Indonesia ENGLISH LANGUAGE
Jul 2010 - Jul 2010
Bina Nusantara Student Mentoring Training , JAKARTA , Indonesia Mentoring Training
Feb 2011 - Feb 2011
Bina Nusantara Student Mentoring Training , JAKARTA , Indonesia Mentoring Training
WORKING EXPERIENCE Apr 2011 - Jun 2011
POSITION-COMPANY NAME PT Mulia Knitting Factory, Ltd. , JAKARTA , Indonesia Internships JOB DESCRIPTION - Developing a desktop application for Export Garment Information System. - Giving daily progress report to the Research and Development Manager. - Providing any IT related supports.
Sep 2011 - Dec 2011
POSITION-COMPANY NAME Astra Credit Companies , JAKARTA , Indonesia Internships JOB DESCRIPTION - Developing a documentation of currently active database structure in the form of Entity Relationship Diagram. - Doing performance tuning on Customer Response System web-based application, using Oracle 9i Database. - Giving monthly progress report to IT Division and Database Administrator.
ORGANIZATION EXPERIENCE Mar 2010 - Mar 2011 Learning
Bina Nusantara Centre
Student Mentoring
To teach and assist Bina Nusantara students (mentee)
PICTURE
PERSONAL INFORMATION Binusian ID
1200991662
Full Name
HANDY WIJAYA
E-mail Address
[email protected] Current Jl.K.H.Syahdan Gang keluarga, kos 39Z lantai 2 nomor 9 Jakarta 11480 DKI Jakarta , Indonesia Permanent Jl.Perdana, komplek bali agung 2, nomor C.17 PONTIANAK 78121 Kalimantan Barat , Indonesia
Phone Number
Mobile : 62 - 852 - 45791116
Gender
Male
Birth Place / Date Nationality Marital Status Religion
PONTIANAK / 14 Oct 1990 Indonesia Single Catholic
Home : 62 - 561 - 580919
FORMAL EDUCATION Sep 2008 - present
Bina Nusantara University , Jakarta , Indonesia GPA: 3.84 Bachelor (S1) , Computer Science
Jul 2005 - Jun 2008 SMAK SANTO PETRUS , PONTIANAK , Indonesia Senior High , Not applicable GPA: N/A Jul 2002 - Jun 2005 SMPK SANTO PETRUS , PONTIANAK , Indonesia Junior High , Not applicable GPA: N/A
INFORMAL EDUCATION Jun 2002 - Jun 2005 GAJAHMADA ENGLISH COURSE , PONTIANAK ENGLISH
, Indonesia
Feb 2011 - Feb 2011 Bina Nusantara Student Mentoring Training , PONTIANAK , Indonesia Mentoring Training
ORGANIZATION EXPERIENCE Feb 2011 - Jun 2011 Learning
Bina Nusantara Centre
Stude nt Mento ring
To teach and assist Bina Nusantara students (mentee).
31 WORKING EXPERIENCE Sep 2011 - Dec 2011 POSITION-COMPANY NAME Astra Credit Companies , JAKARTA , Indonesia Engineering-Software JOB DESCRIPTION Developing a documentation of currently active database structure in the form of Entity Relationship Diagram, Doing performance tuning on Customer Response System web-based application, using oracle 9i Database, and giving monthly progress report to IT Division and Database Administrator. Apr 2011 - Jun 2011 POSITION-COMPANY NAME PT Mulia Knitting Factory, Ltd. , JAKARTA , Indonesia Engineering-Software
