茫茫網海中的冷日
         
茫茫網海中的冷日
發生過的事,不可能遺忘,只是想不起來而已!
 恭喜您是本站第 1671280 位訪客!  登入  | 註冊
主選單

Google 自訂搜尋

Goole 廣告

隨機相片
IMG_60D_00083.jpg

授權條款

使用者登入
使用者名稱:

密碼:


忘了密碼?

現在就註冊!

DB研討會 : [轉貼]oracle 表空間滿了排查和解決

發表者 討論內容
冷日
(冷日)
Webmaster
  • 註冊日: 2008/2/19
  • 來自:
  • 發表數: 15771
[轉貼]oracle 表空間滿了排查和解決

oracle 表空間滿了排查和解決(ORA-1653: unable to extend table test by 128 in tab)

users表空間異常佔滿處理

問題描述:

日常查詢數據庫alert日誌,發現報錯信息ORA-1653: unable to extend table AXJ_REDIS.USSD_UNREPORT_FAIL by 128 in tablespace USERS,users表空間已滿,無法擴展。

問題分析:

USERS表空間是默認用戶表空間,在創建一個用戶並沒有指定此用戶使用表空間時,該用戶所有信息都會放入到users表空間中,使用查詢表空間語句:select file_name,tablespace_name,bytes/1024/1024 "bytes MB",maxbytes/1024/1024 "maxbytes MB" from dba_data_files where tablespace_name='USERS'; 查詢users表空間,發現已佔滿 , 使用sql:select t.TABLE_NAME,t.NUM_ROWS from all_tables t where tablespace_name='USERS' order by num_rows desc;
查詢使用USERS表空間的表,按行級降序排序,發現多個表使用USERS表空間,存在大量數據導致USER表佔滿

問題處理:

1、擴展表空間:
alter datafile 『/oracle/oradata/dbaxj/users01.dbf』 resize 30G;
2、擴展到最大30G文件無法繼續擴展,可增加數據文件:alter tablespace users add datafile 'users02.dbf'
size 1024m autoextend on next 1024m maxsize 30G;
3、truncate刪除無用表釋放空間,假如未釋放,對TEST表進行收縮shrink,執行下面三個語句:
啟用行遷移:alter table TEST enable row movement;
shrink表test:alter TABLE TEST shrink SPACE;
關閉行遷移:alter table TEST DISABLE row movement;
註:數據被刪除後(無論是 delete 還是 truncate table),數據文件大小不會縮小, Oracle 「高水位」所致(可以具體瞭解),想要降低數據文件大小需降低高水位的正確做法是先降低HWM,再確定實際佔有大小,再resize數據文件,執行如下4個語句:
(1)查詢表空間文件編號:select file#, name from v$datafile;
(2)根據文件 ID 查詢這個數據文件最大數據塊(data block)的編號:select max(block_id) from dba_extents where file_id=4;
(3)計算該表空間實際佔用的空間,先查詢數據塊大小: select value from v$parameter where name='db_block_size',咱默認是8192.
(4)計算實際佔用磁盤大小: select 65673 * 8 / 1024 from dual;
(5)把數據文件大小resize到比實際佔用磁盤大小大一些就行了:
alter database datafile '/oracle/oradata/dbaxj/users01.dbf' resize 600m;
這樣數據文件大小就變小了,節約空間
4、需要使用的表,修改表空間alter table USSD_UNREPORT_FAIL move tablespace new_tablespace,建表時需養成習慣,指定好表空間



原文出處:oracle 表空间满了排查和解决(ORA-1653: unable to extend table test by 128 in tab) - 胡威的技术博客 - CSDN博客
冷日
(冷日)
Webmaster
  • 註冊日: 2008/2/19
  • 來自:
  • 發表數: 15771
[轉貼]Oracle 數據庫 1653 錯誤

Oracle數據庫 1653錯誤



無論是系統前台還是後台,錯誤提示都是ora-1653錯誤。

打開oracle數據庫的alter.log中出現如下錯誤,提示如下:

ORA-1653: unable to extend table dbtb.dbtb_LOG by 128 in ....


sqlplus 進入查看

