`
DangDang0701
  • 浏览: 78100 次
  • 性别: Icon_minigender_2
  • 来自: 大连
社区版块
存档分类
最新评论

TUNCATE,DELETE 大汇总

阅读更多

代码部门又出问题了,上次是页面查询响应很慢,这次是页面更新速度很慢,开发人员提交了SQL语句到我这里,
看了一下,这个语句非常简单,update tbl set ... = ... where mobile=..and sp_id=..,他影响的只有一行,这个
语句能慢????
    我在现场数据库中手工执行了这个语句,大概需要3分钟,影响行数:1,马上断定:表数据量庞大,定位这一行
使用了FULL SCAN,于是建议他们在关键字段建立索引,结果开发人员告诉我这个表只有2000多条记录,没必要建立索引,
有点不大相信,看下数据先,select count(*),大概花了4分钟,数据量:2087,晕死,2087行的表,我选个总数用了
4分钟,你ORACLE干什么吃的???
     思考中。。。
     查看数据库的锁定情况,在这个表上并没有TX或TM类型的锁,看来不是事务阻塞了,那为什么出现这种奇怪的事情呢?
生成了一个statspack性能报告,这条更新语句是名列前茅,够强哦,逻辑读有2万多次,真是晕了
     思考中。。。
     干脆分析下这个UPDATE语句,看看查询计划究竟做了什么
    
     set autotrace on
    
     的确是走的全表扫描,有两个地方引起了我的注意,其实这个在statspack报告中就可以看出来,逻辑读是2万多次,
物理读2万多次,进行了很多物理IO,速度下降是肯定的,但怎么会有这么多的物理IO呢?难道这个表真的有2万多个数据块?
查看下先,select blocks from user_segments where segment_name = 'tbl',果然,258333个数据块,每个数据块是8K,
这样每次UPDATE需要扫描近200M的空间,并且这些空间中99.999999%的是空闲的,难怪更新这么慢,于是和他们工程部的
人协商,暂时停掉操作页面,然后我将表数据备份到一张临时表,truncate原表,在将数据导入,启动页面,马上更新快
起来了,查看表数据块,由原来的258333变成了20,现在表只有160K

    这个问题的解决涉及到ORACLE的空间管理,在ORACLE的表上存在着高水位标记(HWM),他是一个分界线,当扫描
表时,ORACLE只会扫描位于HWM以下的数据块(不考虑回滚段中的数据前映象),随着表数据量的不断增加,需要的自由块
就越多,当表需要自由块时,会在表本身的自由列表freelist里面去定位,随着数据块上数据的增加,到某种程度时这个数据块
就会在freelist中失去他的记载(由pctfree决定)如果freelist中已经没有空闲块,则提高HWM,容纳更多的自由块
到freelist中,当表的数据块上的内容被删除时,就有了空间,他们又会回到自由列表中(PCTUSE指定什么时候该回去),
这个过程循环进行,HWM会被渐渐抬高,当表的数据被DELETE掉时,数据没了,数据块都返还到freelist了,但此时HWM并没有
下去,或者他只是下去了一点点,这样扫描表时,可能你的记录是0,但HWM下的数据块却很庞大,就会产生大量的空块读取,
使表的HWM下降的方法是TRUNCATE表或是删除重建,或是ALTER TABLE TBL MOVE TABLESPACE ANOTHER_SPACE,另外ASSM表空间
管理模式可能很少出现这种情况,我这里采用的是TRUNCATE的方法,比较笨拙,事后询问了他们工程部的人,这个表以前有好
几百万的数据,后来清除了许多,现场表他们清除是不敢用TRUNCATE的,所以原因是在清楚不过了,下面我们通过实验来证实
我的说法,创建一个大表,选择出其记录总数,看看花多长时间,然后DELETE表后再选择记录数看花多长时间,最后TRUNCATE
表再选择,看花多长时间
--创建mytest表
SQL> create table mytest nologging as select * from duizhang_toboss;
Table created

SQL> set timing on --显示消耗时间
SQL> select count(*) from mytest; --记录数12522708,耗时19秒,已经不小拉

  COUNT(*)
----------
  12522708

Executed in 19 seconds

SQL> delete from mytest;  --删除表的所有数据,这个过程太长了,涉及到回滚数据的创建,库也不是我一个人在折腾

12522708 rows deleted

Executed in 903.031 seconds

SQL> commit; --提交变更

Commit complete

Executed in 0 seconds

SQL> select count(*) from mytest; --表已经空了,但没有想象中快速完成查询,用时57秒,这不大正常,但证明HWM确实没有下去,在执行不必要的空块读取

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

Executed in 57.046 seconds

SQL> truncate table mytest; --TUNCATE重置HWM,扫描数据块大大降低,很快过去

Table truncated

Executed in 0.406 seconds

现在大家应该明白其中的来龙去脉了吧,大家看到,DELETE对HWM基本没起什么作用,TRUNCATE才降低了水位,这就是为什么同是
空表,扫描时间却大不相同的原因了,就写到这里,头又叫我了,呵呵!!!!!


222222222222222222222222222
深入了解oracle的高水位(HWM)

ORACLE在逻辑存储上分4个粒度:表空间,段,区和块.

(1)块:是粒度最小的存储单位,现在标准的块大小是8K,ORACLE每一次I/O操作也是按块来操作的,也就是说当ORACLE从数据文件读数据时,是读取多少个块,而不是多少行.

(2)区:由一系列相邻的块而组成,这也是ORACLE空间分配的基本单位,举个例子来说,当创建一个表PM_USER时,首先ORACLE会分配一区的空间给这个表,随着不断的INSERT数据到PM_USER,原来的这个区容不下插入的数据时,ORACLE是以区为单位进行扩展的,也就是说再分配多少个区给PM_USER,而不是多少个块.

(3)段:是由一系列的区所组成,一般来说,当创建一个对象时(表,索引),就会分配一个段给这个对象.所以从某种意义上来说,段就是某种特定的数据.如CREATE TABLE PM_USER,这个段就是数据段,而CREATE INDEX ON PM_USER(NAME),ORACLE同样会分配一个段给这个索引,但这是一个索引段了.查询段的信息可以通过数据字典: SELECT * FROM USER_SEGMENTS来获得,

(4)表空间:包含段,区及块.表空间的数据物理上储存在其所在的数据文件中.一个数据库至少要有一个表空间.

OK,现在回到HWM上来,那么,什么是高水位标记呢?这就跟ORACLE的段空间管理相关了.

(一)ORACLE用HWM来界定一个段中使用的块和未使用的块.

举个例子来说,当创建一个表:PT_SCHE_DETAIL时,ORACLE就会为这个对象分配一个段.在这个段中,即使未插入任何记录,也至少有一个区被分配,第一个区的第一个块就称为段头(SEGMENT HEADE),段头中就储存了一些信息,基中HWM的信息就存储在此.此时,因为第一个区的第一块用于存储段头的一些信息,虽然没有存储任何实际的记录,但也算是被使用,此时HWM是位于第2个块.当不断插入数据到PM_USER后,第1个块已经放不下后面新插入的数据,此时,ORACLE将高水位之上的块用于存储新增数据,同时,HWM本身也向上移.也就是说,当不断插入数据时,HWM会往不断上移,这样,在HWM之下的,就表示使用过的块,HWM之上的就表示已分配但从未使用过的块.

(二)HWM在插入数据时,当现有空间不足而进行空间的扩展时会向上移,但删除数据时不会往下移.

这就好比是水库的水位,当涨水时,水位往上移,当水退出后,最高水位的痕迹还是清淅可见.

考虑让看一个段,如一张表,其中填满了块,。在正常操作过程中,删除了一些行。现有就有了许多浪费的空间:

ORACLE 不会释放空间以供其他对象使用,有一条简单的理由:由于空间是为新插入的行保留的,并且要适应现有行的增长。被占用的最高空间称为最高使用标记 (HWM)

(三)HWM的信息存储在段头当中.

HWM本身的信息是储存在段头.在段空间是手工管理方式时,ORACLE是通过FREELIST(一个单向链表)来管理段内的空间分配.在段空间是自动管理方式时(ASSM),ORACLE是通过BITMAP来管理段内的空间分配.

(四)ORACLE的全表扫描是读取高水位标记(HWM)以下的所有块.

所以问题就产生了(一直不解为何ORACLE会采用这种不合理的方式).当用户发出一个全表扫描时,ORACLE 始终必须从段一直扫描到 HWM,即使它什么也没有发现。该任务延长了全表扫描的时间。

(五)当用直接路径插入行时 — 例如,通过直接加载插入(用 APPEND 提示插入)或通过 SQL*LOADER 直接路径 — 数据块直接置于 HWM 之上。它下面的空间就浪费掉了。

来分析这两个问题,后者只是带来空间的浪费,但前者不仅是空间的浪费,而且会带来严重的性能问题.来看看下面的例子:

(A)先来搭建测试的环境(172.17.8.202,Linux,ORACLE 版本:1002000100),第一步先创建一个段空间为手工管理的表空间:

CREATE TABLESPACE "SEC"
LOGGING
DATAFILE '/u01/app/oracle/oradata/TSH1/SEC.DBF' SIZE 5M
AUTOEXTEND
ON NEXT 10M MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL
SEGMENT SPACE MANAGEMENT MANUAL;

(B)创建一个表,注意,此表的第二个字段设成是CHAR(100),以让此表在插入1千万条记录后,空间有足够大:

CREATE TABLE TEST_TAB(C1 NUMBER(10),C2 CHAR(100)) TABLESPACE SEC;

插入记录
DECLARE
I NUMBER(10);
BEGIN
FOR I IN 1..10000000 LOOP
INSERT INTO TEST_TAB VALUES(I,'TESTSTRING');
END LOOP;
COMMIT;
END ;
/

使用了1.3G的表空间,好大!

(C)来查询一下,看在插入一千万条记录后所访问的块数和查询所用时间:

conn /as sysdba
SET TIMING ON
SET AUTOTRACE TRACEONLY
SELECT COUNT(*) FROM sec.TEST_TAB;

SQL> SELECT COUNT(*) FROM sec.TEST_TAB;

Elapsed: 00:01:36.04

Execution Plan
----------------------------------------------------------
Plan hash value: 2778628632

-----------------------------------------------------------------------
| Id  | Operation          | Name     | Rows  | Cost (%CPU)| Time     |
-----------------------------------------------------------------------
|   0 | SELECT STATEMENT   |          |     1 | 34513   (2)| 00:06:55 |
|   1 |  SORT AGGREGATE    |          |     1 |            |          |
|   2 |   TABLE ACCESS FULL| TEST_TAB |    10M| 34513   (2)| 00:06:55 |
-----------------------------------------------------------------------

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


Statistics
----------------------------------------------------------
          5  recursive calls
          0  db block gets
     312025  consistent gets
     154253  physical reads
   11233336  redo size
        411  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

这句SQL总供耗时是:1分36秒.访问方式是采用全表扫描方式(FTS),逻辑读了 312025 个BLOCK,物理读了 154253 个BLOCK.

来分析一下这个表:

BEGIN
DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=> 'SEC',
TABNAME=> 'TEST_TAB',
PARTNAME=> NULL);END;
/

PL/SQL procedure successfully completed.

Elapsed: 00:01:58.63


SQL> select NUM_ROWS,BLOCKS,EMPTY_BLOCKS from dba_tables where table_name = 'TEST_TAB';

  NUM_ROWS     BLOCKS EMPTY_BLOCKS
---------- ---------- ------------
  10004718     156011            0

发现这个表目前使用的BLOCK有: 156011,未使用的BLOCK(EMPTY_BLOCKS)为:0,总行数为(NUM_ROWS):10004718

再查询一下结果:
SQL> SELECT COUNT(*) FROM sec.TEST_TAB;

Elapsed: 00:00:40.67

Execution Plan
----------------------------------------------------------
Plan hash value: 2778628632

-----------------------------------------------------------------------
| Id  | Operation          | Name     | Rows  | Cost (%CPU)| Time     |
-----------------------------------------------------------------------
|   0 | SELECT STATEMENT   |          |     1 | 34500   (2)| 00:06:54 |
|   1 |  SORT AGGREGATE    |          |     1 |            |          |
|   2 |   TABLE ACCESS FULL| TEST_TAB |    10M| 34500   (2)| 00:06:54 |
-----------------------------------------------------------------------


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
     156034  consistent gets
     152544  physical reads
          0  redo size
        411  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

这句SQL总供耗时是:40秒.访问方式是采用全表扫描方式(FTS),逻辑读了 156034 个BLOCK,物理读了 152544 个BLOCK.

(D)接下来把此表的记录用DELETE方式删掉,然后再来看看SELECT COUNT(*) FROM TEST_TAB所花的时间:

SQL> DELETE FROM sec.test_tab;

10000000 rows deleted.

Elapsed: 00:10:22.64



SQL> SET AUTOTRACE TRACEONLY
SQL> SELECT COUNT(*) FROM sec.TEST_TAB;

Elapsed: 00:01:32.12

Execution Plan
----------------------------------------------------------
Plan hash value: 2778628632

-----------------------------------------------------------------------
| Id  | Operation          | Name     | Rows  | Cost (%CPU)| Time     |
-----------------------------------------------------------------------
|   0 | SELECT STATEMENT   |          |     1 | 34500   (2)| 00:06:54 |
|   1 |  SORT AGGREGATE    |          |     1 |            |          |
|   2 |   TABLE ACCESS FULL| TEST_TAB |    10M| 34500   (2)| 00:06:54 |
-----------------------------------------------------------------------


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
     156034  consistent gets
     154379  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


在DELETE表后,此时表中已没有一条记录,为什么SELECT COUNT(*) FROMTEST_TAB花的时间为1分4秒,反而比有记录稍微长点,这是为什么呢?而且,其逻辑读了156310个BLOCK,跟之前有一千万行记录时差不多,ORACLE怎么会这么笨啊?在DELETE表后再次分析表,看看有什么变化:这时, TEST_TAB表目前使用的BLOCK是: 156532,未使用的BLOCK(EMPTY_BLOCKS)为:0,总行数为(NUM_ROWS)已变成:0 为什么表目前使的BLOCK数还是156532呢?问题的根源就在于ORACLE的HWM.也就是说,在新增记录时,HWM会慢慢往上移,但是在删除记录后,HWM却不会往下移,也就是说,DELETE一千万条记录后,此表的HWM根本没移动,还在原来的那个位置,所以,HWM以下的块数同样也是一样的.ORACLE的全表扫描是读取ORACLE高水位标记下的所有BLOCK,也就是说,不管HWM下的BLOCK现在实际有没有存放数据,ORACLE都会一一读取,这样,大家可想而知,在DELETE表后,ORACLE读了大量的空块,耗去了大量的时间.再来看DELETE表后段空间实际使用的状况:

VAR TOTAL_BLOCKS NUMBER
VAR TOTAL_BYTES NUMBER
VAR UNUSED_BLOCKS NUMBER
VAR UNUSED_BYTES NUMBER
VAR LAST_USED_EXTENT_FILE_ID NUMBER
VAR LAST_USED_EXTENT_BLOCK_ID NUMBER
VAR LAST_USED_BLOCK NUMBER
EXEC DBMS_SPACE.UNUSED_SPACE('SEC','TEST_TAB','TABLE',:TOTAL_BLOCKS,:TOTAL_BYTES,:UNUSED_BLOCKS,:UNUSED_BYTES,:LAST_USED_EXTENT_FILE_ID,:LAST_USED_EXTENT_BLOCK_ID,:LAST_USED_BLOCK);
PRINT TOTAL_BLOCKS
PRINT TOTAL_BYTES
PRINT UNUSED_BLOCKS
PRINT UNUSED_BYTES
PRINT LAST_USED_EXTENT_FILE_ID
PRINT LAST_USED_EXTENT_BLOCK_ID
PRINT LAST_USED_BLOCK

输出结果为:
TOTAL_BLOCKS                            ------------    156544     --总共164352块
TOTAL_BYTES                                ------------    1282408448
UNUSED_BLOCKS                            ------------    532        --有7168块没有用过,也就是在HWM上面的块数
UNUSED_BYTES                            ------------    4358144
LAST_USED_EXTENT_FILE_ID    ------------    6
LAST_USED_EXTENT_BLOCK_ID    ------------    148489     --- BLOCK ID 是针对数据文件来编号的,表示最后使用的一个EXTENT的第一个BLOCK的编号
LAST_USED_BLOCK                        ------------    7660       ---在最后使用的一个EXTENT 中一共用了1024块

总共用了164352块,除了一个SEGMENT HEADER,实际总共用了164351个块,有7168块从来没有使用过。LAST USED BLOCK表示在最后一个使用的EXTENT 中使用的BLOCK, 结合 LAST USED EXT BLOCK ID可以计算 HWM 位置 :LAST USED EXT BLOCK ID + LAST USED BLOCK -1 = HWM 所在的数据文件的BLOCK编号代入得出: 158856+1024-1=159879,这个就是HWM所有的BLOCK编号HWM所在的块:TOTAL BLOCKS- UNUSED BLOCKS=164352-7168=157184,也就是说,HWM在第157184个块,其BLOCKID是159879

(E)接下来,再做几个试验:

第一步:执行ALTER TABLE sec.TEST_TAB DEALLOCATE UNUSED; 看看段空间的使用状况:

TOTAL_BLOCKS              ------------  156016        157184       
TOTAL_BYTES               ------------  1278083072    1287651328   
UNUSED_BLOCKS             ------------  4             0            
UNUSED_BYTES              ------------  32768         0            
LAST_USED_EXTENT_FILE_ID  ------------  6             9            
LAST_USED_EXTENT_BLOCK_ID ------------  148489        158856       
LAST_USED_BLOCK           ------------  7660          1024         


此时再代入上面的公式,算出HWM的位置: 157184-0=157184 HWM所在的BLOCKID是158856+1024-1=159879,跟刚刚的没有变化,也就是说执行ALTER TABLETEST_TAB DEALLOCATE UNUSED后,段的高水位标记的位置没有改变,但是看UNUSED BLOCKS变为0了,总的块数减少到157184,这证明,DEALLOCATE UNUSED为释放HWM上面的未使用空间,但是并不会释放HWM下面的自由空间,也不会移动HWM的位置.

第二步:再来看看执行ALTER TABLE sec.TEST_TAB MOVE;后段空间的使用状况:

TOTAL_BLOCKS              ------------  8        8         
TOTAL_BYTES               ------------  65536    65536     
UNUSED_BLOCKS             ------------  7        5         
UNUSED_BYTES              ------------  57344    40960     
LAST_USED_EXTENT_FILE_ID  ------------  6        9         
LAST_USED_EXTENT_BLOCK_ID ------------  9        2632      
LAST_USED_BLOCK           ------------  1        3         


此时,总共用到的块数已变为8, 再代入上面的公式,算出HWM的位置: 8-5=3HWM所在的BLOCK ID是2632+3-1=2634,OK,发现,此时HWM的位置已经发生变化,现在HWM的位置是在第3个BLOCK,其BLOCK ID是2634,所有数据文件的ID是9(这个没有发生变化,数据文件还是原来的那个数据文件,只是释放了原来的自由空间),最后使用的块数也变为3,也就是说已经使用了3块,HWM就是在最后一个使用的块上,即第3个块上.大家可能会觉得奇怪,为什么释放空间后,未使用的块还有5个啊?也就是说HWM之上还是有5个已分配但从未使用的块.答案就跟HWM移动的规律有关.当在插入数据时,ORACLE首先在HWM之下的块当中定位自由空间(通过自由列表FREELIST),如果FREELIST当中没有自由块了,ORACLE就开始往上扩展,而HWM也跟着往上移,每5块移动一次.来看ORACLE的说明:

The high water mark is:
-Recorded in the segment header block
-Set to the beginning of the segment on the creation
-Incremented in five-block increments as rows are inserted
-Reset by the truncate command
-Never reset by the delete command
-Space above the high-water-mark can be reclaimed at the table level by
using the following command:
ALTER TABLE DEALLOCATE UNUSED…

再来看看:SELECT COUNT(*) FROM TEST_TAB所花的时间:

SQL> SET AUTOTRACE TRACEONLY
SQL>SELECT COUNT(*) FROM sec.TEST_TAB;

Elapsed: 00:00:00.06

Execution Plan
----------------------------------------------------------
Plan hash value: 2778628632

-----------------------------------------------------------------------
| Id  | Operation          | Name     | Rows  | Cost (%CPU)| Time     |
-----------------------------------------------------------------------
|   0 | SELECT STATEMENT   |          |     1 | 34500   (2)| 00:06:54 |
|   1 |  SORT AGGREGATE    |          |     1 |            |          |
|   2 |   TABLE ACCESS FULL| TEST_TAB |    10M| 34500   (2)| 00:06:54 |
-----------------------------------------------------------------------


Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
          3  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

很快,不到1秒.
最后再来对表作一次分析, 此时这个表目前使用的BLOCK为: 0,未使用的BLOCK(EMPTY_BLOCKS)为:0,总行数为(NUM_ROWS):0从中也可以发现,分析表和SHOW_SPACE显示的数据有点不一致.那么哪个是准的呢?其实这两个都是准的,只不过计算的方法有点不同.事实上,当你创建了一个对象如表以后,不管你有没有插入数据,它都会占用一些块,ORACLE也会给它分配必要的空间.同样,用ALTER TABLE MOVE释放自由空间后,还是保留了一些空间给这个表.最后,再来执行TRUNCATE命令,截断这个表,看看段空间的使用状况:

SQL> truncate table sec.test_tab;

TOTAL_BLOCKS              ------------  8        8         
TOTAL_BYTES               ------------  65536    65536     
UNUSED_BLOCKS             ------------  7        5         
UNUSED_BYTES              ------------  57344    40960     
LAST_USED_EXTENT_FILE_ID  ------------  6        9         
LAST_USED_EXTENT_BLOCK_ID ------------  9        2632      
LAST_USED_BLOCK           ------------  1        3         

发现TRUNCATE后和MOVE没有什么变化.为了最终验证一下我上面的观点,我再DROP一下表,然后新建这个表,看看这时在没有插入任何数据之前,是否ORACLE确实有给这个对象分配必要的空间:

DROP TABLE sec.TEST_TAB;
CREATE TABLE sec.TEST_TAB(C1 NUMBER(10),C2 CHAR(100)) TABLESPACE SEC;

TOTAL_BLOCKS              ------------  8        8      
TOTAL_BYTES               ------------  65536    65536 
UNUSED_BLOCKS             ------------  7        5     
UNUSED_BYTES              ------------  57344    40960 
LAST_USED_EXTENT_FILE_ID  ------------  6        9     
LAST_USED_EXTENT_BLOCK_ID ------------  17       2112  
LAST_USED_BLOCK           ------------  1        3     

,即使我没有插入任何一行记录,ORACLE还是给它分配了8个块.当然这个跟建表语句的INITIAL 参数及MINEXTENTS参数有关:请看TEST_TAB的存储参数:

STORAGE
(
INITIAL 64K
MINEXTENTS 1
MAXEXTENTS UNLIMITED
);

也就是说,在这个对象创建以后,ORACLE至少给它分配一个区,初始大小是64K,一个标准块的大小是8K,刚好是8个BLOCK.

总结:

在9I中:
(1)如果MINEXTENT 可以使ALTER TABLE TABLENAME DEALLOCATE UNUSED将HWM以上所有没使用的空间释放
(2)如果MINEXTENT >HWM 则释放MINEXTENTS 以上的空间。如果要释放HWM以上的空间则使用KEEP 0。
        ALTER TABLE TABLESNAME DEALLOCATE UNUSED KEEP 0;
(3) TRUNCATE TABLE DROP STORAGE(缺省值)命令可以将MINEXTENT 之上的空间完全释放(交还给操作系统),并且重置HWM。
(4)如果仅是要移动HWM,而不想让表长时间锁住,可以用TRUNCATE TABLE REUSESTORAGE,仅将HWM重置。
(5)ALTER TABLE MOVE会将HWM移动,但在MOVE时需要双倍的表空间,而且如果表上有索引的话,需要重构索引
(6)DELETE表不会重置HWM,也不会释放自由的空间(也就是说DELETE空出来的空间只能给对象本身将来的INSERT/UPDATE使用,不能给其它的对象使用)

在ORACLE 10G:
(1)可以使用ALTER TABLE TEST_TAB SHRINK SPACE命令来联机移动HWM
(2)如果要同时压缩表的索引,可以发布:ALTER TABLE TEST_TAB SHRINK SPACE CASCADE

分享到:
评论

相关推荐

    Tripple Farm:Match 3 Combination Game Complete Project 合成小镇三消Unity合成消除游戏项目游戏插件模版C#

    Tripple Farm:Match 3 Combination Game Complete Project 合成小镇三消Unity合成消除游戏项目游戏插件模版C# 支持Unity2020.3.4或更高 您知道像三合镇这样的著名益智游戏,并且您想制作一个自己的游戏。就是这样。这个包正好适合您。 这是一个完整的项目,您可以在零分钟内将其上传到 appstore 或 googleplay 商店。 基本规则: 3个或以上相同的道具可以匹配升级为新的道具。动物如果被困住,也可以合并。 羽毛: -移动(android/ios)就绪。 - 包含所有源代码。 -超过 12 座建筑/军团需要升级。 -三种特殊物品可以提供帮助。 - 三个不同的主题(场景和动物) -unity iap 支持 -Unity UI -广告位已准备好 -包含详细文档

    【JAVA编程基础】针对新手的JAVA基础测试题:涵盖选择题、简答与编程实践

    内容概要:本文档是一份针对Java初学者的基础测试题,分为不定项选择题、简答题和编程题三大部分。选择题涵盖标识符、数组初始化、面向对象概念、运算符优先级、循环结构、对象行为、变量命名规则、基本

    MATLAB机器人运动学、动力学及轨迹规划的建模与仿真

    内容概要:本文详细介绍了如何利用MATLAB进行机器人运动学、动力学以及轨迹规划的建模与仿真。首先,通过具体的代码实例展示了正运动学和逆运动学的实现方法,包括使用DH参数建立机械臂模型、计算末端位姿以及求解关节角度。接着,讨论了雅克比矩阵的应用及其在速度控制中的重要性,并解释了如何检测和处理奇异位形。然后,深入探讨了动力学建模的方法,如使用拉格朗日方程和符号工具箱自动生成动力学方程。此外,还介绍了多种轨迹规划技术,包括抛物线插值和五次多项式插值,确保路径平滑性和可控性。最后,提供了常见仿真问题的解决方案,强调了在实际工程项目中需要注意的关键点。 适合人群:对机器人控制感兴趣的初学者、希望深入了解机器人运动学和动力学的学生及研究人员、从事机器人开发的技术人员。 使用场景及目标:① 学习如何使用MATLAB进行机器人运动学、动力学建模;② 掌握不同类型的轨迹规划方法及其应用场景;③ 解决仿真过程中遇到的各种问题,提高仿真的稳定性和准确性。 其他说明:文中提供的代码片段可以直接用于实验和教学,帮助读者更好地理解和掌握相关概念和技术。同时,针对实际应用中的挑战提出了实用的建议,有助于提升项目的成功率。

    基于单片机的无线环境监测-仿真设计(51x2+12864+18B20+HW).#0092

    包括:源程序工程文件、Proteus仿真工程文件、配套技术手册等 1、采用51/52单片机作为主控芯片; 2、发送机:18B20测温、开关模拟灯光,发送数据; 3、接收机:接受数据、12864液晶显示;

    微电网优化中风光不确定性的处理:基于机会约束与概率序列的Matlab实现

    内容概要:本文探讨了在微电网优化中如何处理风光能源的不确定性,特别是通过引入机会约束和概率序列的方法。首先介绍了风光能源的随机性和波动性带来的挑战,然后详细解释了机会约束的概念,即在一定概率水平下放松约束条件,从而提高模型灵活性。接着讨论了概率序列的应用,它通过对历史数据分析生成多个可能的风光发电场景及其概率,以此为基础构建优化模型的目标函数和约束条件。文中提供了具体的Matlab代码示例,演示了如何利用CPLEX求解器解决此类优化问题,并强调了参数选择、模型构建、约束添加以及求解过程中应注意的技术细节。此外,还提到了一些实用技巧,如通过调整MIP gap提升求解效率,使用K-means聚类减少场景数量以降低计算复杂度等。 适合人群:从事电力系统研究、微电网设计与运营的专业人士,尤其是那些对风光不确定性建模感兴趣的研究者和技术人员。 使用场景及目标:适用于需要评估和优化含有大量间歇性可再生能源接入的微电网系统,旨在提高系统的经济性和稳定性,确保在面对风光出力波动时仍能维持正常运作。 其他说明:文中提到的方法不仅有助于学术研究,也可应用于实际工程项目中,帮助工程师们制定更为稳健的微电网调度计划。同时,文中提供的代码片段可供读者参考并应用于类似的问题情境中。

    linux之用户管理教程.md

    linux之用户管理教程.md

    基于组态王与S7-200 PLC的六层至八层电梯控制系统设计与实现

    内容概要:本文详细介绍了如何利用组态王和西门子S7-200 PLC构建六层或八层电梯控制系统。首先进行合理的IO地址分配,明确输入输出信号的功能及其对应的物理地址。接着深入解析了PLC源代码的关键部分,涵盖初始化、呼叫处理、电梯运行逻辑和平层处理等方面。此外,提供了组态王源代码用于实现动画仿真,展示了电梯轿厢的画面创建及动画连接方法。最后附上了详细的电气原理图和布局图,帮助理解和实施整个系统架构。 适合人群:从事工业自动化控制领域的工程师和技术人员,尤其是对PLC编程和人机界面开发感兴趣的从业者。 使用场景及目标:适用于教学培训、工程项目实践以及研究开发等场合。旨在为相关人员提供一个完整的电梯控制系统设计方案,便于他们掌握PLC编程技巧、熟悉组态软件的应用,并能够独立完成类似项目的开发。 其他说明:文中不仅包含了理论知识讲解,还分享了许多实际操作经验,如解决编码器丢脉冲的问题、优化平层停车精度的方法等。同时强调了安全性和可靠性方面的考虑,例如设置了多重保护机制以确保系统稳定运行。

    基于MTF的1D-2D-CNN-LSTM-Attention时序图像多模态融合的故障识别,适合研究学习(Matlab完整源码和数据)

    在工业生产和设备运行过程中,滚动轴承故障、变压器油气故障等领域的数据分类与故障诊断至关重要。准确的数据分类与故障诊断能够及时发现设备潜在问题,避免故障恶化导致的生产事故与经济损失。LSTM能够捕获时序信息,马尔可夫场(MTF)能够一维信号转换为二维特征图,并结合CNN学习空间特征,MTF-1D-2D-CNN-LSTM-Attention模型通过将一维时序信号和二维图像融合,融合不同模态优势,并引入多头自注意力机制提高泛化能力,为数据分类与故障诊断提供了新的思路。实验结果表明,该模型在分类准确率、鲁棒性和泛化能力方面具有显著优势。多模态融合算法凭借其创新点和实验验证的有效性,在滚动轴承故障、变压器油气故障等领域展现出广阔的应用前景,有望推动相关领域故障诊断技术的进一步发展。 关键词:多模态融合;故障诊断;马尔可夫场;卷积神经网络;长短期记忆神经网络 适用平台:Matlab2023版本及以上。实验硬件设备配置如下:选用高性能计算机,搭载i7处理器,以确保数据处理和模型训练的高效性;配备16GB的内存,满足大规模数据加载和模型运算过程中的内存需求;使用高性能显卡,提供强大的并行计算能力,加速深度学习模型的训练过程。实验参数的选择依据多方面因素确定。

    【面试模拟系统AI提示词】基于简历和岗位要求的个性化模拟面试(deepseek,豆包,kimi,chatGPT,扣子空间,manus,AI训练师)

    内容概要:本文档提供了一个面试模拟的指导框架,旨在为用户提供一个真实的面试体验。文档中的面试官名为Elian,被设定为性格温和冷静且思路清晰的形象,其主要职责是根据用户提供的简历信息和应聘岗位要求,进行一对一的模拟面试。面试官将逐一提出问题,确保每次只提一个问题,并等待候选人的回答结束后再继续下一个问题。面试官需要深入了解应聘岗位的具体要求,包括但不限于业务理解、行业知识、具体技能、专业背景以及项目经历等方面,从而全面评估候选人是否符合岗位需求。此外,文档强调了面试官应在用户主动发起提问后才开始回答,若用户未提供简历,面试官应首先邀请用户提供简历或描述应聘岗位; 适用人群:即将参加面试的求职者,特别是希望提前熟悉面试流程、提升面试技巧的人士; 使用场景及目标:①帮助求职者熟悉面试流程,提高应对实际面试的信心;②通过模拟面试,让求职者能够更好地展示自己的优势,发现自身不足之处并加以改进; 其他说明:此文档为文本格式,用户可以根据文档内容与面试官Elian进行互动,以达到最佳的模拟效果。在整个模拟过程中,用户应尽量真实地回答每一个问题,以便获得最贴近实际情况的反馈。

    招聘技巧HR必看如何进行网络招聘和电话邀约.ppt

    招聘技巧HR必看如何进行网络招聘和电话邀约.ppt

    三菱PLC与组态王构建3x3书架式堆垛立体库:IO分配、梯形图编程及组态画面设计

    内容概要:本文详细介绍了利用三菱PLC(特别是FX系列)和组态王软件构建3x3书架式堆垛式立体库的方法。首先阐述了IO分配的原则,明确了输入输出信号的功能,如仓位检测、堆垛机运动控制等。接着深入解析了梯形图编程的具体实现,包括基本的左右移动控制、复杂的自动寻址逻辑,以及确保安全性的限位保护措施。还展示了接线图和原理图的作用,强调了正确的电气连接方式。最后讲解了组态王的画面设计技巧,通过图形化界面实现对立体库的操作和监控。 适用人群:从事自动化仓储系统设计、安装、调试的技术人员,尤其是熟悉三菱PLC和组态王的工程师。 使用场景及目标:适用于需要提高仓库空间利用率的小型仓储环境,旨在帮助技术人员掌握从硬件选型、电路设计到软件编程的全流程技能,最终实现高效稳定的自动化仓储管理。 其他说明:文中提供了多个实用的编程技巧和注意事项,如避免常见错误、优化性能参数等,有助于减少实际应用中的故障率并提升系统的可靠性。

    COMSOL电弧放电模型:基于磁流体方程的多物理场耦合仿真及其应用

    内容概要:本文详细探讨了利用COMSOL进行电弧放电现象的模拟,重点在于采用磁流体方程(MHD)来耦合电磁、热流体和电路等多个物理场。文中介绍了关键的数学模型如磁流体动力学方程、热传导方程以及电路方程,并讨论了求解过程中遇到的技术难题,包括参数敏感性、求解器选择、网格划分等问题。此外,作者分享了许多实践经验,比如如何处理不同物理场之间的相互作用,怎样避免数值不稳定性和提高计算效率。 适用人群:适用于从事电弧放电研究的专业人士,尤其是那些希望通过数值模拟深入了解电弧行为并应用于实际工程项目的人群。 使用场景及目标:①帮助研究人员更好地理解和预测电弧放电过程中的各种物理现象;②为工程师提供优化电气设备设计的方法论支持;③指导使用者正确配置COMSOL软件的相关参数以确保高效稳定的仿真结果。 其他说明:尽管存在较高的计算复杂度和技术挑战,成功的电弧放电仿真能够显著提升对这一重要物理过程的认识水平,并促进相关领域的技术创新和发展。

    基于粒子群优化的KELM算法在多维输入单维输出数据处理中的应用与性能提升

    内容概要:本文详细介绍了如何利用粒子群优化算法(PSO)改进极限学习机(KELM),以提升其在多维输入单维输出数据处理任务中的性能。首先简述了KELM的工作原理及其快速训练的特点,接着深入探讨了PSO算法的机制,包括粒子的速度和位置更新规则。然后展示了如何将PSO应用于优化KELM的关键参数,如输入权值和隐含层偏置,并提供了具体的Python代码实现。通过对模拟数据和实际数据集的实验对比,证明了PSO优化后的KELM在预测精度上有显著提升,尤其是在处理复杂数据时表现出色。 适合人群:对机器学习尤其是深度学习有一定了解的研究人员和技术爱好者,以及从事数据分析工作的专业人士。 使用场景及目标:适用于需要高效处理多维输入单维输出数据的任务,如时间序列预测、回归分析等。主要目标是通过优化模型参数,提高预测准确性并减少人工调参的时间成本。 其他说明:文中不仅给出了详细的理论解释,还附上了完整的代码示例,便于读者理解和实践。此外,还讨论了一些实用技巧,如参数选择、数据预处理等,有助于解决实际应用中的常见问题。

    基于粒子群算法的微网优化调度Matlab程序设计与实现

    内容概要:本文介绍了利用粒子群算法(PSO)解决微网优化调度问题的方法。主要内容涵盖微网系统的组成(风力、光伏、储能、燃气轮机、柴油机)、需求响应机制、储能SOC约束处理及粒子群算法的具体实现。文中详细描述了目标函数的设计,包括发电成本、启停成本、需求响应惩罚项和SOC连续性惩罚项的计算方法。同时,阐述了粒子群算法的核心迭代逻辑及其参数调整策略,如惯性权重的线性递减策略。此外,还讨论了代码调试过程中遇到的问题及解决方案,并展示了仿真结果,证明了模型的有效性和优越性。 适合人群:从事电力系统优化、智能算法应用的研究人员和技术人员,特别是对微网调度感兴趣的读者。 使用场景及目标:适用于研究和开发微网优化调度系统,旨在提高供电稳定性的同时降低成本。具体应用场景包括但不限于分布式能源管理、工业园区能源调度等。目标是通过合理的调度策略,使微网系统在满足需求响应的前提下,实现经济效益最大化。 其他说明:本文提供的Matlab程序具有良好的模块化设计,便于扩展和维护。建议读者在理解和掌握基本原理的基础上,结合实际情况进行改进和创新。

    【KUKA 机器人资料】:典型机器人案例分析.pdf

    KUKA机器人相关资料

    基于多智能体的高层建筑分阶段火灾疏散仿 真及策略研究.pdf

    基于多智能体的高层建筑分阶段火灾疏散仿 真及策略研究.pdf

    IR2-Net-ACM资源

    Iterative Time Series Imputation by Maintaining Dependency Consistency (ACM TKDD 2024)

    电力电子领域带同步整流桥的交错PFC源代码仿真实现及优化

    内容概要:本文详细探讨了带同步整流桥的交错PFC(功率因数校正)电路的设计与仿真实现。交错PFC通过多路PFC电路交错工作,降低了输入电流纹波,提高了功率密度。同步整流桥采用MOSFET代替传统二极管,减少了整流损耗,提升了效率。文中提供了关键代码片段,包括PWM控制、同步整流桥控制逻辑、电流环控制等,并介绍了如何在MATLAB/Simulink中搭建仿真模型,验证设计方案的有效性。此外,还讨论了仿真过程中遇到的问题及其解决方案,如死区时间处理、电流采样精度、负载突变应对等。 适合人群:从事电力电子设计的研究人员和技术工程师,尤其是对PFC技术和同步整流感兴趣的从业者。 使用场景及目标:适用于研究和开发高效的电源管理系统,旨在提高电能利用率,减少谐波污染,优化电源性能。目标是通过仿真实验验证设计方案的可行性,最终应用于实际硬件开发。 其他说明:文章强调了仿真与实际调试的区别,提醒读者在实际应用中需要注意的细节,如电流采样精度、死区时间和负载突变等问题。同时,提供了具体的代码实现和仿真技巧,帮助读者更好地理解和掌握这一复杂的技术。

    MATLAB实现冷热电气多能互补微能源网的鲁棒优化调度模型

    内容概要:本文详细探讨了MATLAB环境下冷热电气多能互补微能源网的鲁棒优化调度模型。首先介绍了多能耦合元件(如风电、光伏、P2G、燃气轮机等)的运行特性模型,展示了如何通过MATLAB代码模拟这些元件的实际运行情况。接着阐述了电、热、冷、气四者的稳态能流模型及其相互关系,特别是热电联产过程中能流的转换和流动。然后重点讨论了考虑经济成本和碳排放最优的优化调度模型,利用MATLAB优化工具箱求解多目标优化问题,确保各能源设备在合理范围内运行并保持能流平衡。最后分享了一些实际应用中的经验和技巧,如处理风光出力预测误差、非线性约束、多能流耦合等。 适合人群:从事能源系统研究、优化调度、MATLAB编程的专业人士和技术爱好者。 使用场景及目标:适用于希望深入了解综合能源系统优化调度的研究人员和工程师。目标是掌握如何在MATLAB中构建和求解复杂的多能互补优化调度模型,提高能源利用效率,降低碳排放。 其他说明:文中提供了大量MATLAB代码片段,帮助读者更好地理解和实践所介绍的内容。此外,还提及了一些有趣的发现和挑战,如多能流耦合的复杂性、鲁棒优化的应用等。

    基于Simulink的永磁同步电机无位置传感器FOC控制系统仿真与优化

    内容概要:本文详细介绍了如何在Simulink中构建永磁同步电机(PMSM)无位置传感器的磁场定向控制(FOC)系统。主要内容涵盖双闭环PI调节器的设计、SVPWM调制方法、坐标变换、滑模观测器用于无位置估算以及各环节常见问题及其解决方案。文中提供了具体的MATLAB代码示例,如Clarke变换、SVPWM扇区判断、PI调节器抗饱和处理等,并分享了许多实用的调试技巧,如电流环积分限幅、SVPWM扇区判断优化、滑模观测器增益选择等。 适合人群:具有一定电机控制基础的研究人员和技术工程师,尤其是从事电力电子、自动化控制领域的专业人士。 使用场景及目标:适用于希望深入理解并掌握PMSM无位置传感器FOC控制系统的开发者。主要目标是在Simulink环境中搭建完整的FOC控制系统,解决实际应用中的各种技术难点,提高系统的稳定性和精度。 其他说明:文章强调了仿真与实际硬件之间的差异,指出了一些常见的陷阱和应对措施。同时,作者分享了很多个人实践经验,使得复杂的技术概念更加通俗易懂。

Global site tag (gtag.js) - Google Analytics