Neden DELETE + REORG boş disk alanı (DB2) yok?


18

DB2'de büyük ikili veriler içeren bir tablo var. Şimdi tüm tabloyu temizledim ve runstats, reorg, runstats koştum, ancak alınan disk alanı miktarı değişmiyor. Burada ne yanlış olabilir?

Tablo, aşağıdaki gibi oluşturduğum kendi tablo alanında bulunur:

CREATE BUFFERPOOL "MY_BP" SIZE 250 AUTOMATIC PAGESIZE 4096;
CREATE LARGE TABLESPACE MY_TBS IN DATABASE PARTITION GROUP IBMDEFAULTGROUP PAGESIZE 4096 MANAGED BY AUTOMATIC STORAGE EXTENTSIZE 64 PREFETCHSIZE 64 BUFFERPOOL MY_BP OVERHEAD 10.500000 TRANSFERRATE 0.140000 FILE SYSTEM CACHING;

Aşağıdaki gibi sildim / yeniden düzenledim:

DELETE FROM MY_TBL
RUNSTATS ON TABLE MY_TBL WITH DISTRIBUTION AND DETAILED INDEXES ALL
REORG TABLE MY_TBL
RUNSTATS ON TABLE MY_TABLE WITH DISTRIBUTION AND DETAILED INDEXES ALL
ALTER TABLESPACE MY_TBS REDUCE

MY_TBL tablosu her şeyden önce 2.5GB aldı ve silindikten / yeniden düzenledikten sonra sadece 3 MB daha az yer kaplıyor .

FWIW: DB2 / NT v9.5.2 kullanıyorum.


Bu db2 v8'deki sistemler için çalışıyor mu?
Tony

Yanıtlar:


22

Otomatik depolama kullandığınızı tahmin edeceğim. (Bunun başka türlü olabileceğinden değil ... bunun otomatik depolama ile gerçekleşmesi kolaydır.)

Sorun büyük olasılıkla veritabanınızın kendisi için alanı geri alması, ancak diski işletim sistemine geri bırakmamasıdır. Bu, masa alanı için Yüksek Su İşaretini kontrol ederek çok kolay bir şekilde gösterilebilir.

Aşağıdakileri yapın

db2 list tablespaces show detail

Bu size her tablo alanını ve diskte ne kullandığını gösterecektir. Used pagesveritabanının kaç sayfa disk kullandığını gösterir. Bunu karşılaştırmak total pages(diskte talep edilen toplam) ve High water mark (pages)irade size gerçekten ihtiyacınız olandan daha fazlasını talep edip etmediğinizi gösterecektir. (örneğin, az kullanılan sayfalar, çok yüksek toplam sayfalar ve toplam sayfalara yakın Yüksek Su İşareti).

Bu kullanılmayan alan kurtulmak ve (otomatik depolama altında) aşağıdakileri çıkaracağını işletim sistemine geri döndürmek için: db2 alter tablespace <tablespace name> reduce max. misal

db2 alter tablespace ts1 reduce max;

Bu, DB2'nin yüksek su işaretini düşürmesine ve kullanılmayan diski işletim sistemine geri bırakmasına neden olur. (Bunu, sistem geçici veya kullanıcı geçici tablo alanları için değil, yalnızca normal ve büyük tablo alanları için yapabileceğinizi unutmayın).

Otomatik depolama olmadan DMS kullanıyorsanız, biraz farklı bir komut seti kullanmanız gerekir:

db2 alter tablespace <tablespace name> lower high water mark;
db2 alter tablespace reduce (<containter name> or [all containers] integer K|M|G or integer PERCENT);

misal

db2 alter tablespace ts1 lower high water mark;
db2 alter tablespace reduce (all containers 500 M);

Çalıştığımız yerde, bunu bazı bakım komut dosyalarımıza koyduk, böylece disk alanını geri kazandığımızdan emin olmak için yeniden yaptığımızda bunu otomatik olarak çalıştırıyoruz. Bizim durumumuzda DB2 LUW 9.7 FP 4 kullanıyoruz, bu nedenle sürümünüz için doğru bilgilere erişebildiğinizden emin olmak için Bilgi Merkezi'ni 9.5 için iki kez kontrol etmek zarar vermez.

DÜZENLEME: Tablo alanlarınız DB2 9.7'ye yükseltilmiş bir veritabanından geldiyse, muhtemelen geri kazanılabilir depolama özniteliği ayarlanmaz. Bu, DMS'den otomatik depolamaya yükseltseniz bile geçerlidir. Her iki şekilde de ısırırsınız, çünkü yüksek su işaretini gerçekten düşüremezsiniz. Tablo ve verileri boşaltmanız, tablo boşluklarını bırakmanız gerekir. Ardından otomatik depolama alanını kullanarak tablo alanını yeniden oluşturun ve tablolarınız için verileri içe aktarın.


+1 - siteye katkıda bulunan bir DB2 uzmanını görmek güzel. Geçmişte bu alanda zayıftık.
Philᵀᴹ

1
Sadece hızlı bir yorum, DB2 9.5'te, alter tablespace <tbsp> lower high watermarkveya alter tablespace <tbsp> reduce maxsözdizimini kullanamazsınız - bunlar DB2 9.7'ye kadar tanıtılmadı.
Ian Bjorhovde

İlk yazımda bahsettiğim gibi, bunların çoğunu zaten denedim ve işe yaramadı. Şimdiye kadar çözümü kendim buldum: Disk alanı geri alınamadı çünkü LOBLOBDATA seçeneğini belirtmedim, disk alanını BLOB'lardan veya CLOB'lardan geri almak istiyorsanız gerekli görünüyor. Lütfen burada kendi soruma cevabımı görün. Her neyse, cevabınıza verdiğiniz çabayı takdir ediyorum, +1!
Alexander Tobias Bockstaller

9

Tablo MY_TBL, bir BLOBsütunda büyük ikili veriler içerir . REORGKomutun dokümantasyonu, DB2'nin bu tür nesneleri yeniden düzenlemekten kaçındığını çünkü zaman alıcı olduğunu ve kümelemeyi geliştirmediğini söylüyor. Ancak, LONGLOBDATAseçenek belirtilirse DB2 LOB verilerini yeniden düzenlemeye zorlanabilir . Kullanılmayan alan DB2 tarafından yeniden kullanılabilir, bu nedenle yeni veri eklemek yeni tahsis edilmeden önce mevcut, kullanılmayan sayfaları doldurur.

Koşu

REORG TABLE MY_TBL LONGLOBDATA

boş tablonun kullandığı 2.5GB disk alanını başarıyla geri aldı.

Bu seçeneği bilmiyordum ve belgeleri ilk kez okuduğumda denetledim.


İyi bir nokta. Ancak, bir DB2NightShow "Attack of the Blob" bölümünde öğrendiğim kadarıyla LONGLOBDATA seçeneğini daha uzun sürdüğü ve / veya performans sorunlarına neden olduğu için çok sık çalıştırmak istemezsiniz (çevrimiçi REORG'lar yapmaya çalışıyorsanız) .
Chris Aldrich

Karşılaştığımız veritabanları endüstriyel makinelerden alınan günlük verilerini içermektedir. Bu tür veritabanlarına yönelik sorgular zaman açısından kritik değildir, bu nedenle bir yeniden düzenleme sırasında performans düşerse, bu bir sorun değildir.
Alexander Tobias Bockstaller
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.