SQL> select max(bytes)/1024/1024 from dba_free_space where tablespance_name='dbtb'

MAX(BYTES)/1024/1024
--------------------
.8125


果然只有很小的空間了。這個表空間主要是兩個系統之間交換的臨時數據,運行很長時間後已經撐爆了。

於是想到直接擴展:
SQL> alter database datafile 'D:\ORACLEDB\ORADATA\dbdb\EDI.DBF' resize 5G;
alter database datafile 'D:\ORACLEDB\ORADATA\dbdb\EDI.DBF' resize 5G
*
ERROR at line 1:
ORA-03297: 無法壓縮

仔細一看文件,原來已經40G了,看了還是單獨在新建一個:



SQL> alter TABLESPACE EDI add datafile 'D:\ORACLEDB\ORADATA\dbtb1.DBF' size 50M autoextend on nex
t 500m maxsize unlimited;
如果忘記設置自動擴展和增量,繼續:

SQL> alter database datafile 'D:\ORACLEDB\ORADATA\dbtb1.DBF' autoextend on ne
xt 500M maxsize unlimited;

Database altered.

再看alter.log OK



原文出處: Oracle数据库 1653错误 - 清风弄影 - CSDN博客
冷日
(冷日)
Webmaster
  • 註冊日: 2008/2/19
  • 來自:
  • 發表數: 15771
[轉貼]表擴展失敗(ORA-01653)後的空間管理問題

表擴展失敗(ORA-01653)後的空間管理問題【THE SPACE MANAGEMENT PROBLEM OF THE TABLE EXTEND FAILD 】

    這兩天在公司做ORACLE10G的DATAGUARD測試的時候,發現表擴展報錯後,後續的一些空間問題。
    測試環境中,建了一個500M的TABLESPACE命名為TEST。
    導入一張表(TEST_ALL)有280多萬的數據,然後建立了有建立了一個同樣結構的表TEST1,進行批量插入操作。
   
SQL> insert into test1 select * from test_all;

ORA-01653: unable to extend table TEST.TEST1 by 1024 in tablespace TEST
  
   這是個較為常見的錯誤,就是TABLESPACE沒有空間了。以下為ORACLE給出的錯誤解釋和解決方法。

// *Cause: Cannot shrink the segment because it is not in auto segment space
//       managed tablespace or it is not a data, index or lob segment.
// *Action: Check the tablespace and segment type and reissue the statement

 
   因為我的表空間沒有設置自動增長,所以會有錯誤報出。但是接下來的問題就很有意思了。我們發現雖然插入操作失敗,但是其所佔的空間並沒有自動收回!我的測試環境中,TEST1表一直佔用184M左右的表空間。並且無論我發ROLLBACK,COMMIT,關閉當前SESSION甚至重新啟動數據庫,這個TEST1表一直會佔用著184M的表空間!
   我只能手工TRUNCATE TABLE或者MOVE的方法來消減這張表佔用的空間。
   有意思的是,當我利用ORACLE10G的新方法來試圖回縮所佔用的空間時,ORACLE報錯並且錯的讓我「找不到北」。如下:
  
SQL> alter table test1 shrink space cascade;

alter table test1 shrink space cascade

ORA-10635: Invalid segment or tablespace type
  
   這個10635錯誤也是一個比較典型的錯誤,ORACLE給出的官方解釋:
  
// *Cause: Cannot shrink the segment because it is not in auto segment space
//         managed tablespace or it is not a data, index or lob segment.
// *Action: Check the tablespace and segment type and reissue the statement

    
    當時我以為自己沒有使用ORACLE的ASSM,但是經過確認自己建表空間的SQL,發現我使用的是ASSM的,但還是害怕有問題,對另外一張TEST_ALL的表進行操作,結果正常。
  
  
SQL> alter table test.test_all shrink space cascade;

Table altered

Executed in 10.859 seconds
   
      看上去ORACLE報的這個錯誤也「驢唇不對馬嘴」了。讓我已經久已不用的MOVE命令關鍵時刻還是有點作用的。
      這佔用的表空間只是會造成空間的浪費嗎,還是有其他副作用的。我先後做了兩個COUNT的SQL,其顯示的執行結果比較清楚的說明了這個問題。
    第一個COUNT的SQL是沒有執行TRUNCATE TABLE命令前的,如下


