February 2009 - Posts

• Mengukur Kinerja ETL

  download sample code Waktu lagi nyari-nyari cara buat mempercepat SSIS saya menemukan sebuah artikel menarik tentang bagaimana cara melakukan tuning kinerja SSIS. Sebelum melakukan tuning tentu harus tahu dulu bagian ETL yang harus di-tune, dan untuk mengetahuinya ternyata caranya cukup mudah. Pertama, kita hitung dulu total waktu eksekusi package yang akan di-tune. Dalam contoh berikut saya telah membuat sebuah ETL sederhana yang men-generate satu juta data, melakukan transformasi lookup dari sebuah cache lalu me-load hasilnya ke dalam sebuah file teks. Supaya fleksibel, jumlah data yang di-generate dapat diatur lewat variable NumberOfRows. Package pertama ini saya beri nama Package-Full.dtsx Setelah dilakukan tes dengan penuh ketelitian, ternyata waktu eksekusi yang dibutuhkan 00:01:09.049 Berikutnya menghitung waktu yang dibutuhkan untuk me-load data ke dalam teks file. Sebelum melakukannya saya copy dulu package Package-Full.dtsx dan hasil copy-nya diberi nama Package-Destination.dtsx. Selanjutnya bekerja dengan Package-Destination.dtsx, hapus Flat File Destination dan ganti dengan Row Count lalu eksekusi package Package-Destination.dtsx. Waktu yang ditempuh untuk me-load data ke dalam text file adalah waktu eksekusi Package-Full.dtsx dikurangi waktu eksekusi Package-Destination.dtsx Hasil eksekusi package kali ini adalah 00:00:19.458. Itu berarti waktu load adalah 00:01:09.049 - 00:00:19.458 = 00:00:49.591 Terakhir adalah menghitung waktu extract data sekaligus menghitung waktu transformasi. Seperti pada langkah sebelumnya, copy dulu Package-Destination.dtsx dan ubah nama copy-nya dengan Package-Source.dtsx. Setelah selesai, hapus Lookup, Derived Column, dan Union All pada Package-Source.dtsx. Kemudian hubungkan Script Component dan Row Count lalu eksekusi package Package-Source.dtsx. Setelah dieksekusi ternyata waktu Extract adalah 00:00:10.746. Ini berarti waktu transformasi adalah waktu eksekusi Package-Destination.dtsx dikurangi waktu eksekusi Package-Source.dtsx, 00:00:19.458 - 00:00:10.746 = 00:00:08.712. Berikut adalah hasil pengukuran kinerja ETL diatas: Step Waktu Extract 00:00:10.746 Transform 00:00:08.712 Load 00:00:49.591 Total 00:01:09.049   Wah wah, ternyata proses paling lama terjadi pada saat data di-Load ke dalam text file. Mungkin sudah waktunya saya ganti harddisk yah? Artikel untuk melakukan tuning kinerja SSIS selengkapnya dapat dilihat disini. Posted Feb 20 2009, 11:06 PM by si_hendrik with no comments Filed under: SSIS

