Menjadi Database Consultan untuk SQL Server

Udah beberapa hari ini gw disibukkan dengan "Seseorang" yang sedang stress disebuah
perusahaan. Dia butuh consultasi soal database dia yang lambat. Kalo database lambat sih menurut gw banyak factor -hehehe, dengan menggunakan pengalaman yang gw dapet di Project UFIN-. Bisa querynya jelek, ngak punya index, atau mungkin servernya belet. Well, kalo soal
querynya disuruh betulin sih gw nyerah, karena gw juga ngak tau bisnis proses yang ada diperusahaan itu. Jadi yang pertama kali gw tanya sih langsung Indexnya.

Malem-malem temen gw itu nelpon ke gw.

Edo : yo, tolongin gw dong. Database gw kok lambat banget ya ?
Me : Indexnya gimana ?
Edo : Database gw cuma 4GB
Me : (heeeh, maksudnya apa ya) iya, tapi lo pasangin index ngak disetiap tabel ?
Edo : Masa cuma 4GB, butuh Index ...
Me : (huahuahua ... ) Ya haruslah ... Index itu penting buat searching data. Kalo ngak si SQL Engine akan nyari data secara sequen.

Yang gw heran, kenapa kalo 4GB ngak butuh index? Mungkin dia nganggep 4GB itu database yang kecil, soalnya waktu di UFI dia selalu ngurusin database yang besarnya > 90GB. Ya udah,karena secara detail gw kurang tau masalah disana itu, gw kasih aja best practice untuk pembuatan index yang gw tau.
- Cari column query yang sering dibuat pada WHERE clause, trus buat indexnya.
- Untuk lebih optimal, kalo data pada column tersebut kurang dari 5%, kasih index. kalo lebih mendingan ngak usah karena si SQL Engine akan selalu menggunakan table scan saat searching data.

Beberapa waktu kemudian, dia nelpon lagi dan kayaknya masih stress. karena dia langsung mau kerumah gw untuk diskusi tentang SQL Server. Kemudian hari itu tiba dan gw langsung buka laptop dan Restore database scheme. Setelah gw liat-liat. Heh ? Databasenya parah banget, bahkan servernya cuma ada Drive C, hufff... Database master ya disitu, TempDB ya disitu, User Database juga disitu, Makin berat dong.
Beberapa kesalahan yang gw temuin pada databasenya (berdasarkan pengalaman).
- Tidak ada Primary key (tidak semua tabel, tapi most of all aren't uses the Primary Key)
- Index tidak ada -Idem commentnya-
- Database cuma menggunakan mdf dan ldf untuk filegroupnya

Dan yang lebih parah adalah:
Edo : Yo, kadang gw sebel banget sama aplikasinya
Me : Kenapa ?
Edo : Kalo cabang lagi transaksi, trus jaringan putus. Tuh transaksi jadi sampah semua, gw harus bersihin satu-persatu.
Me : (Heeeh, Kacau bet) Hahaha, itu mah gw tau do, masalahnya kenapa
Edo : Emangnya kenapa ?
Me : Pasti lo ngak pake transaction tuh, mangkanya data lo ancur
Edo : Transaction gimana ?
Me : Sini, coba gw liat Stored Procedure lo...

See, There isn't transaction scope on DML Statement. Bahaya banget, (udah brapa taun ya perusahaannya kayak gitu, dia anak baru sih). Setelah menganalisa database schemenya. Gw coba buat beberapa solusi.
- Membuat beberapa filegroup menjadi beberapa file (ndf)
- Membuat Proper Index
- Primary key, hmmm ... lumayan sulit. takut2 kalo bermasalah. Mendingan buat indexnya aja pada primary key
- Transaction, It's got to be......
- Buat Reindex dan Reorganize Index buat Estimated Execution Plan

Huff ... untung semua kesalahan itu udah pernah gw alamin sendiri. jadinya lumayan ngerti. Kayak Index dan database filegroup, gw ngalamin masa-masa itu saat. dan yang transaction gw ngalamin waktu kerja di JST... hehehe pengalaman pahit. Sampe sekarang berarti gw punya dua kerjaan, yaitu ngurusin batch process di BNI dan Consultan di perusahaan laen (Free of Charge). Emang bener banget kalo pengalaman itu adalah guru yang paling berharga.. semoga apa yang gw lakuin ini bisa ngebantu temen gw itu...