SQL> select count(*) from test1;

  COUNT(*)
----------
         0


Execution Plan
----------------------------------------------------------
Plan hash value: 3896847026

--------------------------------------------------------------------
| Id  | Operation          | Name  | Rows  | Cost (%CPU)| Time     |
--------------------------------------------------------------------
|   0 | SELECT STATEMENT   |       |     1 |  5135   (1)| 00:01:02 |
|   1 |  SORT AGGREGATE    |       |     1 |            |          |
|   2 |   TABLE ACCESS FULL| TEST1 |     1 |  5135   (1)| 00:01:02 |
--------------------------------------------------------------------

Note
-----
   - dynamic sampling used for this statement


Statistics
----------------------------------------------------------
          6  recursive calls
          2  db block gets
      
23641  consistent gets
          0  physical reads
        228  redo size
        410  bytes sent via SQL*Net to client
        385  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

      第二個COUNT的SQL是在執行MOVE TABLE後來完成的

SQL> select /*truncate*/count(*) from test1;

  COUNT(*)
----------
         0


Execution Plan
----------------------------------------------------------
Plan hash value: 3896847026

--------------------------------------------------------------------
| Id  | Operation          | Name  | Rows  | Cost (%CPU)| Time     |
--------------------------------------------------------------------
|   0 | SELECT STATEMENT   |       |     1 |     2   (0)| 00:00:01 |
|   1 |  SORT AGGREGATE    |       |     1 |            |          |
|   2 |   TABLE ACCESS FULL| TEST1 |     1 |     2   (0)| 00:00:01 |
--------------------------------------------------------------------

Note
-----
   - dynamic sampling used for this statement


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          
4  consistent gets
          0  physical reads
          0  redo size
        410  bytes sent via SQL*Net to client
        385  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed


      第二句要明顯好於第一句。性能上還有有差別的。即TEST1表的HWM是上升的。
      接下來另外一個問題就出現了:如果我可以繼續插入的話,空間佔用會持續增加嗎即HWM會持續增加嗎?如果是的話,這樣導致的性能問題就大了。然後我正常插入了32000條數據,空間佔用沒有變化。為了防止是因為空間限製造成空間佔用不增加,我調大了表空間到600M,結果相同。即空間佔用仍為184M。還好,ORACLE沒有犯錯誤。現在比較兩種情況。
    情況一:在不回縮空間佔用的情況下,執行COUNT(*)
  

SQL> SELECT /*320000*/ COUNT(*) FROM TEST1 WHERE OWNER='SYS';

  COUNT(*)
----------
    140216


Execution Plan
----------------------------------------------------------
Plan hash value: 3896847026

----------------------------------------------------------------------------
| Id  | Operation          | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |       |     1 |    17 |  5144   (1)| 00:01:02 |
|   1 |  SORT AGGREGATE    |       |     1 |    17 |            |          |
|*  2 |   TABLE ACCESS FULL| TEST1 |   158K|  
2628K|  5144   (1)| 00:01:02 |
----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("OWNER"='SYS')

Note
-----
   - dynamic sampling used for this statement


Statistics
----------------------------------------------------------
           6  recursive calls
          1  db block gets
       23639  consistent gets
          0  physical reads
         176  redo size

        413  bytes sent via SQL*Net to client
        385  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed
   
      第二種情況,先進行空間收縮,然後進行COUNT查詢。這次使用SHRINK操作,ORACLE沒有報錯。回縮後,TEST1表空間佔用31.8M
  

SQL> SELECT /*shrinked*/ count(*) from test1 where owner='SYS';

  COUNT(*)
----------
    140216


Execution Plan
----------------------------------------------------------
Plan hash value: 3896847026

----------------------------------------------------------------------------
| Id  | Operation          | Name  | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |       |     1 |    17 |   890   (2)| 00:00:11 |
|   1 |  SORT AGGREGATE    |       |     1 |    17 |            |          |
|*  2 |   TABLE ACCESS FULL| TEST1 |   137K|  
2288K|   890   (2)| 00:00:11 |
----------------------------------------------------------------------------

