31 October 2008

Mengenal Transaction Logs

Introduction

The transaction log and how SQL uses it seems to be one of the most misunderstood topics among newcomers to the DBA role. I’m going to see if I can shed a little light on what the transaction log is, why SQL uses it, how the different recovery modes affect the log and how to manage it.
What is the Transaction Log?

Introduction

The transaction log and how SQL uses it seems to be one of the most misunderstood topics among newcomers to the DBA role. I’m going to see if I can shed a little light on what the transaction log is, why SQL uses it, how the different recovery modes affect the log and how to manage it.
What is the Transaction Log?

At its simplest, the transaction log is a log of all transactions run against a database and all database modifications made by those transactions. The transaction log is a critical part of the database’s architecture.

The transaction log is not an audit log. It’s not there so that the DBA can see who did what to the database. It’s also not a data recovery tool. There are third-party tools that can get audit or data-recovery info from the log, but that is not its primary purpose.

The transaction log is predominantly used by the SQL engine to ensure database integrity, to allow transaction rollbacks and for database recovery.
How does SQL use the log?

When changes are made to a database, whether it be in an explicit transaction or an auto-committed transaction, those changes are first written (hardened) to the log file and the data pages are changed in memory. Once the record of the changes is in the log, the transaction is considered complete. The data pages will be written to the disk at a later time either by the lazy writer or by the checkpoint process.

Transaction log entries are considered active until the data pages that were modified by that transaction have been written to disk. Once that occurs, the log entries are considered inactive and are no longer necessary for database recovery.

If transactions are rolled back, either by an explicit ROLLBACK TRANSACTION, by an error if XACT_ABORT is on, or due to a loss of connection to the client, the transaction log is used to undo the modifications made by that transaction.

When a server is restarted, SQL uses the transaction log to see if, at the point the server shut down there were any transactions that had completed but whose changes may not been written to disk, or any transactions that had not completed. If there are then the modifications that may not have been written to disk are replayed (rolled forward) and any that had not completed are rolled back. This is done to ensure that the database is in a consistent state after a restart.

Lastly, backups made of the transaction log can be used to recover a database to a point-in-time in case of a failure.

The transaction log is also used to support replication, database mirroring, change data capture and log shipping. I won’t be going into how they affect the log here.
Recovery models and the Transaction Log

The database recovery model does not (with the exception of bulk operations) affect what is written to the transaction log. Rather it affects how long log entries remain in the log.
Simple Recovery Model

In the simple recovery model, the transactions log entries are kept only for the purpose of database integrity and are not kept for database recovery purposes. Once the log entries are marked as inactive, that is once the associated data pages have been written to disk, the log entries can be discarded. In simple recovery mode, when a checkpoint operation runs, all inactive log records are removed from the transaction log and the space is made available for reuse.

In simple recovery, operations that qualify as bulk operations are minimally logged

This is the simplest recovery mode in terms of log management as the log manages itself. The downside of simple recovery is that because transaction log backups cannot be made, recovery of the database can only be done up until the latest full or differential database backup.

Some of the high-availability features in SQL do not work if the database is in simple recovery; specifically log shipping and database mirroring.
Full Recovery model

In full recovery model transaction log entries are kept for both database integrity and database recovery purposes. Inactive log records are retained in the transaction log until a lob backup occurs.

In full recovery, all operations are fully logged, including operations that qualify as bulk operations.

Full recovery can be difficult to manage as the log can grow beyond expected if transaction log backups don’t occur, or if there’s an increase in the amount of database activity that occurs between log backups. Because log records are not discarded until they have been backed up, a database in full recovery mode can be recovered to any time using a combination of full, differential and log backups.
Bulk-logged recovery model

Bulk-logged is very similar to full recovery, except that in bulk-logged, bulk operations are minimally logged. When operations are minimally logged, the full details are not written to the transaction log, however all extent and page allocations are still logged.

The advantage of bulk-logged recovery is that if there are bulk operations occurring, the impact those operations have on the transaction log is less than it would be if the database was in full recovery mode. However the transaction log backups may be much larger than the transaction log itself since the log backups include any data pages modified by bulk operations since the previous log backup
Managing transaction logs
Picking a recovery model

The key to effectively managing transaction logs is to know what the availability and recovery requirements are for the database. The choice of recovery model should not be chosen because of performance issues or space concerns.

