none
(Sumber: milis SQL Server) Shrink Database SQL Server Boleh atau Tidak? RRS feed

Jawaban

  • Jadi inget pelajaran system operasi. Pernah ngedefrag harddisk nggak ? Kalo pernah yach mirip kayak gitu.

    Kalo di harddisk fragmentasi terjadi karena ngedelete file atau terjadi pemekaran file tetapi tidak cukup sehingga ada bagian file yang lokasi berada jauh dari pecahan lainnya. Tidak tersusun. Di database juga sama. Di system operasi ada nama FAT bukan gaji tapi file allocation table. Memuat peta harddisk pada prinsipnya.

    Kalo di sql server adanya GAM (global allocation map) dan beberap allocation table / map lainnya. Karena sql server lebih komplek dari os maka butuh peta/table yang beraneka ragam. Fragmentasi table menjadi berat ? Hmm... Baca lagi dech.. di bagian bawahnya ditulis

    This code shrinks the whole database on a single SQL Server Instance. I instantly figured out where this code was used, and then I removed it. After I got rid of the code, I rebuilt and reorganized indexes. For the next 5 days, I faced no problem at all. Well, this is another reason not to shrink the database. Shrinking the database causes heavy fragmentation of the tables and reduces the performance. After shrinking, it seems that rebuilding indexes is necessary. But again, there should not be any real need to shrink the database. Do NOT shrink your database. =====

    Shrinking boleh tapi keliatannya rebuild index harus dilakukan. Kalo nggak dishrink juga bermasalah sebetulnya. Seperti kata budha "Hidup ini adalah penderitaan. Kita cuma menukar-nukarnya dari penderitaan satu ke penderitaan lain",

    Masalah tidak dishrink :

    1. membaca tabel menjadi tidak terurut. harus lompat-lompat area. Mungkin secara gam tidak tetapi secara fat iya. karena sql server menyimpan datanya di file dan filenya diatur oleh fat. jadi bisa double fragmentation.

    2. tidak efesien tempat. Btw kalo mau riset lebih lanjut bisa ke codeplex. Keywordnya sql server internal. Nanti ada open source project untuk ngeliat isi gam tadi.

    Dijawab oleh: Johan Max


    Best Regards,
    Agnes Sannie [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Senin, 01 April 2013 09.44
    Moderator

Semua Balasan

  • Jadi inget pelajaran system operasi. Pernah ngedefrag harddisk nggak ? Kalo pernah yach mirip kayak gitu.

    Kalo di harddisk fragmentasi terjadi karena ngedelete file atau terjadi pemekaran file tetapi tidak cukup sehingga ada bagian file yang lokasi berada jauh dari pecahan lainnya. Tidak tersusun. Di database juga sama. Di system operasi ada nama FAT bukan gaji tapi file allocation table. Memuat peta harddisk pada prinsipnya.

    Kalo di sql server adanya GAM (global allocation map) dan beberap allocation table / map lainnya. Karena sql server lebih komplek dari os maka butuh peta/table yang beraneka ragam. Fragmentasi table menjadi berat ? Hmm... Baca lagi dech.. di bagian bawahnya ditulis

    This code shrinks the whole database on a single SQL Server Instance. I instantly figured out where this code was used, and then I removed it. After I got rid of the code, I rebuilt and reorganized indexes. For the next 5 days, I faced no problem at all. Well, this is another reason not to shrink the database. Shrinking the database causes heavy fragmentation of the tables and reduces the performance. After shrinking, it seems that rebuilding indexes is necessary. But again, there should not be any real need to shrink the database. Do NOT shrink your database. =====

    Shrinking boleh tapi keliatannya rebuild index harus dilakukan. Kalo nggak dishrink juga bermasalah sebetulnya. Seperti kata budha "Hidup ini adalah penderitaan. Kita cuma menukar-nukarnya dari penderitaan satu ke penderitaan lain",

    Masalah tidak dishrink :

    1. membaca tabel menjadi tidak terurut. harus lompat-lompat area. Mungkin secara gam tidak tetapi secara fat iya. karena sql server menyimpan datanya di file dan filenya diatur oleh fat. jadi bisa double fragmentation.

    2. tidak efesien tempat. Btw kalo mau riset lebih lanjut bisa ke codeplex. Keywordnya sql server internal. Nanti ada open source project untuk ngeliat isi gam tadi.

    Dijawab oleh: Johan Max


    Best Regards,
    Agnes Sannie [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Senin, 01 April 2013 09.44
    Moderator
  • thanks pak infonya jelas skali saya beberapa kali melakukan shrink database, apalagi jika menghapus/memindahkan data dlm jumlah banyak kadang stlh itu saya merasa agak lambat, salah satunya pernah juga rebuild index tp ga sadar ada hubungannya sama shrink database :D


    Best Regards,
    Agnes Sannie [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Senin, 01 April 2013 09.44
    Moderator
  • Sebaiknya dihindari dan gunakan backup trancate log aja.

    -- step 1 
     
    
    BACKUP LOG AdventureWorks TO DISK = 'c:\backups\advw20120317.trn' 
     
    
    -- step 2 
     
    
    USE AdventureWorks
    GO
    ALTER DATABASE AdventureWorks
    SET RECOVERY SIMPLE
    GO
    ALTER DATABASE AdventureWorks
    SET RECOVERY FULL
    GO
    
    

    Fragmentasi table : pemetaan table berdasarkan kolom dan baris, erat kaitannya dengan performa.

    Dijawab oleh: Subhan


    Best Regards,
    Agnes Sannie [MSFT]
    MSDN Community Support | Feedback to us
    Get or Request Code Sample from Microsoft
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Senin, 01 April 2013 09.45
    Moderator