Predicate Information (identified by operation id):
---------------------------------------------------

   2 - filter("OWNER"='SYS')

Note
-----
   - dynamic sampling used for this statement


Statistics
----------------------------------------------------------
          0  recursive calls
          0  db block gets
       4008  consistent gets
          0  physical reads
           0  redo size

        413  bytes sent via SQL*Net to client
        385  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed


      不難發現性能上,第二句還是有非常大的優勢的。
  
      綜上所述
      如果我們在操作(INSERT)某個表,因為空間擴張失敗後,需要認真執行空間的回縮處理。雖然在我們看來,失敗了回滾即可。但是其HWM卻上去後就沒有下來。也許這是ORACLE在並發處理情況下要求快速相應的一種策略。但是也會留下性能憂患的伏筆。週期性的執行空間管理還是非常非常有必要的。
      但是對於ORACLE的SHRINK操作,只有對批量INSERT某個空表而造成空間擴展失敗後的表進行回縮時報ORA-10635錯來看,這應該是個BUG。(因為如果直接對某個空表或有原表中有些數據然後進行INSERT操作造成空間擴展失敗的表執行SHRINK操作都沒有問題)
  
    要多想些,再多想些 -:)

    --------------------系統環境
    OS: REDHAT AS4 U5
    ORACLE:10.2.0.1
   
    歡迎指正。
   
   

原文出處: 表扩展失败(ORA-01653)后的空间管理问题【THE SPACE MANAGEMENT PROBLEM OF THE TABLE EXTEND FAILD 】-Be the miracle!-51CTO博客
冷日
(冷日)
Webmaster
  • 註冊日: 2008/2/19
  • 來自:
  • 發表數: 15771
[轉貼]手工建庫後表空間數據文件非自動擴展引起的錯誤
手工建庫後表空間數據文件非自動擴展引起的錯誤:ORA-01653: una

手工建庫時,未將表空間數據文件設置為自動擴展引起的錯誤:ORA-01653: unable to extend * in tablespace * 的解決:

查看數據庫alert日誌文件時,發現出現大量如下的錯誤:
Sun Dec 01 10:00:42 2013
ORA-1653: unable to extend table SYS.SCHEDULER$_EVENT_LOG by 8 in tablespace SYSAUX
Errors in file /u01/app/Oracle/product/11.2.0/dbhome_1/log/diag/rdbms/bys3/bys3/trace/bys3_j000_15569.trc:
ORA-01653: unable to extend table . by in tablespace
ORA-01653: unable to extend table SYS.SCHEDULER$_EVENT_LOG by 8 in tablespace SYSAUX
Sun Dec 01 11:00:27 2013
ORA-1653: unable to extend table SYS.WRI$_ADV_PARAMETERS by 128 in tablespace SYSAUX
Sun Dec 01 12:00:32 2013
ORA-1653: unable to extend table SYS.WRI$_ADV_PARAMETERS by 128 in tablespace SYSAUX
Sun Dec 01 13:00:36 2013
ORA-1653: unable to extend table SYS.WRI$_ADV_PARAMETERS by 128 in tablespace SYSAUX
Sun Dec 01 14:00:40 2013
ORA-1653: unable to extend table SYS.SCHEDULER$_EVENT_LOG by 8 in tablespace SYSAUX
ORA-1653: unable to extend table SYS.SCHEDULER$_EVENT_LOG by 8 in tablespace SYSAUX
Sun Dec 01 14:00:41 2013
ORA-1653: unable to extend table SYS.WRI$_ADV_PARAMETERS by 128 in tablespace SYSAUX
Sun Dec 01 15:00:45 2013
ORA-1653: unable to extend table SYS.WRH$_IOSTAT_FILETYPE by 8 in tablespace SYSAUX
MMON Flush encountered SYSAUX out of space error(1653).
MMON (emergency) purge of WR snapshots (188) and older
Sun Dec 01 15:00:49 2013


從報錯信息可以很直觀的看出:

