64 BAB 3
ANALISIS DAN PERANCANGAN EVALUASI DAN PENINGKATAN KINERJA SISTEM BASIS DATA SIDJP CORE
3.1 Organisasi Direktorat Jenderal Pajak
3.1.1 Gambaran Umum Direktorat Jendral Pajak
Direktorat Jenderal Pajak adalah sebuah Direktorat Jenderal di bawah naungan Kementerian Keuangan Republik Indonesia yang mempunyai tugas merumuskan serta melaksanakan kebijakan dan standardisasi teknis di bidang perpajakan.
Dalam melaksanakan tugasnya, Direktorat Jenderal Pajak menyelenggarakan fungsi:
• Penyiapan perumusan kebijakan Departemen Keuangan di bidang perpajakan.
• Pelaksanaan kebijakan di bidang perpajakan.
• Perumusan standar, norma, pedoman, kriteria, dan prosedur di bidang perpajakan.
• Pemberian bimbingan teknis dan evaluasi di bidang perpajakan. • Pelaksanaan administrasi Direktorat Jenderal Pajak.
Secara khusus, bagian basis data SIDJP Core di Direktorat Jenderal Pajak melibatkan sekitar (secara kasar) 30 ribu data karyawan, 20 ribu pengguna sistem dan kuota jumlah transaksi mencapai 100 GB per hari.
3.1.2 Visi dan Misi Direktorat Jenderal Pajak Visi Direktorat Jenderal Pajak adalah :
Menjadi Institusi pemerintah yang menyelenggarakan sistem administrasi perpajakan modern yang efektif, efisien, dan dipercaya masyarakat dengan integritas dan profesionalisme yang tinggi.
Misi Direktorat Jenderal Pajak adalah :
Menghimpun penerimaan pajak negara berdasarkan Undang-undang Perpajakan yang mampu mewujudkan kemandirian pembiayaan Anggaran Pendapatan dan Belanja Negara melalui sistem administrasi perpajakan yang efektif dan efisien.
3.1.3 Struktur Organisasi
Struktur organisasi Direktorat Jenderal Pajak pada divisi Teknologi Informasi Perpajakan yang dikepalai oleh seorang Direktur Teknologi Informasi Perpajakan dengan ikhtisar jabatan adalah mengarahkan perumusan kebijakan, standardisasi dan bimbingan teknis, evaluasi dan pelaksanaan di bidang pemantauan sistem dan infrastruktur, pemberian dukungan dan layanan operasional serta pembinaan pengolahan data dan pengelolaan dokumen.dan terdiri dari 3 buah Subdirektorat yaitu :
- Subdirektorat Pelayanan Operasional. - Subdirektorat Pendukungan Operasional.
Gambar 3. 1 Struktur Organisasi Direktorat Jenderal Pajak
Secara khusus, Direktur Teknologi Informasi Perpajakan mengepalai 3 subdirektorat, yaitu Subdirektorat Pelayanan Operasional, Subdirektorat Pendukung Operasional dan Subdirektorat Pemantauan Sistem dan Infrastruktur. Berikut adalah gambar 3.2 yang merupakan struktur organisasi dari Direktur Teknologi Informasi Perpajakan.
Gambar 3. 2 Struktur Organisasi Direktur Teknologi Informasi Perpajakan
Masing-masing kepala subdirektorat memiliki ikhtisar jabatan dan secara khusus mengenai bagian Pemantauan Basis Data ada pada Subdirektorat Pemantauan Sistem dan Infrastruktur. Ikhtisar jabatan masing-masing subdirektorat adalah sebagai berikut :
1. Kepala Subdirektorat Pelayanan Operasional
Ikhtisar jabatannya adalah mengarahkan perumusan kebijakan, standardisasi dan bimbingan teknis, evaluasi dan pelaksanaan di bidang pemantauan sistem dan infrastruktur, pemberian dukungan dan layanan operasional serta pembinaan pengolahan data dan pengelolaan dokumen.
2. Kepala Subdirektorat Pendukung Operasional
Ikhtisar jabatannya adalah menjamin terlaksananya kegiatan penyiapan, penelaahan dan penyusunan kebijakan teknis operasional, dan pemantauan, pengendalian dan evaluasi pelaksanaan kebijakan teknis operasional, serta
pelaksanaan bimbingan sistem, pemutakhiran data tampilan, pertukaran data elektronik, pengelolaan intranet dan internet serta administrasi pekerjaan, kegiatan dan pelaksanaan tugas.
Bagian Kepala Subdirektorat Pendukung Operasional terdiri dari : 3. Kepala Subdirektorat Pemantauan Sistem dan Infrastruktur
Ikhtisar jabatannya adalah menjamin terlaksananya kegiatan penyiapan, penelaahan, dan penyusunan kebijakan, serta pemantauan, pengendalian, dan evaluasi pelaksanaan kebijakan teknis operasional, serta pelaksanaan pemantauan terhadap konfigurasi dan kapasitas infrastruktur teknologi informasi, keamanan sistem dan jaringan komunikasi data, basisdata, pengolahan data dan dokumen, pemeliharaan Master File Wajib Pajak, serta administrasi program aplikasi.
Bagian Kepala Subdirektorat Pemantauan Sistem dan Infrastruktur terdiri dari :
b. Kepala Seksi Pemantauan Konfigurasi dan Kapasitas
Ikhtisar jabatannya adalah melaksanakan kegiatan penyiapan bahan, penelaahan dan penyusunan, serta pemantauan, pengendalian dan evaluasi kebijakan teknik operasional, serta pelaksanaan pemantauan dan pemeliharaan konfigurasi dan kapasitas infrastruktur teknologi informasi, serta administrasi program aplikasi.
c. Kepala Seksi Pemantauan Keamanan Sistem dan Jaringan Komunikasi Data
Ikhtisar jabatannya adalah melaksanakan kegiatan penyiapan bahan, penelaahan dan penyusunan, serta pemantauan, pengendalian dan
evaluasi kebijakan teknik operasional, serta pelaksanaan pemantauan dan pemeliharaan keamanan sistem dan jaringan komunikasi data, serta administrasi program aplikasi.
d. Kepala Seksi Pemantauan Basisdata
Ikhtisar jabatannya adalah melaksanakan kegiatan penyiapan bahan, penelaahan dan penyusunan, serta pemantauan, pengendalian dan evaluasi teknik operasional, serta pelaksanaan pemantauan distribusi dan konsolidasi data serta operasional basisdata nasional, serta administrasi program aplikasi.
e. Kepala Seksi Pemantauan Pengolahan Data dan Dokumen
Ikhtisar jabatannya adalah melaksanakan kegiatan penyiapan bahan, penelaahan dan penyusunan, serta pemantauan, pengendalian dan evaluasi kebijakan teknik operasional, serta pelaksanaan pembinaan di bidang transformasi data dan pengelolaan dokumen dalam hal perekaman, kualitas dan transfer data, penyimpanan, peminjaman dan penghapusan dokumen dan media elektronik, pemeliharaan Master File Wajib Pajak serta administrasi program aplikasi.
3.2 Sistem yang Berjalan
SIDJP Core merupakan basis data dalam Direktorat Jenderal Pajak yang menangani beberapa bagian alur proses, diantaranya adalah :
• Modul pengaturan mutasi pegawai, dari kantor cabang satu ke kantor cabang lainnya.
• Modul pengaturan data pembayaran yang sudah diakui sebagai pembayaran yang sudah divalidasi kebenarannya.
• Modul pengaturan data yang berupa kasus pembayaran yang bermasalah, misalnya jumlah pajak yang dibayarkan wajib pajak tidak sesuai dengan jumlah tagihan yang seharusnya.
• Modul pengaturan laporan data SPT beserta sinkronisasi data SPT offline.
• Modul pengaturan data referensi wajib pajak sebagai tabel master, misalnya mencakup wilayah wajib pajak, alamat, kelurahan, daerah, dan sebagainya. 3.1.4 Analisis Proses Bisnis
Berikut ini merupakan penjelasan dan detail mengenai modul-modul yang ditangani oleh basis data SIDJP Core :
• Modul pengaturan mutasi pegawai, dari kantor cabang satu ke kantor cabang lainnya
Dalam hal ini, data wajib pajak yang ditangani oleh HR (Account Representative) akan ditangani oleh HR yang lain sewaktu HR tersebut dimutasikan dari cabang asal. Sebagai ilustrasi, seorang pegawai dimutasi dengan surat SK ke Kantor Pajak tujuan. Awalnya pegawai A menangani data Wajib Pajak di Kantor Pelayanan Pajak asalnya, jika ia dipindahkan, maka pegawai A akan menangani data Wajib Pajak di Kantor Pelayanan Pajak tujuan. Sehingga basis data SIDJP Core melakukan sinkronisasi penanganan data Wajib Pajak oleh pegawai yang dimutasi.
• Modul pengaturan data pembayaran yang sudah diakui sebagai pembayaran yang sudah divalidasi kebenarannya
Berikut ini merupakan gambaran umum dari modul pengaturan data pembayaran yang sudah diakui sebagai pembayaran yang sudah divalidasi kebenarannya :
1. Wajib Pajak membayarkan pajaknya ke bank setempat. 2. Bank akan melakukan pengecekan data Wajib Pajak tersebut.
3. Setelah proses pembayaran selesai dilakukan, maka data pembayaran tersebut dimasukkan ke dalam basis data bank yang bersangkutan.
4. Pada waktu tertentu, dilakukan sinkronisasi antara data yang ada pada bank tersebut dengan data yang ada pada basis data SIDJP Core.
• Modul Pengaturan laporan data SPT beserta sinkronisasi data SPT offline
Berikut ini merupakan rincian dari masing-masing sinkronisasi yang dilakukan antara laporan data SPT dari Wajib Pajak secara offline dan terpusat :
- Offline
1. Wajib pajak melapor SPT ke Kantor Pelayanan Pajak setempat.
2. Kantor Pelayanan Pajak setempat tersebut melakukan input ke aplikasi yang bersangkutan di Kantor Pelayanan Pajak tersebut.
3. Aplikasi akan menyimpan data SPT pada basis data di Kantor Pelayanan Pajak setempat.
4. Aplikasi mencetak tanda terima untuk diserahkan ke Wajib Pajak
5. Saat server online, akan dilakukan sinkronisasi data ke Basis Data SIDJP Core.
- Terpusat
1. Wajib pajak melapor SPT ke Kantor Pelayanan Pajak setempat.
2. Kantor Pelayanan Pajak setempat tersebut melakukan input ke aplikasi yang bersangkutan dari server.
3. Aplikasi input data tersebut ke basis data SIDJP Core.
4. Basis data SIDJP Core mengolah dan membuat tanda terima bagi Wajib Pajak.
5. Aplikasi mencetak tanda terima tersebut untuk diserahkan ke Wajib Pajak 6. Setiap waktu tertentu (dalam hitungan menit), terdapat batch job untuk
memasukkan detail SPT ke dalam basis data SIDJP Core.
• Modul pengaturan data yang berupa kasus pembayaran yang bermasalah, misalnya jumlah pajak yang dibayarkan wajib pajak tidak sesuai dengan jumlah tagihan yang seharusnya
Ada beberapa penanangan yang dilakukan ketika ada kasus pembayaran yang bermasalah, yaitu :
1. Jika seorang Wajib Pajak kurang membayar pajak SPT, maka hal yang harus dilakukannya adalah melunasi pajak SPT. Dalam hal ini basis data SIDJP Core melakukan sinkronisasi SPT yang disertakan pembayaran yang wajib dilunasi oleh Wajib Pajak yang bersangkutan.
2. Jika seorang Wajib Pajak memiliki kelebihan pembayaran dari pajak SPT-nya, maka akan dilakukan validasi mengenai kebenaran hal tersebut. Jika hasilnya adalah benar, maka permohonan Wajib Pajak akan dilanjutkan ke KPPN untuk pencairan dana ke Wajib Pajak yang bersangkutan. Dalam hal ini, SIDJP Core melakukan sinkronisasi data pembayaran dengan tagihan kemudian data permohonan kelebihan pembayaran dan data hasil keputusan kelebihan pembayaran disimpan di dalam basis data SIDJP Core.
• Modul Pengaturan data referensi wajib pajak sebagai tabel master, misalnya mencakup wilayah wajib pajak, alamat, kelurahan, daerah, dan sebagainya
1. Calon Wajib Pajak melakukan registrasi sebagai Wajib Pajak melalui website Direktorat Jenderal Pajak.
2. Dari website tersebut, data hasil registrasi dimasukkan ke dalam sebuah basis data untuk divalidasi kebenarannya.
3. Dari basis data tersebut akan dilakukan sinkronisasi dengan basis data SIDJP Core.
3.1.5 Analisis Tabel berjalan
Pada penilaian performance di Enterprise Manager Oracle untuk basis data SIDJP Core, terdapat top SQL yang membuat Active Sessions tinggi pada waktu tertentu. Top SQL tersebut berkaitan dengan beberapa tabel yang digunakan pada basis data tersebut. Berikut ini adalah Entity Relationship Diagram (ERD) dari beberapa tabel-tabel yang ada pada basis data SIDJP Core terkait dengan top SQL yang akan dioptimasi :
Gambar 3. 3 Entity Relationship Diagram (ERD) beberapa tabel SIDJP Core *) Keterangan : Deskripsi tabel dan keterangan tabel ada pada Lampiran Tabel.
3.3 Analisis Permasalahan
Melalui wawancara yang dilakukan dengan Kepala Seksi Pengembangan Aplikasi Perpajakan, belum dilakukan tuning apapun pada basis data SIDJP Core ini. Kebutuhan akan tuning tersebut masih dapat diusahakan tanpa penambahan perangkat keras untuk basis data ini. Melalui analisis yang dilakukan pada chart performance pada basis data SIDJP Core (terlampir pada Lampiran L39), dapat dilihat tingkat average active sessions yang tinggi dengan yang dikategorikan melalui sumber daya yang digunakan pada setiap sesi yang aktif. Dari gambar tersebut, terdapat 2 kategori yang paling menghabiskan sumber daya, yaitu CPU dan User I/O. User I/O merupakan kategori yang paling dominan penggunaannya dari chart tersebut. Penggunaan I/O dan CPU pada dasarnya sangat berkaitan dengan pengelolaan query yang dijalankan pada basis data SIDJP Core.
Setelah dianalisis lebih lanjut pada sistem yang berjalan di Kantor Pusat Direktorat Jenderal Pajak, terdapat permasalahan top SQL pada basis data SIDJP Core. Berikut ini adalah analisis permasalahan yang ada pada Top SQL tersebut :
- Ketidaktepatan penggunaan JOIN pada perintah SQL yang menyebabkan Optimizer kurang optimal dalam menentukan proses JOIN dan index yang optimal untuk query yang dijalankan.
- Penggunaan JOIN tabel yang tidak diperlukan.
- Penggunaan fungsi pada kolom yang terletak di klausa where. Dalam hal ini, fungsi pada kolom dapat dihilangkan dengan penggantian fungsi dalam perintah SQL. Selain itu, tidak adanya function-based-index pada fungsi perintah SQL membuat waktu untuk pencarian data menjadi lebih lama. Ada beberapa cara
untuk menghilangkan fungsi pada kolom sehingga penggunaan fungsi di dalam perintah SQL dapat diganti dengan cara yang berbeda namun lebih cepat
- Penggunaan antara IN dan EXISTS yang tidak tepat pada query tertentu.
- Ada beberapa indeks yang tidak dieksekusi saat Optimizer melakukan eksekusi perintah SQL akibat kurang tepatnya index, penggunaan is null, dan penggunaan inequality.
- Tidak adanya indexing sehingga proses query kurang optimal. Misalnya tidak ada penggunaan partitioned-index yang digunakan pada tabel yang sudah dipartisi.
- Banyak terdapat query yang dibuat dengan hardcode dimana seharusnya menggunakan bind variable agar oracle lebih cepat untuk mengeksekusi query tersebut
3.4 Usulan Solusi Pemecahan Masalah
SQL Tuning merupakan salah satu teknik tuning paling awal dan merupakan sebuah proses tuning yang dapat meningkatkan kinerja database dengan signifikan. Dengan observasi dan wawancara tersebut, maka disimpulkan bahwa SQL Tuning merupakan jawaban dari teknik tuning yang sesuai pada basis data SIDJP Core.
SQL Tuning mencakup perubahan struktur (restrukturisasi query) dan melakukan analisis penggunaan indeks yang ada. Dalam menentukan restrukturisasi query dan analisis indeks, diperlukan hal-hal yang dapat diukur dan petunjuk untuk memilik teknik terbaik. Oleh karena itu,pada masing-masing query akan dianalisis 3 hal yaitu : eksekusi pemrosesan query, cost dan waktu eksekusi tersebut. Melalui analisis eksekusi
pemrosesan query awal, maka dapat dicari solusi untuk mengurangi cost dan waktu eksekusi yang dibutuhkan query tersebut.
Melalui analisis permasalahan query yang ada pada perintah SQL di atas, ada beberapa solusi pemecahan masalah yang telah ditemukan. Solusi tersebut berupa upaya optimasi jalannya query dengan melakukan penggantian perintah SQL dan penambahan index sesuai dengan kebutuhan query yang tidak optimal tersebut. Berikut ini adalah usulan solusi pemecahan masalah berdasarkan analisis masalah yang telah disebutkan :
- Penggunaan JOIN pada perintah SQL yang kurang tepat, dapat diganti dengan struktur JOIN yang dapat menghasilkan eksekusi query yang lebih cepat dari sebelumnya. Ada beberapa cara penggantian struktur JOIN yang disesuaikan dengan query, yaitu dengan alias Subquery atau penggunaan IN – EXISTS yang disesuaikan dengan kondisi query yang penggunaan JOIN-nya hanya dilakukan untuk pemeriksaan kondisi. Ketiga bentuk penggunaan JOIN ini akan menghasilkan proses eksekusi yang berbeda, sehingga perlu disesuaikan dengan kondisi query untuk ditentukan proses eksekusi yang paling baik.
- Penggunaan JOIN pada tabel yang tidak diperlukan dapat dioptimalkan dengan menghilangkan JOIN terhadap tabel tersebut sehingga optimizer tidak akan melakukan proses JOIN yang seharusnya dapat dihilangkan.
- Penggunaan fungsi SQL pada kondisi di klausa WHERE, usahakan untuk menggunakan kolom yang belum ditransformasikan. Proses transformasi kolom memerlukan waktu yang lebih lama dibandingkan dengan tanpa proses transformasi pada kolom. Selain itu, penggunaan fungsi pada kolom juga
menyebabkan indeks yang ada pada kolom tersebut tidak dieksekusi oleh Optimizer.
Hal lainnya, jika penggunaan fungsi pada kolom tersebut tidak dapat dihindari, maka dapat dilakukan pembuatan function-based-index pada kolom yang akan dilakukan transformasi dengan fungsi SQL.
- Penggunaan perintah IN dan EXISTS masing-masing memiliki spesialisasi sendiri dalam query. Agar penggunaannya efektif, perintah IN sebaiknya digunakan bila selective-predicate berada di dalam subquery sedangkan penggunaan EXISTS sebaiknya digunakan bila selective-predicate berada pada parent query.
- Pemanggilan query-query secara berulang dengan struktur yang sama, dimana pada setiap pemanggilanya hanya berbeda pada parameternya dapat dioptimasi dengan menggunakan bind-variable. Hal ini bertujuan agar Oracle tidak perlu melakukan hard parsing.
- Penggunaan indeks yang tidak terbaca oleh Optimizer menyebabkan eksekusi perintah SQL yang dilakukan menjadi lambat dan terkesan bahwa pembuatan indeks yang ada menjadi sia-sia. Untuk mengatasinya, seringkali harus dilakukan penggantian struktur pada perintah SQL agar optimizer dapat membaca indeks yang ada pada proses eksekusi. Hal lain yang dapat dilakukan adalah dengan memaksa optimizer menggunakan indeks dengan penggunaan INDEX_HINT. Berikut ini merupakan hal-hal yang mempengaruhi optimizer tidak menggunakan indeks dalam eksekusi query :
o Untuk penggunaan is null maka is null tersebut dapat diubah strukturnya menjadi nvl dan ditambah function based index agar optimizer dapat melakukan pencarian dengan index
o Untuk penggunaan inequality maka inequality tersebut dapat diganti dengan equality sehingga optimizer dapat melakukan pencarian dengan index.
o Untuk kurang optimalnya index maka diperlukan pengecekan index mana yang tepat dengan selective predicate yang ada di dalam query dan akan di buat index baru untuk hal tersebut.
- Jika tidak ada partitioned-index tidak ada pada tabel yang terpartisi, maka Oracle menyediakan dua buah jenis indeks untuk partisi, yaitu Global-Partitioned-Index dan Local-Partitioned-Index. Penggunaan Global-Partitioned-Index digunakan untuk proses transaksi yang dilakukan setiap hari atau Online Transaction Processing (OLTP) sedangkan Local-Partitioned-Index digunakan untuk analisis proses transaksi atau Online Analisis Processing (OLAP). Hal lainnya mengenai penambahan sebuah indeks harus disesuaikan antara jenis indeks dengan kebutuhan query. Misalnya untuk melakukan penambahan indeks pada sebuah fungsi SQL, maka function-based-index adalah jenis indeks yang tepat.
3.5 Perancangan Peningkatan Kinerja Sistem Basis Data SIDJP Core dengan SQL Tuning
Bagian ini akan dijelaskan mengenai perancangan restrukturisasi dan indexing pada sistem basis data SIDJP Core. Dalam mempersiapkan kebutuhan SQL Tuning pada basis data SIDJP Core, tahap awalnya meliputi pembelajaran awal mengenai organisasi, kebutuhan dilakukannya tuning pada basis data SIDJP Core dan proses bisnis yang
sedang berjalan di organisasi, terutama yang berkaitan dengan basis data SIDJP Core. Seiring dengan analisis proses yang berkaitan dengan basis data SIDJP Core, dilakukan pula penilaian kinerja melalui bagian Performance dari Enterprise Manager Oracle di SIDJP Core. Dari hasil analisis bagian Performance, diambil seluruh Top SQL pada jangka waktu yang telah ditentukan (time tabel activity terlampir pada lampiran L131).
Bagian tahap awal perancangan SQL Tuning pada basis data SIDJP Core meliputi pengambilan query yang terdapat pada Top SQL. Pengambilan query-query ini dilakukan secara bertahap dalam waktu tertentu untuk memastikan data yang valid dalam melakukan SQL Tuning. Kemudian dilakukan pengujian terhadap masing-masing query dengan tools TOAD for Oracle dalam hal waktu akses dan proses eksekusinya. Dilanjutkan dengan proses SQL Tuning dengan teknik yang tepat sesuai dengan proses eksekusi yang dikenakan pada tabel yang diakses. Dalam memastikan SQL Tuning berhasil dilakukan pada query yang bersangkutan, dilakukan perbandingan waktu, CPU cost dan I/O cost pada query sebelum dan setelah dilakukan SQL Tuning.
Dari hasil analisis penilaian performance yang dilakukan mengenai Top SQL dari SIDJP Core, dilakukan SQL Tuning dengan teknik restrukturisasi perintah SQL dan teknik indexing. Proses SQL Tuning tersebut akan digambarkan melalui alur pola pikir proses SQL Tuning secara umum, kemudian menjadi pedoman untuk melakukan SQL Tuning terhadap kumpulan query pada top SQL.
Proses SQL Tuning diawali dengan menjalankan explain plan dari tools Toad for Oracle. Dalam hal ini, tujuan dalam melakukan SQL Tuning dilakukan dengan berusaha untuk mengurangi langkah yang diperlukan untuk proses JOIN dan mengurangi waktu akses ke baris-baris dengan penggunaan indeks. Hal ini dapat dilakukan dengan
memeriksa langkah-langkah yang akan dijalankan oleh Optimizer melalui explain plan pada tools Toad. Gambar 3.4 menunjukkan proses mengenai langkah-langkah yang dilakukan dalam SQL Tuning untuk menentukan teknik yang tepat terhadap masing-masing query. Berikut ini adalah gambar 3.4 berupa alur pola pikir untuk menggambarkan proses perancangan dalam menentukan restrukturisasi SQL dan indexing pada query-query yang bersangkutan :
