2023年6月25號客戶的users表空間暴漲了900g，經過查詢系統監控記錄，找到了相關的sql語句和責任人，具體過程如下：
這裡需要先說明乙個情況，由於之前users表空間使用率達到了99%後，由於使用的是bigfile，無法新增檔案，只好把自動擴充套件引數開啟，並且設定了每次擴充套件20g，這裡注意一下，如果設定過小會使很多會話發生buffer busy waits 等待事件，但是設定這麼大有個缺點就是如果sql語句出現笛卡兒積的話就會是表空間迅速暴漲，這裡的這個例子就是這種情況下的一種。
第一步，首先檢視了下users 表空間增長歷史記錄，具體截圖如下，確定了users表空間增長的時間範圍是在 6月25號下午14點到6月25號晚上23點：
第二，從6月25號下午14點到 晚上23點開始，檢視了下具體段的增長情況，發現users表空間有乙個******(這裡遮蔽掉)使用者下的臨時段持續增長，漲了859g，由臨時段的名稱看以看出都是乙個段，且位於4號檔案的705052090塊，可以推斷出是由於某乙個錯誤sql導致的，而4號檔案剛好就是users表空間，而臨時段主要是由2種方式來生成：① 重建索引生成 ② 通過ctas方式建表形成，重建索引不可能，因為沒有哪個索引的大小達到800g，所以只可能是哪個使用者通過ctas的方式建表導致的，而且在23點監控不到這個臨時段了，可能表已經建成或者建表語句報錯後臨時段釋放了。
大段的監控歷史截圖：
第三，仔細分析了下出現問題的時間段內ddl語句的監控，發現了乙個錯誤記錄，如下圖，由此說明了是臨時段達到了最大值sql語句報錯了，所以空間釋放了，這裡我們可以看出當時的會話的sid是1567，登入的terminal的ip位址為10.31.6.61，具體同事是 ******(這裡遮蔽掉)
第四，通過sid和serial#檢視當時具體的sql監控，截圖如下，由圖看出該sql是從25號中午11點35分30秒開始執行，一直執行了12小時17分鐘後報錯，這個也和users表空間增長的時間範圍相符
第五，把該sql拿出來看了下執行計畫和sql語句,發現該執行計畫的cost花費和預估的返回行數都超級大：
sql語句（這裡只列出出現問題的地方）：
createtableg_tx_db_label_base_4 nologgingas
select
。。。。。。。。。。。。。
fromg_tx_db_label_1 a
leftjoing_tx_db_label_2_comp b
ona.
單位名稱=a.單位名稱
leftjoing_tx_db_label_2_comp_1 c
ona.
單位名稱=a.單位名稱;
很顯然，，，，，，，， 連線條件寫錯了
sql執行計畫，cost和rows都非常的恐怖呀。。。。。。。。：
由此可以看出空間暴漲的原因是該sql最後的3張表的連線條件無效導致的，我把該sql拿出來重新執行了下發現短短1分鐘內臨時段漲了2g多，至此可以肯定導致6月25號空間暴漲的sql就是這個了
最後，我給出的一些建議，建議充分利用一下我們的監控系統：
加入笛卡兒積的監控，每隔20分鐘監控一次
增加對執行了5個小時以上的sql的監控
增加對執行計畫中預估的行數以及cost花費超大的sql的監控(例如本例中的sql語句)
對統計資訊有誤的表的監控（如表實際有200w行，但是統計資訊中的num_rows為0 ，這種可能會出現笛卡兒積的連線）
對資料庫中的分割槽表全分割槽掃瞄的sql監控
Oracle臨時表空間為何暴漲？
昨天在做測試的時候發現乙個非常奇怪的問題 在程式的查詢模組中做查詢的時候，開始速度很快，但是過了一段時間以後速度就變慢，最後乾脆就報錯，不工作了。在排錯的過程中，發現oracle臨時表空間暴漲，達到了幾十個gb，在oracle中對session進行跟蹤，發現磁碟空間還在不停的消耗，幾乎是每隔5s，臨...
mysql空間暴漲 SQL語句引起的空間暴增分析
概述 mysql資料庫由資料檔案與各類日誌檔案組成，通常情況下，空間增長是由資料檔案 binlog檔案引起的，但個別情況下是短期內mysql產生了大量的磁碟臨時表引起的。本案例就是由低效sql產生了大量磁碟臨時表引起的。分析收到簡訊告警，一生產庫空間使用率達到90 隨後登陸主機檢視，發現空間使用率為...
壓縮暴漲的ora10g資料庫臨時表空間的大小
近日在維護ora10g資料庫時發現臨時表空間的資料檔案temp.dbf從最初的512m猛增到5g，嚴重占用了磁碟空間。經過多次努力，總於解決問題，現將查詢到的臨時表空間的相關資料以及處理方法簡要歸納如下 1 臨時表空間的作用 臨時表空間主要用途是在資料庫進行排序運算 管理索引 訪問檢視等操作時提供臨...