If there is no requirement for point-in-time recovery and it is acceptable, in the case of a disaster, to restore the database to the last full/differential backup, then simple recovery model can be used. In reality, it’s not that common to have a database where the loss of several hours of data is acceptable, so in general simple recovery model should be limited to development or testing environments or databases that can be completely recreated from a source if they fail.

If is a requirement for point-in-time recovery and minimal or no data loss in the case of a disaster, then the database should be in full or bulk-logged recover model and regular log backups should be done. The frequency that the log backups get done at should be determined by the maximum acceptable data loss in the case of a complete disaster.

If the database is in full or bulk-logged recovery model then log backups must be done. Without log backups the log entries will never be discarded from the log and the log file will grow without bound. Since one of the main reasons for having a database in full or bulk-logged recovery model is to allow the database to be restored without data loss, it’s important to have an unbroken log chain to allow a restore to the point of failure, if necessary.
Log chains

Log backups form a chain which starts with the first full backup done to the database (or the first full backup after switching to full recovery). To be able to restore to a point in time, the log chain must stretch unbroken from a full or diff backup to the point that the database needs to be recovered to. If the log chain is broken, either by a log truncation, a missing log backup file or a switch to simple recovery mode, then the database cannot be restored past that point.

For this reason it is very important not to truncate the transaction log of a database. Truncating the transaction log of a database that is in full or bulk-logged recovery means discarding log records that may be needed for database recovery. The same applies to changing the database to simple recovery and back to full/bulk-logged. Either way, the log chain is broken and a new full or differential backup of the database is needed to restart the log chain.
Log size

The transaction log should be sized based on the amount of data modifications made to a database and the frequency of the log backups. Large data modifications, such as data loads or index rebuilds should be taken into account when calculating a log file size.

In simple recovery model the transaction log should not grow as the interval between checkpoints (which truncate the log) is based on the amount of data modifications made. If the log does grow, it may be that there are long-running transactions or transactions that have been left open. Either may indicate a problem with the application.

In full or bulk-logged recovery model, if the transaction log grows it may indicate that the frequency of data modifications has increased and as such, the interval between log backups should be decreased. It may also indicate long running transactions or that the log backup jobs are not running properly.
Conclusion

The transaction log is a crucial piece of a database and at least a basic understanding of it is necessary to effectively manage a system. I hope this has clarified some of the details of what the

Login YM dengan Banyak ID (Multple Login)


Bagi pengguna internet tentu tidak asing dengan aksi chating, terlebih pelanggan yahoo tentu sering menikmati layanan Yahoo messenger dari Yahoo, ini merupakan layanan terbesar di indonesia yang disediakan oleh sebuah perusahaan bisnis. Secara asali atau default yahoo messenger hanya dapat melakukan Log In dengan satu ID. Kenyataan umumnya kita memiliki lebih dari satu email yang masing-masing memiliki fungsi berbeda. Pada kondisi tertentu kita butuh untuk Online (OL) dengan menggunakan yahoo messenger dengan beberapa ID sekaligus, nah bagaimana caranya? yuk kita praktek barang...

Sebenernya ini bukan trik baru, di internet dah banyak soal ini, cuman buat nambah-nambah dokumentasi, lagian aku suka lupa jadi mending saya iket aja disini.

Mulailah dengan membuka registry windows, unumnya registry buka dengan melakukan klik pada tombol start kemudian klik menu run. Pada kotak dialog yang muncul ketik "regedit", tanpa tanda petik dan tekan Enter atau klik tombol OK, sehingga muncul Registry Editor.

Pada Jendela Registri Editor klik tanda Plus (+) pada HKEY_CURRENT_USER, Klik lagi pada tanda plus (+) pada Software, klik tanda Plus (+) pada yahoo, klik tanda plus (+) pada pager, terakhir klik pada Test, ingat bukan klik tanda plus lho yah.

Kalo udah klik pada Test, trus geser mouse ke jendela bagian kanan, lakukan klik kanan, Klik New lanjutkan dengan Klik DWORD Value. maka akan muncul New Value #1, langsung aja ketik atau ganti dengan "Plural", tanpa tanda petik. Klik Ganda pada Plural tadi, pada kotak isian value data isikan dengan nilai 1 (satu), pada frame Base pilih opsi Decimal. Klik OK dan tutuplah Registri Editor.

Silahkan jalankan Yahoo Messenger, laginlah dengan ID yang anda kehendaki. Kalau ingin login dengan ID ke dua jalankan lagi yahoo Messenger lagi, sehingga ada dua jendela Yahoo Messenger, isikan dengan ID yang berbeda.

