Bitmap的問題
今天工作中發現了產品部署在Oracle上的一個defect,由於在一個low cardinality建立了一個bitmap索引,由於程式對於這個列的修改過於頻繁,導致資料庫的效能下降。
我們都知道每個點陣圖索引被分為多個bitmap segment,而對於點陣圖索引的更新,其封鎖粒度在bitmap segment一級(而不是在行),一個bitmap segment又會對應到多個資料行,這樣對於頻繁更新的表,點陣圖索引就一定會提高發生鎖阻塞的這種可能性,從而降低系統效率。
SQL> create bitmap index my_indx on student(name);
索引已建立。
SQL> update student set name='A' where id=1011;
已更新 1 行。
1 row updated.
另外一個session事務
SQL> update student set name='B' where id=1012;
該事務被阻塞。
點陣圖索引的更新代價比較高,且易於發生鎖阻塞,所以其比較適用於靜態表,如DSS,而絕對不適用於OLTP系統。因此我在表中取消了這個點陣圖索引,並且正在考慮如何修改應用。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/12361284/viewspace-598/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 關於點陣圖索引的split及bitmap to rowid實現問題索引
- BITMAP索引的INLIST ITERATOR與BITMAP OR索引
- bitmap
- c# svg轉Bitmap Bitmap轉ImageSourceC#SVG
- Android中的BitmapAndroid
- Clickhouse的bitmap函式函式
- Bitmap的分析與使用
- 核心中bitmap的使用
- Jedis bitmap
- Bitmap IndexIndex
- bitmap to rowid執行計劃下的基數計算疑問
- 實現簡單的BitMap
- Bitmap的載入和Cache
- bitmap indexes 的結構分析Index
- BitMap介紹
- Redis-BitMapRedis
- 淺談BitMap
- bitmap join indexIndex
- CREATE BITMAP INDEXIndex
- Redis 中 BitMap 的使用場景Redis
- Bitmap回收—Canvas: trying to use a recycled bitmap android.graphicsCanvasAndroid
- 怎樣計算Bitmap的記憶體佔用和Bitmap載入優化記憶體優化
- 7.36 BITMAP_COUNT
- 演算法---BitMap演算法
- 理解Android BitmapAndroid
- Android Bitmap 使用Android
- WPF Bitmap轉imagesource
- Android Bitmap 初探Android
- 獲取bitmap大小
- b+ and bitmap indexIndex
- The Secrets of Oracle Bitmap IndexesOracleIndex
- Restrictions on Create Bitmap IndexesRESTIndex
- 《扶蘇的問題》題解
- Redis的Bitmap、HyperLogLog和GeoRedis
- Bitmap的圖片壓縮彙總
- Bitmap的載入與快取策略快取
- Android Bitmap的常用壓縮方式Android
- android中Bitmap的剪下與拉伸Android