SYSAUX表空間中的表無法擴展,原因一般為:數據文件空間不足且未設置autoextend on屬性或者用戶磁盤限額不足導致用戶的表無法擴展。
驗證數據文件使用率及屬性如下:
SYS@ bys3>col file_name for a40
SYS@ bys3>select file_name,autoextensible,increment_by from dba_data_files; --查數據文件是否設置autoextend on屬性要從 dba_data_files 查
FILE_NAME AUT INCREMENT_BY
---------------------------------------- --- ------------
/u01/oradata/bys3/system01.dbf NO 0
/u01/oradata/bys3/sysaux01.dbf NO 0
/u01/oradata/bys3/undotbs01.dbf NO 0
/u01/oradata/bys3/user01.dbf NO 0
SYS@ bys3>select TABLESPACE_NAME,sum(bytes/1024/1024) from dba_free_space group by tablespace_name; 通過這語句查各表空間使用率,因SYSAUX沒有FREE SPACE,在這沒顯示。
TABLESPACE_NAME SUM(BYTES/1024/1024)
------------------------------ --------------------
UNDOTBS1 58.0625
USERS 48.6875
SYSTEM 155.375


確定問題後,解決方法:將sysaux表空間的數據文件屬性改為自動擴展 autoextend on
SYS@ bys3>alter tablespace sysaux autoextend on; ---此語句只能修改大文件表空間時使用。
alter tablespace sysaux autoextend on
*
ERROR at line 1:
ORA-32773: operation not supported for smallfile tablespace SYSAUX

SYS@ bys3>alter database datafile '/u01/oradata/bys3/sysaux01.dbf' autoextend on; --使用此語句修改數據文件的屬性
Database altered.
SYS@ bys3>select file_name,autoextensible,increment_by from dba_data_files; ---修改後查詢數據文件屬性,已經更改為autoextend on
FILE_NAME AUT INCREMENT_BY
---------------------------------------- --- ------------
/u01/oradata/bys3/system01.dbf NO 0
/u01/oradata/bys3/sysaux01.dbf YES 1
/u01/oradata/bys3/undotbs01.dbf NO 0
/u01/oradata/bys3/user01.dbf NO 0
SYS@ bys3>select TABLESPACE_NAME,sum(bytes/1024/1024) free_mb from dba_free_space group by tablespace_name; --修改後查詢表空間剩余,SYSAUX已經自動擴展了一個區--64K. 詳見:http://blog.csdn.net/q947817003/article/details/11370881
TABLESPACE_NAME FREE_MB
------------------------------ ----------
SYSAUX .0625 ---這裏即擴展了一個extent,
UNDOTBS1 58.0625
USERS 48.6875
SYSTEM 155.375


到這裏,問題就已經得到解決!

可以將SYSTEM及user表空間的數據文件都設置為autoextend on
SYS@ bys3>alter database datafile '/u01/oradata/bys3/system01.dbf' autoextend on;
Database altered.
SYS@ bys3>alter database datafile '/u01/oradata/bys3/user01.dbf' autoextend on;
Database altered.
SYS@ bys3>select file_name,bytes/1024/1024 total_MB,user_bytes/1024/1024 user_mb,AUTOEXTENSIBLE from dba_data_files;
FILE_NAME TOTAL_MB USER_MB AUT
---------------------------------------- ---------- ---------- ---
/u01/oradata/bys3/system01.dbf 500 499 YES
/u01/oradata/bys3/sysaux01.dbf 325 324 YES
/u01/oradata/bys3/undotbs01.dbf 200 199 NO
/u01/oradata/bys3/user01.dbf 50 49 YES


原文出處: 手工建庫後表空間數據文件非自動擴展引起的錯誤:ORA-01653: una - IT閱讀
冷日
(冷日)
Webmaster
  • 註冊日: 2008/2/19
  • 來自:
  • 發表數: 15771
[轉貼]冷日總結一下技巧
冷日總結一下小技巧

檢查表空間:
SELECT * FROM dba_data_files WHERE TABLESPACE_NAME='APPS_TS_TX_DATA';

將原有表空間擴充檔案上限:
alter tablespace APPS_TS_TX_DATA datafile '/u01/install/APPS/data/a_txn_data01.dbf' RESIZE 10G;