29 October 2008

Instalasi Zencafe Untuk Warnet Berbasis Linux


Satu minggu bergerilya mencari distro linux yang cocok untuk di pasang pada warnet yang rencananya berbasis linux. Jujur aja mendirikan warnet berbasis linux merupakan pekerjaan yang belum pernah dilakukan. Kalaupun pake linux hanya dipake untuk server internet di kantor dan semua komputer tergolong baru. Setelah bergerilya pilihan sementara jatuh pada Zencafe, namun perjuangannya belum selesai sampai disitu.

Zencafe merupakan distro turunan Zenwalk yang dirancang untuk digunakan dikalangan warnet. Makanya semua fitur dan perangkat lunak yang dibutuhkan untuk warnet hampir dapat dipenuhi oleh distro yang satu ini. Bahkan mungkin Zencafe merupakan satu-satunya distro yang sudah dilengkapi dengan billing sistem.

Zenwalk sendiri merupakana keturunan dari distro slackware. Satu distro yang sangat dikenal dengan keamanan dan kestabilannya. mungkin karena emang masih seketurunan sehingga proses instalasinya juga mirip-mirip atau bahkan persis dengan leluhurnya. Selama proses instalasi zencafe hanya menyediakan tampilan mode text, walau proses instalasinya cukup sederhana dan gak ribet.

Setelah balapan donlot sama temen file image Zencafe darisini, akhirnya saya harus mengakui bahwa kecepatan dolot saya emang lemot, padahal temen donlot dua distro sekaligus yaitu Zencafe dan PCLinuxOS. Kesokan harinya ngambil fila image ke kantor temen.

Proses Instalasi berjalan lancar walau tanpa panduan dan sempet gagal satu kali. distro satu ini agak beda dengan sitro yang lain, hardisk SATA 160GB saya terdeteksi sebagai sda, ada info dari temen bahwa hardisk IDE-pun terdeteksi sebagai sda bukan hda seperti pada distro umumnya.

lebih detail mengenai langkah-langkah instalasi zencafe bisa dilihat dilink-link berikut :

ditulis oleh Deny Andreas dari Awali, manual book yang sulit dicari, umumnya link dari manual book ini udah broken.

ditulis oleh komunitas mahasiswa UGM , kemaren sempet broken sih, tapi coba lagi deh.
sementara baru itu yang ketemu, kalo ada yang punya artikel lainnya boleh deh tambahin....

28 October 2008

Karakter: Bisakah Kita Merubahnya?

Pernah lihat binatang koala?

Atau paling tidak, tahu tentu yang namanya koala.

Si koala ini adalah binatang khas dari Australia.
Dia tenar sekali disana karena bentuknya memang lucu dan mengemaskan. Coklat gelap warnanya dan wajahnya lugu banget gitu.

Si koala ini punya karakter pemalas. Menurut penelitian (& juga menurut sumber salah seorang teman saya), si koala adalah salah satu binatang paling malas di dunia ini.

Konon dia tidur 22 jam dalam sehari!

Huebat ya… Padahal dalam satu hari hanya ada 24 jam, dimana dengan kata lain, ya hanya 2 jam tok si koala bangun dan beraktifitas.

Dia hidup di batang sebuah pohon. Kalau mau makan pun dia malas bergerak dan hanya mau bergeser sedikit untuk mengambil makanan yang sudah tersedia saja di sekitar dia. Bergerak paling banyak dia lakukan hanya kalau sedang melakukan hubungan seks.

Itulah mungkin kenapa si koala kemudian mendapat titel sebagai binatang pemalas.

Ya memang begitulah karakternya… Mana bisa berubah lagi?

Tetapi bagaimana ceritanya kalau dengan karakter seorang manusia?

Apa masih berubah?

Dalam satu bulan belakangan ini saya banyak sekali mendapat kalimat yang sama dari waktu ke waktu terus-menerus, “Ya memang begitu kok karakternya. Mana bisa berubah lagi, Liz”

Dahi saya kok jadi berkerut ya.

Apa iya manusia itu bisa sama disejajarkan seperti seekor koala, yang nota bene masuk ke dalam spesies binatang, dan tidak bisa berubah?

Dahi saya tambah berkerut nih sekarang kayaknya…

Saya yakin tidak ada yang tidak mungkin dilakukan oleh seorang manusia.

