ORA-01652，temp表空間不足的相關問題及處理
十一長假期間也不得輕鬆，某日接到業務保障，資料庫報錯，導致某關鍵業務不能正常執行，需要立即處理
原因分析
1，登入資料庫，檢視主機日誌，報錯內容為ORA-01652，temp表空間不足
ORA-01652: unable to extend temp segment by 128 in tablespace TEMP01
2，讓業務部門重新執行相關指令碼，發現佔用temp表空間的具體語句如下，目前temp表空間96GB，大約1個小時會被該sql使用滿，sql異常退出
Sql具體如下 INSERT INTO www.WWW_BILL_DTL_TEMP_0101(ACCT_ID,SERV_ID,FEE,BRAND, PHONE_ID,USER_TYPE) SELECT ACCT_ID, SERV_ID, sum(FEE) FEE,BRAND ,PHONE_ID,USER_TYPE FROM ( SELECT ACCT_ID, SERV_ID, SUM(FEE) F EE,BRAND,PHONE_ID,USER_TYPE FROM (select a.acct_id,e.serv_id,s um(b.unpay_fee) FEE,a.brand,a.phone_id,a.user_type from www.ACC_B ILL_010120121010 A , www.WWW_BILL_DTL_010120121010 B , www.OWE_MO NITOR_QUEUE_ACTION E where a.bill_id=b.bill_id and A.ACCT_ID=E. ACCT_ID and a.brand in (:"SYS_B_00",:"SYS_B_01",:"SYS_B_02",:"SY S_B_03",:"SYS_B_04",:"SYS_B_05") and b.fee_item_id>:"SYS_B_06" group by a.acct_id,e.serv_id,a.brand,a.phone_id,a.user_type ) g roup by ACCT_ID, SERV_ID,BRAND,PHONE_ID,USER_TYPE UNION ALL SE LECT ACCT_ID, SERV_ID, -:"SYS_B_07"*SUM(FEE) FEE,BRAND,PHONE_ID, USER_TYPE FROM (select a.acct_id,e.serv_id,sum(b.unpay_fee) FE E,a.brand,a.phone_id,a.user_type from www.WWW_BILL_010120121005 A , www.WWW_BILL_DTL_010120121005 B , www.WWW_MONITOR_QUEUE_ACTION E where a.bill_id=b.bill_id and A.ACCT_ID=E.ACCT_ID and a.bran d in (:"SYS_B_08",:"SYS_B_09",:"SYS_B_10",:"SYS_B_11",:"SYS_B_12 ",:"SYS_B_13") and b.fee_item_id>:"SYS_B_14" group by a.acct_id ,e.serv_id,a.brand,a.phone_id,a.user_type ) group by ACCT_ID, S ERV_ID,BRAND,PHONE_ID,USER_TYPE ) GROUP BY ACCT_ID, SERV_ID,BRAN D,PHONE_ID,USER_TYPE
執行計劃如下
Plan hash value: 3236377944 -------------------------------------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | -------------------------------------------------------------------------------------------------------------------- | 0 | INSERT STATEMENT | | | | 19281 (100)| | | 1 | HASH GROUP BY | | 2 | 184 | 19281 (2)| 00:03:52 | | 2 | VIEW | | 2 | 184 | 19280 (2)| 00:03:52 | | 3 | UNION-ALL | | | | | | | 4 | SORT GROUP BY | | 1 | 92 | 19271 (2)| 00:03:52 | | 5 | VIEW | | 1 | 92 | 19271 (2)| 00:03:52 | | 6 | SORT GROUP BY | | 1 | 144 | 19271 (2)| 00:03:52 | |* 7 | HASH JOIN | | 1 | 144 | 19270 (2)| 00:03:52 | | 8 | MERGE JOIN CARTESIAN | | 1 | 65 | 8717 (2)| 00:01:45 | | 9 | TABLE ACCESS FULL | WWW_MONITOR_QUEUE_ACTION | 1 | 26 | 2 (0)| 00:00:01 | | 10 | BUFFER SORT | | 257K| 9810K| 8715 (2)| 00:01:45 | |* 11 | TABLE ACCESS FULL | WWW_BILL_DTL_010120121010 | 257K| 9810K| 8715 (2)| 00:01:45 | |* 12 | TABLE ACCESS FULL | WWW_BILL_010120121010 | 16755 | 1292K| 10552 (1)| 00:02:07 | | 13 | SORT GROUP BY | | 1 | 53 | 9 (12)| 00:00:01 | | 14 | VIEW | | 1 | 53 | 9 (12)| 00:00:01 | | 15 | SORT GROUP BY | | 1 | 79 | 9 (12)| 00:00:01 | | 16 | TABLE ACCESS BY INDEX ROWID | WWW_BILL_DTL_010120121005 | 1 | 18 | 3 (0)| 00:00:01 | | 17 | NESTED LOOPS | | 1 | 79 | 8 (0)| 00:00:01 | | 18 | NESTED LOOPS | | 1 | 61 | 5 (0)| 00:00:01 | | 19 | TABLE ACCESS FULL | WWW_MONITOR_QUEUE_ACTION | 1 | 26 | 2 (0)| 00:00:01 | |* 20 | TABLE ACCESS BY INDEX ROWID| WWW_BILL_010120121005 | 1 | 35 | 3 (0)| 00:00:01 | |* 21 | INDEX RANGE SCAN | ITDX_ACCT_ID_10120121005 | 1 | | 2 (0)| 00:00:01 | |* 22 | INDEX RANGE SCAN | TPK_BILL_DTL_ID_10120121005 | 1 | | 2 (0)| 00:00:01 | --------------------------------------------------------------------------------------------------------------------
3，繼續分析原因。仔細分析該sql語句，實際上可以拆分為兩個並列子sql。後一部分的sql執行計劃是好的，不優的是上半部分，因此解決方案就很簡單了，把上半部分的統計資訊和索引做成和下半部分同樣的結構。經查確認，上部分的sql缺少相關索引，且由於表今天建立，且插入了大量資料，且沒有統計資訊，選擇列沒有設定索引，導致執行計劃不優。
SQL> select * from dba_objects where object_name ='WWW_BILL_DTL_010120121010'; OWNER OBJECT_NAME SUBOBJECT_NAME ------------------------------ -------------------------------------------------------------------------------------------------------------------------------- ------------------------------ OBJECT_ID DATA_OBJECT_ID OBJECT_TYPE CREATED LAST_DDL_TIM TIMESTAMP STATUS T G S ---------- -------------- ------------------- ------------ ------------ ------------------- ------- - - - ZC WWW_BILL_DTL_010120121010 1209877 1209877 TABLE 06-OCT-12 06-OCT-12 2012-10-06:11:19:25 VALID N N N
解決方法
1，表WWW_BILL_DTL選擇列ACCT_ID，在表WWW_BILL上bill_id，FEE_ITEM_ID新增組合索引，
2，然後重新收集統計資訊，sql即走合適的執行路徑了
exec dbms_stats.gather_table_stats('ZC',WWW_BILL_DTL_010120121010,method_opt => 'FOR ALL COLUMNS SIZE 1',cascade =>TRUE,estimate_percent => 40,granularity=>'all',degree => 4,no_invalidate => false);
exec dbms_stats.gather_table_stats('ZC',WWW_BILL_010120121010,method_opt => 'FOR ALL COLUMNS SIZE 1',cascade =>TRUE,estimate_percent => 40,granularity=>'all',degree => 4,no_invalidate => false)簡單總結：
1，本次問題出在新建的臨時表，沒有同時新建相關索引，且在資料建立和大量資料插入後，沒有立即收集統計資訊，導致oracle無法選擇合適的執行計劃，進而佔用大量臨時表空間，sql無法正常執行完成。
2，merge join cartesian（笛卡兒演算法）：是每個集合的任務一個成員都要與其他集合的每個成員進行匹配。因此原有執行計劃需要執行對兩個大表的N×N次查詢和排序，佔用大量temp表空間
相關推薦
ORA-01652，temp表空間不足的相關問題及處理
十一長假期間也不得輕鬆，某日接到業務保障，資料庫報錯，導致某關鍵業務不能正常執行，需要立即處理 原因分析 1，登入資料庫，檢視主機日誌，報錯內容為ORA-01652，temp表空間不足 ORA-01652: unable to extend temp segment by
ORA-03206，當表空間不夠時，如何以添加數據文件的方式擴展表空間
style 創建表空間 mage all 註意 flow ada -- 導入 準備導入一個數據庫，大約為33G，開始創建的空庫表空間為自增到20G，結果自然不夠，然後就開始自動擴展表空間大小 使用的如下語句 --自動擴展表空間大小 ALTER DATABASE DA
oracle 表空間 不足時如何處理
--1、查看錶在那個表空間 select tablespace_name,table_name from user_talbes where table_name='test'; --2、獲取使用者的預設表空間 select username, DEF
oracle表空間不足，相關查詢和處理
今天用PL SQL Developer往oracle資料庫中匯入資料時，突然報錯，只能終止，錯誤的具體內容如下：ORA-01653: unable to extend table BOSDATA.KSYS_RWYXRZ by 128 in tablespace 本報錯意思
ORA-臨時表空間不足
ORA-01652臨時表空間不足 最近使用ETL執行任務發現經常報一個“臨時表空間的問題”，根據公司業務摸索出了一些修改方案。 首先在網上搜索問題解決方案，看到絕大多數都是從重新分配臨時表空間或增加或清除。但由於環境原因導致不能輕易去更改分配的相關表空間大小。 另外，我
ORA-01950：對表空間“”XXXX”無權限，解決辦法
解決辦法 src sql ace 指定 dba 用戶 否則 space 上圖報錯 解決方案比如你要在用戶（或SCHEMA）usera中建表，那麽你用SYSTEM登錄ORACLE後，執行如下SQL ： ALTER USER 用戶名 QUOTA UNLIMITED ON 表空
ORA-01653 無法在表空間擴展的解決辦法 -- 增加表空間大小或給表空間增加數據文件
xid com 滿了 height log rod details 空閑 weight 轉自原文 ORA-01653 無法在表空間擴展的解決辦法 -- 增加表空間大小或給表空間增加數據文件 當前系統的數據量越來越大的，昨天還運行正常的數據庫，突然無法使用了。經過定位發現
Oracle表空間管理相關
自己 問題 出現 測試 方式 文件的 個數 數據字典 多個 以下以我自己的測試環境舉例：1.表空間的 block_size 為 8192字節，即8KBytes。從數據字典中查到 max_size 為 2147483645，即約為15.9TBytes。2.在創建表空間時，可以
TEMP表空間持續增高問題根結
WM_CONCAT函數 temp表空間高生產系統，業務反饋只要他們一跑某程序，就報TEMP表空間不足。我們的用戶在創建某表的時候，需要指定自己的臨時表空間，其他用戶均沒有問題，就這個用戶有問題。抓取數據庫內部等待事件，沒有temp相關的等待事件，先查一下temp表空間的利用率看看有沒有頭緒。SELECT d.
WRI$_ADV_OBJECTS表過大,導致PDB的SYSAUX表空間不足
idl execute 文檔 comm end inf build tor api 現象監控發現sysaux表空間使用不斷增加，導致表空間不足 查看過程 查看版本： SQL> select * from v$version; BANNER
oracle建立使用者，表空間，臨時表空間，分配許可權步驟詳解
首先登陸管理員賬號，或者有DBA許可權的使用者，接下來依次： --查詢所有使用者 select * from dba_users; --建立新使用者 create user gpmgt identified by GPMGT; --檢視所有使用者所在表空間 select usernam
檢視使用者表空間使用情況，擴容表空間語句
一、查看錶空間使用情況 SELECT SUM(bytes) / (1024 * 1024) AS free_space, tablespace_name FROM dba_free_space GROUP BY tablespace_name; SELECT a
oracle表空間不足擴容的方法
1、查詢當前使用者的所屬表空間 select * from user_users; 2、增加表空間有兩種方法： 以sysdba登陸進資料庫 語法： alter tablespace 表空間名稱 add datafile 表空間存放路徑 size
針對oracle資料庫表空間不足的問題
Oracle表空間不足的處理步驟 1.檢視所有表空間使用情況 select b.file_id 檔案ID號, b.tablespace_name 表空間名, b.bytes/1024/1024||'M'位元組數, (b.bytes-sum(nvl(a.bytes,
臨時表空間不足問題
今晚開發臨時拉我去定位一個數據庫問題，是臨時表空間不足的問題，主要是他們的sql存在clob大欄位排序把臨時表空間佔滿了且不釋放。 這種問題解決的最好辦法就是優化SQL，能把臨時表空間耗盡的sql明顯是存在很大的問題的。但目前臨時表空間不足已經影響到其他應用，所
oracle 表空間不足解決辦法大全
oracle表空間不足，一般有兩個原因：一，原表空間太小，沒有自增長；二，表空間已自增長，而且表空間也已足夠大，對於這兩種原因分別有各自的解決辦法。 【檢查原因】 1、查看錶在那個表空間 select tablespace_name,table_name from use
Oracle表空間不足的案例總結
1、問題描述： Creating procedure PRO_ALTER_TABLES =================================== CREATE OR REPLACE PROCEDURE PRO_ALTER_TABLES IS * ERROR a
oracle undo表空間不足的解決方法
資料庫大批量插入提交注意事項-undo： undo定義： UNDO 表空間用於存放UNDO資料,當執行DML操作(INSERT,UPDATE和DELETE)時,oracle會將這些操作的舊資料寫入到UNDO段滾段,還可以使用UNDO表空間.因為規劃和管理回滾段比較複雜,所
ora-01658 :無法為表空間USERS 中的段建立INITIAL區
"CREATE INDEX "IDX_TS_BONUS_Q_201209_DS" ON "TS_BONUS_Q_201209" ("DS" ) PCT" "FREE 10 INITRANS 2 MAXTRANS 255 STORAGE(INITIAL 3145728
Ubuntu16.04 將其他磁碟掛載到 /home， 解決/home空間不足
本文轉載自: https://blog.csdn.net/handsome_for_kill/article/details/52654724 1、檢視磁碟資訊 sudo fdisk -l 檢視分割槽的UUID命令： sudo blkid 根據這