新增表空間檔案:
alter tablespace APPS_TS_TX_DATA add datafile  'a_txn_data05.dbf' size 1024m autoextend on next 1024m maxsize 10G;

擴展原有表空間檔案容量上限:
alter database datafile '/u01/install/APPS/data/a_txn_data01.dbf' autoextend on next 1024m maxsize 10G;
alter database datafile '/u01/install/APPS/data/a_txn_data02.dbf' autoextend on next 1024m maxsize 10G;
alter database datafile '/u01/install/APPS/data/a_txn_data03.dbf' autoextend on next 1024m maxsize 10G;
alter database datafile '/u01/install/APPS/data/a_txn_data04.dbf' autoextend on next 1024m maxsize 10G;
alter database datafile '/u01/install/APPS/data/a_txn_data05.dbf' autoextend on next 1024m maxsize 10G;

查找表空間檔案位置:
locate a_txn_data05.dbf

查詢現在已經存在的表空間檔案:
ls -alsph /u01/install/APPS/data/a_txn_data* |more
4.0G -rw-r----- 1 oracle oinstall 4.0G Apr 12 15:32 /u01/install/APPS/data/a_txn_data01.dbf
4.0G -rw-r----- 1 oracle oinstall 4.0G Apr 12 15:32 /u01/install/APPS/data/a_txn_data02.dbf
4.0G -rw-r----- 1 oracle oinstall 4.0G Apr 12 15:32 /u01/install/APPS/data/a_txn_data03.dbf
4.0G -rw-r----- 1 oracle oinstall 4.0G Apr 12 15:22 /u01/install/APPS/data/a_txn_data04.dbf

檢查現在磁碟使用況況:
df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg_ebsdb-lv_root
                       50G   11G   37G  22% /
tmpfs                  63G   16M   63G   1% /dev/shm
/dev/sda1             477M  164M  284M  37% /boot
/dev/mapper/vg_ebsdb-lv_home
                      1.1T  179G  814G  18% /u01
ebssoa.foxport.cn:/u01/ebsdb_backup
                     1019G  211G  756G  22% /u01/ebsdb_backup
192.168.3.1:/volume3/LinuxBackup
                      9.4T  2.0T  7.5T  21% /home/linuxBackupFolder

如何移動表空間:
ALTER TABLE TABLE_NAME MOVE TABLESPACE_NAME;

如何將索引移動表空間:
ALTER INDEX INDEX_NAME REBUILD TABLESPACE TABLESPACE_NAME;

如何查看各個表空間佔用磁盤情況?
SQL> col tablespace format a20
SQL> select
b.file_id 文件ID號,
b.tablespace_name 表空間名,
b.bytes 字節數,
(b.bytes-sum(nvl(a.bytes,0))) 已使用,
sum(nvl(a.bytes,0)) 剩餘空間,
sum(nvl(a.bytes,0))/(b.bytes)*100 剩餘百分比
from dba_free_space a,dba_data_files b
where a.file_id=b.file_id
group by b.tablespace_name,b.file_id,b.bytes
order by b.file_id

如何知道數據褲中某個表所在的tablespace?
select tablespace_name from user_tables where table_name='TEST';
select * from user_tables中有個字段TABLESPACE_NAME,(oracle);
select * from dba_segments where …;

怎麼可以看到數據庫有多少個tablespace?
select * from dba_tablespaces;

如何查看數據文件放置的路徑?
col file_name format a50
select tablespace_name,file_id,bytes/1024/1024,file_name from dba_data_files order by file_id;

如何查看現有回滾段及其狀態?
SQL> col segment format a30
SQL> SELECT SEGMENT_NAME,OWNER,TABLESPACE_NAME,SEGMENT_ID,FILE_ID,STATUS FROM DBA_ROLLBACK_SEGS

如何知道表在表空間中的存儲情況?
select segment_name,sum(bytes),count(*) ext_quan from dba_extents where
tablespace_name='&tablespace_name' and segment_type='TABLE' group by tablespace_name,segment_nam;

前一個主題 | 下一個主題 | 頁首 | | |



Powered by XOOPS 2.0 © 2001-2008 The XOOPS Project|