Yang dibutuhkan lagi-lagi hanya seonggok, segepok, segumpal keyakinan dan kemauan. Dan saya yakin semua pasti sudah pernah mendengar kalimat tersebut sebelumnya dalam beragam percakapan, dalam beragam artikel, dalam beragam hal.

Masalahnya sekarang seberapa besar keyakinan dan kemauan kita untuk berubah??

Kalau keyakinan dan kemauan itu cukup besar, rasanya tidak ada yang tidak mungkin.

Saya tidak percaya dengan kalimat tadi, ‘Ya sudah karakter. Mana bisa berubah lagi’. Menurut saya itu adalah sebuah alasan yang dangkal sekali.

Karakter pemarah, karakter pemalas, karakter tukang ngaret, karakter defensif, karakter pembohong, karakter pembual, karakter egois, karakter kompulsif, karakter penakut, karakter depresif, karakter manipulatif dan beribu-ribu karakter lainnya SEMUA BISA BERUBAH.

Saya berani mempertaruhkan semua milik saya untuk kalimat saya tersebut : semua karakter BISA BERUBAH.

Pertanyaannya ‘hanya’lah, mau tidak si manusia itu berubah?
Kalau sudah mau berubah, pertanyaan selanjutnya (& yang paling penting) mau tidak dia berjuang untuk berubah????

Perubahan bukan hal yang mudah dan dapat dicapai dalam waktu satu malam.

Saya pun tidak pernah bilang itu akan menjadi hal yang mudah serta cepat dicapai seperti orang makan cabai lalu langsung pedas.

Perubahan itu mungkin perlu dilakukan dengan usaha yang maha gigih sedikit demi sedikit, selangkah demi selangkah, setakar demi setakar.

(Saya menyadari hal tersebut dari pengalaman pribadi).

Kebayang sudah berapa puluh tahun mungkin si karakter telah mengendap dan mengalir lancar dalam diri.
Kebayang pula sudah berapa puluh tahun kita telah terbiasa menjalankan karakter tersebut.

Seperti kalau misalnya si koala yang juga sudah turun temurun dari nenek moyang begitulah adanya. Hal yang mustahil rasanya untuk merubah si koala.

Tetapi sekali lagi, apa iya kita sama sejajar dengan si koala?
Bagaimana kabarnya dengan atribut ‘kemanusiaan’ yang melekat pada manusia seperti otak, kepintaran, intensi dan kemauan bebas?

Apa tidak ada gunanya semua untuk menghasilkan keadaan yang lebih baik?

Banyak orang mengatakan ingin berubah dan akan berubah.
Tetapi tidak banyak orang yang benar-benar berjuang mewujudkan perubahan itu.

Setiap orang juga tentunya pernah kena teguran, tamparan dan bahkan cacian.

Tetapi tidak banyak orang yang bisa belajar dari teguran, tamparan dan cacian tersebut serta menjadikannya sebagai wake up call.

Mungkin dulu pernah ada penelitian atau percobaan yang ingin membuat si koala lebih aktif, lebih gesit dan lebih banyak bergerak (he3x… mungkin lho ya. Siapa tahu memang pernah ada penelitian atau percobaan itu).

Namun tampaknya tidak sukses tuh karena si koala tetap lah si koala.

Lalu bagaimana dengan kita?

Apakah kita tetaplah kita yang sama dablek-nya dengan si koala???

Atau kita masih bisa menggunakan atribut ‘kemanusiaan’ kita untuk berjuang dan berubah menghasilkan keadaan yang lebih baik?

Saya yakin kita bisa.

Saya pribadi berharap Yang Diatas terus membimbing saya (& kita semua) untuk menggunakan atribut ‘kemanusiaan’ yang ada dengan bijak.

27 October 2008

Situs BPPI Depkominfo DiDeface


Situs Balai Pengkajian dan Pengembangan Informasi Departemen Komunikasi dan Informatika malam tadi dideface. Dalam situs tersebut secara exslusive ditampilkan surat pernyataan tentang pelaksanaan eksekusi mati ketiga terpidana mati bom bali 1, Mukslas, Imam Samudra dan Amrozi.

Surat yang ditampilkan dengan cantik itu menyatakan sikab Mukhlas, Imam Samudra dan Amrozi menanggapi akan dilaksanakannya eksekusi mati atas mereka. Dalam pernyataannya itu mereka mengajak saudaranya untuk menyatakan perang terhdap dan membunuh individu-individu yang terlibat eksekusi tersebut.

