第乙個主題 介紹undo表空間不足的問題
undo表空間不足的問題，基本可劃分兩類
針對這兩個情況的處理方法如下（僅供參考）：
1.通過下面語句查詢當前例項undo空間的使用情況(active、unexpired型別段的佔比）
select b.tablespace_name,
nvl(used_undo,0) "used_undo(m)",
total_undo "total_undo(m)",
trunc(nvl(used_undo,0) / total_undo * 100, 2) || '%' used_pct
from (select nvl(sum(bytes / 1024 / 1024), 0) used_undo, tablespace_name
from dba_undo_extents
where status in ( 'active','unexpired')
group by tablespace_name) a,
(select tablespace_name, sum(bytes / 1024 / 1024) total_undo
from dba_data_files
where tablespace_name in
(select value
from v$spparameter
where name = 'undo_tablespace'
and (sid = (select instance_name from v$instance) or
sid = '*'))
group by tablespace_name) b
where a.tablespace_name (+)= b.tablespace_name
/2.進一步檢視active、unexpired段的具體使用情況
select tablespace_name,status,sum(bytes/1024/1024/1024) gb from dba_undo_extents group by tablespace_name,status;
3.如果是active段使用過高導致undo段無法擴充套件，則可以根據以下方法解決：
a.臨時新增資料檔案到undo表空間，暫緩問題
b.問題暫時緩解以後，需尋找問題的根本原因，分析當前session中undo段的使用情況，通過以下語句查詢：
--檢視系統中會話使用的回滾段
select r.name rbs,
nvl(s.username, 'none') oracle_user,
s.osuser client_user,
p.username unix_user,
s.sid,
s.serial#,
p.spid unix_pid,
s.machine
,s.program
,s.module,
t.used_ublk * to_number(x.value) / 1024 / 1024 as undo_mb ,
to_char(s.logon_time, 'mm/dd/yy hh24:mi:ss') as login_time,
to_char(sysdate - (s.last_call_et) / 86400, 'mm/dd/yy hh24:mi:ss') as last_txn,
t.start_time transaction_starttime
from v$process p,
v$rollname r,
v$session s,
v$transaction t,
v$parameter x
where s.taddr = t.addr
and s.paddr = p.addr
and r.usn = t.xidusn(+)
and x.name = 'db_block_size'
order by undo_mb desc
/c.如果發現某個session大量使用undo，分析session連線資訊和執行的語句（使用者、應用主機，模組等等），最後調整應用
備註：session執行當前執行的可能不會占用undo段，這種情況下，需要查詢session當前事務中歷史執行的所有sql，可以關聯查詢v$open_cursor,v$active_session_history等檢視。
4.如果是unexpired型別的段使用過高，這種情況下，不會出現undo表空間無法擴充套件，oracle會將unexpired型別的段強制使用來確保dml操作得以繼續執行。但是這種情況下oracle需要搜尋最早的expired段，同時需要將expired段進行一些特殊處理，會導致整個操作過程速度下降，在大量併發dml操作下，由於裙帶效應，會導致整個資料庫執行緩慢，活動session數上公升。
分析方法：
檢查v$undostat中的unxpblkreucnt: number of unexpired undo blocks reused by transactions，這個數值大於0，說明事務由於需要undo空間而從unexpired undo segment中重用空間的次數
處理方法：
a.臨時新增資料檔案到undo表空間，暫緩問題
b.問題暫時緩解以後，需尋找問題的根本原因，即什麼原因導致unexpired型別段使用過高。可能導致這類問題的原因如下：
undo表空間大小設定不合理
undo_retention引數設定的過期時間過長
undo_retention設定合理，但是由於oracle自動調整的原因，導致
expired型別段過高(通過查詢v$undostat中的tuned_undoretention)。這種情況下考慮禁用自動調整（_undo_autotune引數）
其它oracle bug導致
注意：關於通過切換例項使用的undo表空間方法來解決這類問題，不在此文討論範圍。
至此，兩類導致undo表空間不足的問題介紹完畢；下乙個主題介紹單個session占用過高的undo（但是未導致undo空間不足），導致資料庫效能急劇下降的問題。
UNDO相關問題總結（二）
這一次主題為單個session占用大量undo，導致資料庫效能急劇下降的問題總結。關於 問題現象 問題原因 引申現象 資料庫中出現大量latch undo global data 或者 wait for a undo record 相關的等待，但在當前例項中查詢每個session的undo使用情況時...
UNDO自我理解總結
場景 當在更新資料的時候，發現更新的值寫錯了，這時就需要將已經更新的地方恢復到原始資料。基本概念 在更新的過程中，oracle會將原始的資料都放入到undo裡，這樣當以上情況發生後，就可以從undo中拿到原本的資料了。undo是在oracle 11g被提出的，由undo tablespace進行管理...
CocoaPods相關問題總結
關於pod install 和 pod update 第一次為專案新增依賴或者每一次修改podfile後使用pod install。當你執行pod install，它只會解決那些沒有在podfile.lock檔案中列出來的pods的依賴。對於沒有在podfile.lock中列出的pods，會去匹配p...