• The SSIS logging provider "SSIS log provider for SQL Server" failed with error code 0x800401F3 ((null))

  Seharian kemarin saya dapat error itu di Job yang saya schedule. Error lengkapnya sebagai berikut: Executed as user: SQLServer2008\Administrator. Microsoft (R) SQL Server Execute Package Utility  Version 9.00.4035.00 for 64-bit  Copyright (C) Microsoft Corp 1984-2005. All rights reserved.    Started:  9:13:40 AM  Error: 2009-02-19 09:13:55.76     Code: 0xC0014010     Source: MyPackage      Description: The SSIS logging provider "SSIS log provider for SQL Server" failed with error code 0x800401F3 ((null)).  This indicates a logging error attributable to the specified log provider.  End Error  Error: 2009-02-19 09:18:27.06     Code: 0xC0014010     Source: MyPackage      Description: The SSIS logging provider "SSIS log provider for SQL Server" failed with error code 0x800401F3 ((null)).  This indicates a logging error attributable to the specified log provider.  End Error  DTExec: The package execution returned DTSER_FAILURE (1).  Started:  9:13:40 AM  Finished: 9:18:28 AM  Elapsed:  287.297 seconds.  The package execution failed.  The step failed. Error tersebut terjadi apabila master package dijalankan dan di dalamnya terdapat Execute Package Task untuk memanggil MyPackage. Tetapi apabila hanya MyPackage yang dieksekusi error tidak terjadi. Awalnya saya pikir konfigurasi logging di MyPackage bermasalah. Tapi pas dah saya ubah logging nya dari SQL Server ke Text File error tetap terjadi. Kemudian saya coba hapus loggingnya dan hasilnya... masih tetep error. huhuhu. Setelah kebingungan seharian, dan gak bisa nemuin orang yang mengalami masalah yang sama di internet akhirnya saya beranikan diri untuk menghapus Execute Package Task MyPackage dan connection MyPackage.dtsx (package nya masih saya simpan di File System karena masih dalam development). Setelah saya buat ulang keduanya, dan master package saya eksekusi error pun hilang dan job saya berhasil dieksekusi. Sampai sekarang masih bingung apa yah yang menyebabkan error itu, soalnya cara saya membuat Execute Package Task dan Connection kan sama, merupakan hasil generate tools yang saya bikin. Posted Feb 20 2009, 03:51 AM by si_hendrik with no comments Filed under: SSIS, Error

• Kok Ada yang Tega Membenci SSIS

  Pas lagi iseng-iseng nyari group SSIS di facebook, malah ketemu sama group orang-orang yang membenci SSIS. Sempet sok demi menemukan group ini pertama kali, trus penasaran dan ngebaca-baca isinya, tapi akhirnya saya malah gak bisa berhenti ketawa demi mendapati alasan kebencian mereka. Di salah satu postingannya ada yang curhat betapa sulitnya men-debug SSIS karena harus melakukannya dengan cara menampilkan pesan melalui message box. Jadi inget waktu pertama kali bekerja dengan SSIS dan bagaimana saya melakukannya sekarang. Di postingan lain ada yang cerita soal betapa dia terjebak dalam konfigurasi package yang membingungkan, atau terpaksa mengerjakan SSIS lantaran punya bos yang notabene fans beratnya Microsoft. Setelah membaca postingan-postingan itu saya baru sadar bahwa sepertinya orang-orang tersebut tidak memahami SSIS atau mungkin tidak mengetahui best practice dalam menggunakannya. Padahal Microsoft sudah menerbitkan contoh dan tutorial yang sangat mudah dipahami di setiap edisi Books Online, dan kumpulan best practice SSIS yang dirangkum dalam Project REAL. Seperti yang dibilang temen saya yang nge-fans berat sama pak haji Roma Irama, "Sungguh Terlalu..." Demi mendapati hal ini saya jadi semakin semangat buat bikin e-book soal SSIS, walaupun sebenernya bingung sendiri gimana atau kapan yah ngerjainnya secara kerjaan saya sendiri sekarang sedang banyak-banyaknya. heuheuheu. Posted Feb 12 2009, 10:58 PM by si_hendrik with 4 comment(s) Filed under: A Life Less Ordinary

• The Importance of DontSaveSensitive

  Secara default property ProtectionLevel sebuah SSIS package berisi EncryptSensitiveWithUserKey. dengan nilai ini berarti hal-hal yang sifatnya sensitive seperti password connection yang terdapat pada connection manager akan di-encrypt berdasarkan user yang membuat package tersebut. Apabila Anda mendevelop package nya seorang diri tentu tidak akan menjadi masalah, tapi apabila Anda bekerja dalam sebuah team yang sering kali memodifikasi package milik teman satu team Anda, tentu akan sedikit tidak nyaman dengan munculnya pesan error yang mengatakan bahwa package tersebut memiliki Encryption Key berbeda. Untuk menghindarinya ada beberapa cara yang dapat ditempuh, dan yang biasa saya kerjakan (dan sukai) adalah dengan mengatur ProtectionLevel-nya dengan DontSaveSensitive. Dengan konfigurasi seperti ini, setiap kali kita membuat package, maka password connection tadi tidak akan ikut disimpan pada saat penyimpanan package. Informasi tentang connection string beserta dengan password nya saya simpan dalam SQL Server yang mode autentikasinya Windows Authentication. Hal ini juga memudahkan kita pada saat maintenance. Jika policy di perusahaan mengharuskan pengubahan password SQL secara berkala, connection string yang harus diubah cukup disatu tempat dan pada saat package dieksekusi connection string yang terdapat pada package akan mengikuti konfigurasi di SQL Server tadi. Posted Feb 12 2009, 09:35 AM by si_hendrik with no comments Filed under: SSIS