Melihat pemberitaan dan aksi-aksi rekan-rekan Amrozi CS nampaknya eksekusi terhadap terpidana bom bali 1 akan "seru". akan ada banyak Hambatan, Tantangan, Ancaman dan bahkan gangguan dalam pelaksanaan eksekusi.

Kelompok ini masih belum berhenti melakukan aksi-aksinya. Kematian para pemimpin mereka tidak menghentikan aksi-aksi mereka. Anggapan yang mengatakan jika kepalanya mati maka badannya tidak akan dapat bergerak jelas salah, Karena yang mereka ikuti bukan ketua atau pemimpin mereka.

24 October 2008

"Semprit Saja Polisinya.....!"

Tulisan ini merupakan tulisan lama yang dipublikasikan melalui social blog di http://isnanto.multiply.com. Sayangnya layanan di Multiply ditutup per Desember 2012, maka sebagian posting yang dipublish di Multiply diimport ke blogger. Namun demikian catatan-catatan diskusi yang terjadi tidak dapat dipindahkan ke layanan blogger. Semoga masih tetap bermanfaat.

Pernahkan anda membayangkan berlalulintas dijalan raya yang ramai dengan pengendara serta persimpangan jalan-persimpangan jalan tanpa trafic light atau lampu pengatur lalulintas?. Mungkin mendengarnya saja anda akan ngeri apalagi kalau menjalaninya secara langsung.

Tapi hal itu tidak hanya sebuah bayangan, namun sungguh nyata adanya. Pemadaman listrik yang dilakukan oleh PLN secara bergilir secara tidak langsung berdampak pula pada ketertiban dan kelancaran lalulintas. Setiap kali suatu kawasan mengalami giliran pemadaman maka dapat dipastikan pula lampu penatur lalulintas tidak berfungsi sama sekali. Maka siap-siap saja terkaget-kaget setiap kali melewati perempatan jalan atau pertigaan.

Tidak semua orang atau pengendara tahu jadwal pemadaman listrik, jangankan pengendaraa dari luar kota, dari dalam kotapun belum tentu hafal. setidaknya hampir setiap satu hari dalam satu pekan ada kawasan tertentu yang pemadaman, setiap itu pula lampu lalulintas mati. Mungkin kalau setiap hari terjadi tidak berfungsinya lampu pengatur lalulintas, setiap pengendara akan hafal bahwa setiap melewati perempatan harus selalu siaga. tapi jika terjadi pada hari-hari yang tidak pasti tentu sangat membahayakan pengguna jalan.

Saat pagi hari ketika jalanan mulai ramai, polisi bersiaga penuh di perempatan jalan, seperti biasa setiap pagi jam 6.30 s.d 7.30 polisi membantu menertibkan dan melancarkan pengguna jalan, wajar memang itu adalah jam sibuk setiap hari karena umumnya merupakan jam aktifitas penuh dijalan. Beberapa polisi ada yang memasang pertanda atau tulisan sekedar pemberitahuan bahawa listrik padam dan lampu trafik lalulintas tidak berfungsi, sementara disebagian perempatan jalan lain, seolah-olah tidak berdaya menghadapi semrawutnya lalulintas, sebut saja begitu.

Selepas jam 7.30 polisi yang dibantu petugas dari Dinas Lalulintas Jalan Raya (DLLAJR) mulai membubarkan diri, kembali kekantor masing-masing, jalan mulai kosong dari pengatur lalulintas, mereka kembali ke kantor masing-masing, sementara sebagian lainnya masuk ke pos-pos tempat piket mereka, sementara listrik masih mati dan lampu pengatur lalulintas masih juga belum berfungsi. Biasanya pemadaman dimulai dari jam 6.30 hingga jam 17.00.

Nah bagi anda yang akan masuk kota purwokerto, waspadalah selalu disetiap perempatan, bisa jadi saat anda lewat adalah saat pemadaman listrik, sehingga lampu pengatur lalulintas tidak berfungsi. Saat melewati perempatan jalan, perhatikan dari arah kiri, kanan, depan bahkan belakang. bisa jadi dari ke empat arah itu sedanga ada kendaraan yang sedang melaju kencang.

Biasanya kita akan di "semprit" atau diberhentikan karena melanggar rambu-rambu pengatur lalulintas jika melaju terus di perempatan, nah ketika rambu-rambu pengatur lalulintasnya tidak berfungsi, dan kita melaju terus, siapakah yang melanggar?, tidak adakah pihak yang melanggar? siapa yang mesti di "semprit"? DLLAJR?