none
TABLE COMPRESS DANIŞMA... RRS feed

  • Soru

  • Size bir konuda danışmak istedim ;

    TABLE COMPRESS üzerine birkaç denemem oldu Okuma sayısını düşürmek ve performans için.

    Konu şu; büyük birkaç tablom var ama programın içinde aktif kullanılan tablolar bunlar.

    Daha sonra birkaç rapor çektim ve  querysini aldım ve birkaç tabloda okuma sayısının bayağı yüksek olduğunu gördüm örneğin o query de bir tablom 1518256 Logical Read yaparken diğeri de 341589 logical read yapıyordu daha sonra bu taplolarımı Compressledim aşağıdaki gibi.

    ALTER TABLE dbo.Deneme1 REBUILD WITH (DATA_COMPRESSION = PAGE)

    ALTER TABLE dbo.Deneme2 REBUILD WITH (DATA_COMPRESSION = PAGE)

    Olarak.

    Ve 1518256 değeri bir anda 14056 ya 341589 değeri ise 34250 ye düştü fakat bu performans açıısndan neye mal olur.

    Compress yöntemi burada uygunmudur ki bu taplolar programın temeli..

    Düşüncelerinizi ve yorumlarını bekliyorum

    Teşk.

    19 Kasım 2012 Pazartesi 13:51

Tüm Yanıtlar

  • Row veya Page bazındaki compression işlemi temelde I/O cephesinde performans sağlamaktadır ancak CPU tarafını da izlemekte fayda var. Verinin büyüklüğüne bağlı olarak compress ve decompress işlemleri için daha fazla CPU kaynağı gerekebilir.

    Ayrıca compression  backup/restore işlemlerini etkilemese de özellikle export işlemini doğrudan etkilemektedir.


    Ahmet Kaymaz
    http://www.ahmetkaymaz.com
    C# VB.NET ASP.NET kitabı

    19 Kasım 2012 Pazartesi 14:14
  • CPU yu yorma olasılığını düşünüyorum ama bir yandan da bir query de sadece bir tablo 1 milyon küsürden fazla okuma yapıyor diğerlerini söylemiorum bile peki siz bu durumda olsanız ne yapardınız.Birde Export açısından ne gibi sıkıntı çıkarabilir ?
    19 Kasım 2012 Pazartesi 14:38
  • Export işini ne sıklıkta yapıyorsun ki bu kadar çok dikkate alıyorsun?

    Söz konusu sistem, OLTP bir sistemdir diye tahmin ediyorum. Şayet böyleyse, daha ziyadesiyle performans açısından dikkate alman gereken şey SELECT ve DML işlemleridir. Biz banka ortamında Table Compression'ı, Loglama yaptığımız tablolarda kullanıyorduk. Yani sadece yazılan, ama çok nadiren okunan tablolarda. SELECT, DELETE ve UPDATE işlemlerinin de yapıldığı tablolarda test etmemiştik.

    Senin durumunda, READ sayısı olarak tabii çok çarpıcı bir sonuç ortaya çıkmış. Fakat CPU kullanımı, Compression öncesine göre ne kadar fark etti? En kritik soru bu bence. Eğer oluşan CPU tüketim masrafı sıkıntı yaratmayacak şekildeyse, sorgularının (DML dahil) Duration'ları ve Read'leri kayda değer şekilde düştüyse, bence kullanmanda herhangi bir sakınca yok.

    Bu testlerinin sonuçlarını da bizimle paylaşırsan sevinirim.


    Ekrem Önsoy - MCDBA, MCITP:DBA+DBD, MCSD.Net, MCSE, ITILv3 | http://ekremonsoy.blogspot.com

    20 Kasım 2012 Salı 20:06