• 02: What's The Story?

  Waktu ikut bantuin bos kasim bikin e-book buat project otak untuk sub topic business intelligence bareng yudhi, kita sempet kepikiran buat bikin sebuah skenario yang menjadi benang merah antara SSIS, SSAS, dan SSRS. Sayangnya, karena keterbatasan waktu kita berdua mengerjakannya dengan sangat menyesal akhirnya skenario itu dibatalkan. Dalam skenario itu, dikisahkan tentang seorang penjual voucher telpon seluler yang memiliki beberapa kios di seputaran jakarta. Di sore hari setelah kios tutup, para pemiliknya mengirimkan sebuah file berbentuk csv yang berisi data-data penjualan pada hari tersebut dan pemesanan voucher untuk esok hari kepada si penjual voucher via e-mail. Setelah e-mail nya diterima, si penjual menyimpannya di dalam sebuah folder lalu menggabungkan dan mulai menghitung berapa banyak voucher yang terjual pada hari itu dan berapa banyak voucher yang harus dikirimkan ke kios di keesokan harinya. Bayangkan betapa banyaknya waktu yang dibutuhkan untuk menyimpan attachment file csv yang terdapat di e-mail, menggabungkannya dan kemudian menghitung penjualan dan kebutuhan setiap kios. Hal ini menyebabkan si penjual tidak memiliki waktu untuk membuat strategi dalam mengembangkan usahanya. Dan kita akan membantu memecahkan masalah yang dihadapi si penjual dengan Business Intelligence menggunakan fitur-fitur yang terdapat pada SQL Server. Pada blog berikutnya saya akan mulai mencoba membuat analisa dari kisah si penjual voucher diatas. Posted Feb 10 2009, 11:06 PM by si_hendrik with 1 comment(s) Filed under: Belajar BI

