- 浏览: 77939 次
- 性别:
- 来自: 大连
-
文章分类
最新评论
代码部门又出问题了,上次是页面查询响应很慢,这次是页面更新速度很慢,开发人员提交了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
发表评论
-
oracle define与variable
2011-04-26 17:59 0define(即host变量) Host变量主要作用是起到 ... -
存储过程
2010-04-16 19:11 1069存储过程小结: CREATE OR REPLACE PROC ... -
Oracle的优化器
2010-04-15 11:12 864Oracle的优化器有两种优 ... -
Update用法
2010-04-14 17:30 1082更新表A的某些字段,字段的值来源于表B。 第一种写法: U ... -
oracle的系统表
2010-01-22 17:47 923最近用到的系统表挺多的。每次都百度N次。 现记录一下,一劳永逸 ... -
oracle的表或View字段数取得
2010-01-22 17:15 1006今天同事让我帮忙写个文档,里边有很多是记录View的字段数。 ... -
SQL和PL/SQL
2009-11-25 13:48 927总是听说PL/SQL,听了无数遍这个名词。自己也开发过存储过程 ... -
intersect, minus
2009-11-10 17:36 1416intersect运算:返回查询结果中相同的部分 exp:各 ... -
ETL BI/DW ERP CRW
2009-10-16 11:18 1136ETL,Extraction-Transformation ... -
交叉表解决方案
2009-10-14 16:56 850最近看到论坛的问答里有人问到交叉表的问题。 我也不知道专业术语 ... -
学习Oracle的网站
2009-10-13 22:24 969http://www.itpub.net/forum-72-1 ... -
oracle9i 和10G下载地址
2009-10-13 20:45 2305orcal 9和orcal10的下载地址 Oracle9i ... -
group by 和 partition by的比较
2009-10-13 19:01 4557今天看到一个老兄的问题, 大概如下: 查询出部门的最低工资的u ... -
查看系统位数
2009-10-12 22:20 1406今天想Down一个ORACLE,结果版本有很多,什么32位用的 ... -
一些面试题
2009-10-12 21:36 864(1)FROM子句和WHERE子句应该注意点什么 (2)对一 ... -
DDL,DML,DCL,TCL
2009-10-12 21:29 1913最近从JAVA组调到数据库组,最近几天一顿恶补ORACLE的知 ...
相关推荐
目前关于属性操作的创建于编辑主要有新旧两个版本,旧版本主要使用UF_ATTR_assign()函数,新版本主要使用UF_ATTR_set_user_attribute()函数。注意在使用新版本是需要初始化。
编书 机械制图习题集(属性块图框)出版社.dwg
【项目资源】: 物联网项目适用于从基础到高级的各种项目,特别是在性能要求较高的场景中,比如操作系统开发、嵌入式编程和底层系统编程。如果您是初学者,可以从简单的控制台程序开始练习;如果是进阶开发者,可以尝试涉及硬件或网络的项目。 【项目质量】: 所有源码都经过严格测试,可以直接运行。 功能在确认正常工作后才上传。 【适用人群】: 适用于希望学习不同技术领域的小白或进阶学习者。 可作为毕设项目、课程设计、大作业、工程实训或初期项目立项。 【附加价值】: 项目具有较高的学习借鉴价值,也可直接拿来修改复刻。 对于有一定基础或热衷于研究的人来说,可以在这些基础代码上进行修改和扩展,实现其他功能。 【沟通交流】: 有任何使用上的问题,欢迎随时与博主沟通,博主会及时解答。 鼓励下载和使用,并欢迎大家互相学习,共同进步。 # 注意 1. 本资源仅用于开源学习和技术交流。不可商用等,一切后果由使用者承担。 2. 部分字体以及插图等来自网络,若是侵权请联系删除。
内容概要:本文档提供了三种神经网络控制器(NNPC、MRC和NARMA-L2)在机器人手臂模型上性能比较的MATLAB实现代码及详细解释。首先初始化工作空间并设定仿真参数,包括仿真时间和采样时间等。接着定义了机器人手臂的二阶动力学模型参数,并将其转换为离散时间系统。对于参考信号,可以选择方波或正弦波形式。然后分别实现了三种控制器的具体算法:MRC通过定义参考模型参数并训练神经网络来实现控制;NNPC利用预测模型神经网络并结合优化算法求解控制序列;NARMA-L2则通过两个神经网络分别建模f和g函数,进而实现控制律。最后,对三种控制器进行了性能比较,包括计算均方根误差、最大误差、调节时间等指标,并绘制了响应曲线和跟踪误差曲线。此外,还强调了机器人手臂模型参数的一致性和参考信号设置的规范性,提出了常见问题的解决方案以及性能比较的标准化方法。 适合人群:具备一定编程基础,特别是熟悉MATLAB编程语言的研究人员或工程师,以及对神经网络控制理论有一定了解的技术人员。 使用场景及目标:①理解不同类型的神经网络控制器的工作原理;②掌握在MATLAB中实现这些控制器的方法;③学会如何设置合理的参考信号并保证模型参数的一致性;④能够根据具体的性能指标对比不同控制器的效果,从而选择最适合应用场景的控制器。 其他说明:本文档不仅提供了完整的实验代码,还对每个步骤进行了详细的注释,有助于读者更好地理解每段代码的功能。同时,针对可能出现的问题给出了相应的解决办法,确保实验结果的有效性和可靠性。为了使性能比较更加公平合理,文档还介绍了标准化的测试流程和评估标准,这对于进一步研究和应用具有重要的指导意义。
资源内项目源码是来自个人的毕业设计,代码都测试ok,包含源码、数据集、可视化页面和部署说明,可产生核心指标曲线图、混淆矩阵、F1分数曲线、精确率-召回率曲线、验证集预测结果、标签分布图。都是运行成功后才上传资源,毕设答辩评审绝对信服的保底85分以上,放心下载使用,拿来就能用。包含源码、数据集、可视化页面和部署说明一站式服务,拿来就能用的绝对好资源!!! 项目备注 1、该资源内项目代码都经过测试运行成功,功能ok的情况下才上传的,请放心下载使用! 2、本项目适合计算机相关专业(如计科、人工智能、通信工程、自动化、电子信息等)的在校学生、老师或者企业员工下载学习,也适合小白学习进阶,当然也可作为毕设项目、课程设计、大作业、项目初期立项演示等。 3、如果基础还行,也可在此代码基础上进行修改,以实现其他功能,也可用于毕设、课设、作业等。 下载后请首先打开README.txt文件,仅供学习参考, 切勿用于商业用途。
# 基于Python的微信智能聊天机器人 ## 项目简介 本项目是一个基于Python的微信智能聊天机器人框架,旨在通过ChatGPT的强大对话能力,将微信打造成一个智能助手。该机器人支持私聊和群聊的智能回复、语音识别、图片生成、插件扩展等功能,能够与好友进行多轮对话,并提供丰富的交互体验。项目支持多端部署,包括个人微信、微信公众号和企业微信应用。 ## 项目的主要特性和功能 多端部署支持个人微信、微信公众号和企业微信应用等多种部署方式。 智能对话支持私聊和群聊的智能回复,具备多轮会话上下文记忆功能,支持GPT3、GPT3.5、GPT4等模型。 语音识别可识别语音消息并通过文字或语音回复,支持Azure、Baidu、Google、OpenAI等多种语音模型。 图片生成支持图片生成和图生图功能(如照片修复),可选择DALLE、Stable Diffusion、Replicate等模型。
【项目资源】: 适用于从基础到高级的各种项目,特别是在性能要求较高的场景中,比如操作系统开发、嵌入式编程和底层系统编程。如果您是初学者,可以从简单的控制台程序开始练习;如果是进阶开发者,可以尝试涉及硬件或网络的项目。 【项目质量】: 所有源码都经过严格测试,可以直接运行。 功能在确认正常工作后才上传。 【适用人群】: 适用于希望学习不同技术领域的小白或进阶学习者。 可作为毕设项目、课程设计、大作业、工程实训或初期项目立项。 【附加价值】: 项目具有较高的学习借鉴价值,也可直接拿来修改复刻。 对于有一定基础或热衷于研究的人来说,可以在这些基础代码上进行修改和扩展,实现其他功能。 【沟通交流】: 有任何使用上的问题,欢迎随时与博主沟通,博主会及时解答。 鼓励下载和使用,并欢迎大家互相学习,共同进步。 # 注意 1. 本资源仅用于开源学习和技术交流。不可商用等,一切后果由使用者承担。 2. 部分字体以及插图等来自网络,若是侵权请联系删除。
资源内项目源码是来自个人的毕业设计,代码都测试ok,包含源码、数据集、可视化页面和部署说明,可产生核心指标曲线图、混淆矩阵、F1分数曲线、精确率-召回率曲线、验证集预测结果、标签分布图。都是运行成功后才上传资源,毕设答辩评审绝对信服的保底85分以上,放心下载使用,拿来就能用。包含源码、数据集、可视化页面和部署说明一站式服务,拿来就能用的绝对好资源!!! 项目备注 1、该资源内项目代码都经过测试运行成功,功能ok的情况下才上传的,请放心下载使用! 2、本项目适合计算机相关专业(如计科、人工智能、通信工程、自动化、电子信息等)的在校学生、老师或者企业员工下载学习,也适合小白学习进阶,当然也可作为毕设项目、课程设计、大作业、项目初期立项演示等。 3、如果基础还行,也可在此代码基础上进行修改,以实现其他功能,也可用于毕设、课设、作业等。 下载后请首先打开README.txt文件,仅供学习参考, 切勿用于商业用途。
【项目资源】: 物联网项目适用于从基础到高级的各种项目,特别是在性能要求较高的场景中,比如操作系统开发、嵌入式编程和底层系统编程。如果您是初学者,可以从简单的控制台程序开始练习;如果是进阶开发者,可以尝试涉及硬件或网络的项目。 【项目质量】: 所有源码都经过严格测试,可以直接运行。 功能在确认正常工作后才上传。 【适用人群】: 适用于希望学习不同技术领域的小白或进阶学习者。 可作为毕设项目、课程设计、大作业、工程实训或初期项目立项。 【附加价值】: 项目具有较高的学习借鉴价值,也可直接拿来修改复刻。 对于有一定基础或热衷于研究的人来说,可以在这些基础代码上进行修改和扩展,实现其他功能。 【沟通交流】: 有任何使用上的问题,欢迎随时与博主沟通,博主会及时解答。 鼓励下载和使用,并欢迎大家互相学习,共同进步。 # 注意 1. 本资源仅用于开源学习和技术交流。不可商用等,一切后果由使用者承担。 2. 部分字体以及插图等来自网络,若是侵权请联系删除。
该资源为scipy-0.11.0.tar.gz,欢迎下载使用哦!
内容概要:PT500PLUS平行轴齿轮箱故障测试台是由瓦伦尼安(VALENIAN)Machine Vibration & Gearbox Simulator(机械振动-齿轮箱模拟器)开发的专业机械故障仿真测试设备。该测试台旨在模拟和研究转子、齿轮传动、轴承及电机系统中的多种常见故障,包括但不限于轴不对中、转子不平衡、机械松动、轴承故障、齿轮故障(如点蚀、磨损、断齿等)以及电机故障(如转子不平衡、轴承故障、匝间短路等)。测试台配备有先进的传感器和数据采集系统,能够实时采集并分析振动、噪声、转速、扭矩等参数,提供多通道同步信号采集与频谱分析功能。此外,测试台还配备了10寸触摸屏、PLC智能控制系统和急停按钮,确保操作简便和安全。 适用人群:机械工程专业师生、科研人员以及从事机械故障诊断和维护的技术人员。 使用场景及目标:①用于高校和科研机构的教学和研究,帮助学生和研究人员深入理解机械故障的机理;②为企业提供故障诊断和预防性维护的解决方案,提高设备可靠性和运行效率;③通过模拟真实工况下的故障,进行轴承寿命预测性试验,研究轴承故障机制与轴承载荷、转速、振动、温度之间的关系。 其他说明:测试台结构紧凑,模块化设计,便于移动和维护。它不仅支持多种传感器的安装和数据采集,还提供了丰富的分析软件功能,如FFT频谱分析、轴心轨迹图、小波分析等,支持数据导出和二次开发,适用于各种复杂的研究和应用需求。
内容概要:本文档详细介绍了XXX5G特色商业街的规划设计方案,旨在通过5G技术与物联网等前沿科技的融合,全方位提升游客体验感和街区运营效率。首先,基础信息系统涵盖综合管理智慧平台、统一结算系统、5G视频智慧安防监控系统等多个子系统,实现多系统协同管理和数据安全保障。其次,特色应用方面,推出5G短信服务、5G智慧机器人、5G无人巡逻车、5G+XR时空走廊、5G+元宇宙体验馆等项目,将尖端科技与深厚文化底蕴巧妙结合,创新文旅体验形式。最后,通过5G高清视频直播与分享、5G+高空文旅等举措,进一步提升水街的影响力和吸引力。 适用人群:本方案适用于文旅项目规划者、商业街运营管理者、信息技术从业者以及对智慧城市建设感兴趣的各界人士。 使用场景及目标:①为商业街提供全面的智慧化升级方案,涵盖基础信息系统和特色应用两大部分;②通过5G技术赋能,实现高效运营管理和沉浸式游客体验;③推动文旅产业创新发展,促进地方经济繁荣和社会进步。 其他说明:该方案不仅关注技术实现,更重视用户体验和服务质量,强调文化传承与科技创新的有机结合,致力于打造具有国际影响力的智慧文旅新地标。
【更新至2023年】2000-2023年中国气候政策不确定性指数数据(全国、省、市三个层面) 1.时间:2000-2023年 2.来源:使用人工审计和深度学习算法MacBERT模型,基于中国《人民日报》《光明日报》《经济日报》《环球时报》《科技日报》《中国新闻社》等6家主流报纸中的1,755,826篇文章,构建了2000年1月至2023年12月的中国全国、省份和主要城市层面的CCPU指数。研究框架包括六个部分:数据收集、清洗数据、人工审计、模型构建、指数计算与标准化以及技术验证。 3.范围:中国、省、市三个层次 4.参考文献:Ma, Y. R., Liu, Z., Ma, D., Zhai, P., Guo, K., Zhang, D., & Ji, Q. (2023). A news-based climate policy uncertainty index for China. Scientific Data, 10(1), 881. 5.时间跨度:全国层面:日度、月度、年度;省级层面:月度、年度;地级市层面:月度、年度
【项目资源】: 单片机项目适用于从基础到高级的各种项目,特别是在性能要求较高的场景中,比如操作系统开发、嵌入式编程和底层系统编程。如果您是初学者,可以从简单的控制台程序开始练习;如果是进阶开发者,可以尝试涉及硬件或网络的项目。 【项目质量】: 所有源码都经过严格测试,可以直接运行。 功能在确认正常工作后才上传。 【适用人群】: 适用于希望学习不同技术领域的小白或进阶学习者。 可作为毕设项目、课程设计、大作业、工程实训或初期项目立项。 【附加价值】: 项目具有较高的学习借鉴价值,也可直接拿来修改复刻。 对于有一定基础或热衷于研究的人来说,可以在这些基础代码上进行修改和扩展,实现其他功能。 【沟通交流】: 有任何使用上的问题,欢迎随时与博主沟通,博主会及时解答。 鼓励下载和使用,并欢迎大家互相学习,共同进步。 # 注意 1. 本资源仅用于开源学习和技术交流。不可商用等,一切后果由使用者承担。 2. 部分字体以及插图等来自网络,若是侵权请联系删除。
内容概要:BTS200轴承寿命预测测试台是一款专为研究轴承寿命预测及加速磨损过程设计的实验设备。该设备结构灵活,支持不同尺寸和类型的轴承测试,最大负载可达15000N。测试台采用先进的伺服电缸加载系统,能够在轴向和径向上精确施加载荷,并配备高精度测力传感器和温度监测系统,确保实验数据的准确性。此外,BTS200还拥有油液循环润滑系统,通过油膜减少摩擦和磨损,保持机械部件在适宜的工作温度范围内,延长轴承寿命。Bearing Prognostics Simulator(实验台可通过触控屏操作,支持多速运行(0-3000RPM),并具备过热保护机制,在温度超过150℃时自动停机。BTS200广泛应用于轴承寿命预测、故障机制研究以及剩余寿命预测模型的开发。 适合人群:轴承设计研发人员、机械工程研究人员、高校实验室师生及相关领域工程师。 使用场景及目标:①研究轴承在不同载荷和转速条件下的磨损特性;②开发和验证轴承剩余寿命预测模型;③探索轴承故障机制及其对系统性能的影响;④评估不同润滑方式对轴承寿命的影响。 其他说明:BTS200测试台不仅提供硬件支持,还配备了完整的软件控制系统,包括PLC闭环控制、温度监测反馈模块等,确保实验过程的稳定性和数据的可靠性。此外,设备支持快速安装和拆卸测试轴承,便于实验操作。
xilinx基于PCIE IP的PCIE Bridge IP操作手册
【项目资源】: 单片机项目适用于从基础到高级的各种项目,特别是在性能要求较高的场景中,比如操作系统开发、嵌入式编程和底层系统编程。如果您是初学者,可以从简单的控制台程序开始练习;如果是进阶开发者,可以尝试涉及硬件或网络的项目。 【项目质量】: 所有源码都经过严格测试,可以直接运行。 功能在确认正常工作后才上传。 【适用人群】: 适用于希望学习不同技术领域的小白或进阶学习者。 可作为毕设项目、课程设计、大作业、工程实训或初期项目立项。 【附加价值】: 项目具有较高的学习借鉴价值,也可直接拿来修改复刻。 对于有一定基础或热衷于研究的人来说,可以在这些基础代码上进行修改和扩展,实现其他功能。 【沟通交流】: 有任何使用上的问题,欢迎随时与博主沟通,博主会及时解答。 鼓励下载和使用,并欢迎大家互相学习,共同进步。 # 注意 1. 本资源仅用于开源学习和技术交流。不可商用等,一切后果由使用者承担。 2. 部分字体以及插图等来自网络,若是侵权请联系删除。
使用教程 (1).mov
# 基于webpack和Vue的前端项目构建方案 ## 项目简介 本项目是基于webpack和Vue构建的前端项目方案,借助webpack强大的打包能力以及Vue的开发特性,可用于快速搭建现代化的前端应用。项目不仅完成了基本的webpack与Vue的集成配置,还在构建速度优化和代码规范性方面做了诸多配置。 ## 项目的主要特性和功能 1. 打包功能运用webpack进行模块打包,支持将scss转换为css,借助babel实现语法转换。 2. Vue开发支持集成Vue框架,能使用Vue单文件组件的开发模式。 3. 构建优化采用threadloader实现多进程打包,cacheloader缓存资源,极大提高构建速度开启热更新功能,开发更高效。 4. 错误处理与优化提供不同环境下的错误映射配置,便于定位错误利用webpackbundleanalyzer分析打包体积。
数据说明: 板球是世界上观看人数第二多的运动。这项运动充满了大量的情绪和戏剧性,直到比赛的最后一球。而且,有板球运动员一次又一次地证明,他们是这项运动的真正大师,改变了输掉比赛到赢得比赛的方程式,并在比赛中用他们的魔法咒语为他们的国家带来了许多胜利。作为板球迷,是时候利用深度学习技能,通过这个数据集获得更多乐趣,并检测/预测有史以来最伟大的板球运动员了。 数据准备: 2019年,BBC邀请观众投票选出“有史以来最伟大的板球运动员”,最终根据收到的最高票数发布了有史以来最伟大的30名板球运动员名单。这个数据集从中提取了30名板球运动员的相关图像6950张