• 01: Memahami Konsep Business Intelligence

  Mari kita mulai mempelajari Business Intelligence dengan memahami konsepnya. Kalo boleh saya simpulkan dari berbagai sumber, Business Intelligence adalah kemampuan untuk mengumpulkan data dari berbagai sumber, memproses dan menampilkannya dalam bentuk yang dapat dengan mudah dianalisis oleh orang-orang bisnis pada suatu organisasi sehingga dari hasil analisis tadi dapat dihasilkan keputusan yang lebih baik untuk organisasi tersebut. Tentunya dengan pengambilan keputusan yang baik akan membantu bisnis berkembang dengan pesat dan menjaga bisnis tetap berada pada performa terbaik. Dari apa yang sering saya temui, biasanya sebuah organisasi menyimpan datanya dalam berbagai bentuk. Sebagian besar data disimpan di database, tapi ada juga yang disimpan dalam file excel karena struktur database-nya tidak dapat mengakomodasi data-data dalam file excel tadi. Ditambah lagi, database yang digunakan bermacam-macam. Bisa jadi dalam database legacy seperti AS/400, SAP, SQL Server dan Oracle. Tentunya keberagaman sumber data seperti ini akan menyulitkan orang-orang bisnis untuk melakukan analisis data secara cepat dan akurat. Pada pembuatan sebuah solusi BI, data-data tadi akan diambil, dibersihkan dan distandardisasi, lalu disimpan ke dalam sebuah database yang disebut data warehouse. Proses pengambilan, pembersihan dan penyimpanan tadi dikenal dengan proses Extract, Transform, Load (ETL). Data warehouse terdiri dari dua tipe table. Pertama adalah fact table yang menyimpan data numerik yang merupakan kunci bisnis yang akan diagregasi dan dianalisa. Dan yang kedua adalah dimension table yang mendefinisikan aspek bisnis dimana fact diagregasi. Sebagai contoh pada data penjualan, data tentang jumlah barang yang dijual dan nilai transaksi penjualan disimpan dalam fact table sementara produk dan waktu penjualan disimpan dalam dimension table. Setelah datanya disimpan di data warehouse, kemudian data tadi akan diproses ke dalam multi dimensional database yang disebut database OLAP (Online Analytical Processing). Di dalam OLAP terdapat cube yang menyimpan summary fact dan dimension yang dapat di slice and dice untuk keperluan analysis. OLAP inilah yang nantinya dapat diakses oleh orang-orang bisnis menggunakan aplikasi BI seperti Excel, Reporting Services atau Performance Point. Keseluruhan proses mulai dari ETL hingga ke OLAP adalah proses yang biasanya dilakukan setiap hari sekali secara otomatis, seringnya dikerjakan pada tengah malam dan selesai sebelum jam masuk kerja sehingga pada saat orang-orang bisnis tiba di kantor mereka sudah disuguhi laporan analisis dari data-data pada hari sebelumnya. Sebagai catatan, biasanya data pada database OLAP tidak bersifat realtime, tapi h-1. Hal ini dimaksudkan agar prosesnya tidak menggangu performance database OLTP yang berjalan. Selain itu juga karena untuk keperluan analisis, data yang dianalisis adalah data yang telah selesai ditransaksikan dan bukan data yang sedang ditransaksikan. OLTP vs OLAP Mungkin akan timbul pertanyaan tentang mengapa datanya harus disimpan dalam database yang terpisah dari database transaksi (OLTP: Online Transaction Processing), dan kenapa tidak membuat report analisis yang langsung mengakses database OLTP tadi. Tentunya ini akan menghemat biaya yang harus dikeluarkan sebuah organisasi untuk proses pengembangan solusi BI. Database OLTP dirancang untuk kemudahan data entry dan bukan untuk keperluan report. Membuat report dari database OLTP dengan struktur yang kompleks akan sangat sulit dilakukan. Selain itu proses pengambilan data pada saat report ditampilkan akan mempengaruhi performance database OLTP karena untuk analisis data yang diambil merupakan agregasi yang akan menghabiskan resource server. Dengan database OLAP, data yang disimpan sudah berupa hasil agregasi yang akan mempercepat waktu dan performace database. Selain itu struktur data pada database OLAP juga akan memudahkan proses pembuatan report dan analisis data. Pada blog selanjutnya saya akan membuat sebuah skenario sederhana yang akan digunakan dalam pembuatan solusi BI. Posted Feb 03 2009, 02:12 AM by si_hendrik with 1 comment(s)

• Belajar BI Begins

  Sebagai seseorang dengan title BI Consultant, sejujurnya saya belum pernah merancang dan mengembangkan sebuah solusi BI secara keseluruhan. I always be the SSIS or SSRS guy tanpa pernah menyentuh SSAS. Rasanya akan sangat menyenangkan apabila suatu hari nanti saya memiliki experience mengerjakannya, terutama membuat OLAP cube di SSAS. Saya pernah membicarakan hal ini dengan manager saya, tapi beliau menyarankan agar saya memperdalam SSIS dan SSRS yang telah saya kuasai sambil belajar sendiri SSAS. Tapi kan susah yah kalo belajar-belajar sendiri tanpa menggunakan contoh yang nyata. Biasanya belajar itu berhasil apabila sambil mengerjakan projek. Jadi sambil menunggu kesempatan dari bapak bos, saya berpikir untuk membuat sebuah seri tentang belajar BI secara kecil-kecilan. Mudah-mudahan seri ini bermanfaat bukan hanya untuk saya sendiri, tapi juga buat rekan-rekan yang ingin belajar mengenai Business Intelligence. Selain itu, mudah-mudahan suatu hari nanti manager saya tadi membaca blog ini dan mempertimbangkan atau bahkan mempercayakan sebuah project buat saya. hehehe. Saya sadar dalam belajar pasti banyak kekurangan dan kesalahan, jadi untuk Anda yang memiliki experience BI dan melihat atau menyadari apabila ada yang salah dengan apa yang saya kerjakan, feel free to give your comment. Pada blog berikutnya saya akan mulai mempelajari Business Intelligence dengan memahami konsepnya. Posted Feb 03 2009, 02:10 AM by si_hendrik with 3 comment(s) Filed under: Belajar BI