<![CDATA[独木舟]]>

<![CDATA[独木舟]]> http://kanoe.cn/ PJBlog3 2010-07-27T22:41:21+08:00 <![CDATA[嗯阿]]> 独木舟 http://kanoe.cn/ master@kanoe.cn 2010-07-27T22:41:21+08:00 2010-07-27T22:41:21+08:00

http://kanoe.cn/default.asp?id=204 <![CDATA[量子通信传输实验在中国成功进行]]> 独木舟 http://kanoe.cn/ master@kanoe.cn 2010-05-29T01:43:15+08:00 2010-05-29T01:43:15+08:00

需要说明的一点是，量子通信与我们从科幻小说中了解到的并不相同，在科幻电影或小说中一个地方的物体或人可以在另一个地方完美的复制出来。在量子通信中，两个光子或离子形成纠缠态，当一个的量子态发生改变另一个也随之改变，就好象它们仍然连在一起。因而能让量子信息实现远距通信。

曾被爱因斯坦称作幽灵般的超距离作用(spooky action at a distance)的“量子纠缠”，指的是，在量子力学中，有共同来源的两个微观粒子之间存在着某种纠缠关系，不管它们被分开多远，只要一个粒子发生变化就能立即影响到另外一个粒子，即两个处于纠缠态的粒子无论相距多远，都能“感知”和影响对方的状态，这就是量子纠缠。

由于量子纠缠的存在，使得光子、电子甚至是原子之间相互影响相互制约地共同传输。理论上讲，这种纠缠可以使两点之间，不论距离的即时通信顺利完成。在以前的实验中，光子被限制在数百米长的光纤信道内，以确保它们的状态不发生改变，即便如此，光纤传输的保密性差，易被窃听。如今，中国科学家把纠缠态的高能光子对穿过10英里长的自由空间通道，量子保密通信技术的物理原理保证了其绝对安全性。这一距离是目前国际上自由空间纠缠光子分发的最远距离,也是目前国际上没有窃听漏洞量子密钥分发的最大距离。

研究人员发现，在这个距离上接收端的光子仍能响应留在后方的光子状态变化。远距传输的平均保真度为89%。这项突破意味着不久的未来量子通信应用将能扩大到全球规模。

该实验由中国科技大学的科学家潘建伟教授主导，实现了目前国际上最远距离的“自由空间纠缠光子分发”，他和他的同事杨涛、彭承志的研究论文已发表于国际物理学权威期刊《物理评论快报》。该期刊的审稿人对这一成果给予了高度评价，称之为 “一项相当了不起的成就”。

在该实验中，科学家们通过“自由空间纠缠光子的分发”，首次在国际上证明了纠缠光子在穿透等效于整个大气层厚度的地面大气后，其纠缠的特性仍然能够保持，并可应用于高效、安全的量子通信。这一研究成果为实现全球化的量子通信奠定了实验基础。

该项实验，为全球范围内量子保密通讯的实现带来希望。

据潘建伟的研究团队介绍，他们正在计划开展更远距离的量子通信实验，下一步的目标是通过自由空间实现几百公里的量子通信，超越光纤传输的极限。他们希望，有朝一日，人类能够通过通信卫星实现更远距离乃至全球的量子保密通信。

[转自http://cnbeta.com/articles/112349.htm]]]>

http://kanoe.cn/default.asp?id=203 <![CDATA[呃]]> 独木舟 http://kanoe.cn/ master@kanoe.cn 2010-05-19T10:17:30+08:00 2010-05-19T10:17:30+08:00

http://kanoe.cn/default.asp?id=202 <![CDATA[腾迅，网民愤怒了]]> 独木舟 http://kanoe.cn/ master@kanoe.cn 2010-04-26T23:50:18+08:00 2010-04-26T23:50:18+08:00

一、发现
晚上上qq农场，发现如下留言：

引用内容

今天 17:05 ＱＱ农场管理员：尊敬的QQ农牧场用户：您已被查出近期仍在使用第三方软件，现对您的农场将原有的28级降为27级，并回收一块土地。若再次出现，将进行回收土地等处理措施。希望您珍惜QQ农场，远离外挂！

此刻，我震惊了，我从来都是抱着正常的心态玩农场，根本没用过所谓的外挂。硬要说有，好吧，只在自己手机上装了腾迅的qq浏览器农场版，用来方便收菜。难倒腾迅的qq浏览器也是外挂？？？到现在还是没搞懂腾迅所谓的外挂是哪些。腾迅管理员脑子不知道长哪里了，这是一个莫须有的罪名呀，其严重如诽谤。

也不知道腾迅是怎样判断外挂的，单从经验上升和偷菜数量？经验上升快就很简单，不停叫别人放草给自己除就行，偷菜的话现在多少人是早上3点或6点起来偷菜的，腾迅有统计过么？难倒这都是外挂？显然要是腾迅认为是，那他们就是脑子进水了。

二、投诉
气愤之下想去投诉，打开腾迅客服的在线提问，查询得到如下结果：

引用内容

亲爱的玩家朋友您好！

非常感谢您使用我们的服务！关于您反馈QQ农场等级下降问题，经系统检测，由于QQ号码:********曾使用过农场第三方辅助软件（即外挂），故，现对此QQ号码作出如下处理：农场等级由28级降到27级，同时回收一块土地。对于等级下降及土地回收，很抱歉，不支持恢复，不便之处敬请原谅！

如您本人未使用过第三方软件，请您及时修改密码并加强帐号安全防护与管理，同时清空浏览器的缓存记录。为了确保所有QQ农场玩家遵循游戏的公平性，我司对使用第三方辅助软件（即外挂）打击处理的态度是坚定且力度会不断加大。在此，非常感谢您一直以来的支持与理解，若您仍有疑问，欢迎您再次反馈！

我更震惊了，“如您本人未使用过第三方软件，请您及时修改密码并加强帐号安全防护与管理”，这意思是我们的qq被盗后，qq盗贼还负责帮我们开外挂升级？！！！这是否有辱国人的智商！！！！也就是说不管用没用外挂，无论如何你也是用了。

无奈之下去qq农场的讨论区，只见一堆人在投诉tx，可见这是一个大范围的误判。

三、损失
很多情况下，所谓降一级不是刚好一级，像我就是一级半，足足8000多点的经验，即使以后被升级回来被降的半级也是无力回天吧，何况这是发生奇迹才发生的事情。还有被没收的土地，现在要230000金币。还有算上这段时间的时间损失和精神损失，广大网民真的大折了。

四、诡异
后来再上qq空间，发现有2条小纸条，其中一条写着

引用内容

尊敬的用户，关于您的农场/牧场被降级/封号的问题，请登陆农牧场降级封号自助查询系统(http://my.qq.com/sns)了解详细原因或进行申诉。

为了再探究竟，再登录上面指定网站，输入验证码，得出的结果如下。

引用内容

您没有被降级的记录，可以正常使用qq农牧场。

以为是级别升回去了，谁知道还是那样子。居然不认账了，真是诡异了。

五、题外话
据说有很多人在21号哀悼日的时候利用系统漏洞偷了菜，腾迅现在就到处找人降级。我只想说：你tmd腾迅自己出的漏洞使某些人能在停机的时候偷到菜，不自检一下还想推卸责任！
ps：我那时候也是登不上去，但很无辜的被偷了很多萝卜！

六、感慨
这样的判断外挂能力真是服了农场的管理员和程序员，实在不行就让我去写外挂监控说不定还更好！

七、最新进展
由于在腾迅qq农场的讨论区跟帖投诉了，现在（27日0：50）农场已经恢复了，级别貌似比原先加一同时经验清零了，就当这段时间的精神损失费？不知道其他人是不是也这样呢。]]>

http://kanoe.cn/default.asp?id=201 <![CDATA[相机传感器尺寸对比]]> 独木舟 http://kanoe.cn/ master@kanoe.cn 2010-03-31T22:53:35+08:00 2010-03-31T22:53:35+08:00

]]>

http://kanoe.cn/default.asp?id=200 <![CDATA[惠普“蟑螂门”对联]]> 独木舟 http://kanoe.cn/ master@kanoe.cn 2010-03-19T20:13:34+08:00 2010-03-19T20:13:34+08:00

]]>

http://kanoe.cn/default.asp?id=199 <![CDATA[杂]]> 独木舟 http://kanoe.cn/ master@kanoe.cn 2010-03-16T23:53:59+08:00 2010-03-16T23:53:59+08:00

http://kanoe.cn/default.asp?id=198 <![CDATA[临时表空间历险[转]]]> 独木舟 http://kanoe.cn/ master@kanoe.cn 2010-02-12T18:26:18+08:00 2010-02-12T18:26:18+08:00

OS:WINDOWS XP
数据库：Oracle 9.2.0.1.0

2、起因
今天在看《oracle性能优化技术内幕》，中间有一个关于数据库缓冲区高速缓存的脚本：

Select o.owner,o.object_type,o.object_name,
Count(b.OBJD) From v$bh b,dba_objects o
Group By o.owner ,o.object_type,o.object_name
Having Count(b.OBJD)>(Select
to_number(Value*0.5) From v$parameter
Where Name = 'db_block_buffers')

用sys用户登陆数据库执行该脚本，然后一直处于正在执行的状态，然后报错，
“无法通过128（在表空间temp中）扩展 temp 段”，确定之后，检查临时表空间，是因为临时表空间满了，而且没有设置自动扩展，设置自动扩展之后，开始重新查询，我的temp表空间参数：大小200m，自动扩展，每次扩展100m。在执行该脚本的同时，用oem观察表空间的大小，一直到表空间增长至4g左右的时候，查询依然没有结果。此时表空间已经很大了，因此在考虑临时表空间到底是如何增长的呢？在什么情况下释放空间？是否可以收缩？

3、为此做如下测试：

1) 首先重建temp表空间，并重启数据库，确保temp表空间没有被占用
C:\Documents and Settings\zero>sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.1.0 - Production on 星期五 12月 7 16:14:09 2007

Copyright (c) 1982, 2002, oracle Corporation.  All rights reserved.

连接到:
oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the Partitioning, OLAP and oracle Data Mining options
JServer Release 9.2.0.1.0 - Production

SQL> shutdown immediate;
数据库已经关闭。
已经卸载数据库。
orACLE 例程已经关闭。
SQL> startup;
orACLE 例程已经启动。

Total System Global Area  135338868 bytes
Fixed Size                   453492 bytes
Variable Size             109051904 bytes
Database Buffers           25165824 bytes
Redo Buffers                 667648 bytes
数据库装载完毕。
数据库已经打开。
SQL>

2) 检查数据库当前大小和已使用情况
当前大小200M，未使用，

3) 执行下面的脚本，持续50秒
Select o.owner,o.object_type,o.object_name,
Count(b.OBJD) From v$bh b,dba_objects o
Group By o.owner ,o.object_type,o.object_name
Having Count(b.OBJD)>(Select
to_number(Value*0.5) From v$parameter
Where Name = 'db_block_buffers')

50秒之后该脚本依然没有执行出结果，中止该脚本的执行，当前数据库临时表空间大小900M，占用894M。

4、临时表空间的作用

oracle临时表空间主要是用来做查询和存放一些缓存的数据的，磁盘消耗的一个主要原因是需要对查询的结果进行排序
1. 没有为临时表空间设置上限，而是允许无限增长。但是如果设置了一个上限，最后可能还是会面临因为空间不够而出错的问题，临时表空间设置太小会影响性能，临时表空间过大同样会影响性能，至于需要设置为多大需要仔细的测试。
2.查询的时候连表查询中使用的表过多造成的。我们知道在连表查询的时候，根据查询的字段和表的个数会生成一个迪斯卡尔积，这个迪斯卡尔积的大小就是一次查询需要的临时空间的大小，如果查询的字段过多和数据过大，那么就会消耗非常大的临时表空间。

关于临时表空间的释放，在网上查了资料，确认重启数据库可释放临时表空间，如果不能重启实例，而一直保持问题sql语句的执行，temp表空间会一直增长。直到耗尽硬盘空间。在网上看到有个帖子提供了几种释放的方法，但是有的不能应用于当前的版本。此外没有发现好的释放临时表空间的方法。

5、临时表空间的释放测试

使用语句进行表空间大小的修改：
SQL> Alter DATABASE TEMPFILE 'D:\ORACLE\ORADATA\ZERO\TEMP.ORA' RESIZE
  2      200M;
Alter DATABASE TEMPFILE 'D:\ORACLE\ORADATA\ZERO\TEMP.ORA' RESIZE
*
ERROR 位于第 1 行:
orA-03297: 文件包含在请求的 RESIZE 值以外使用的数据

关闭并重启数据库，查看临时表空间的使用情况，当前大小900M，已使用0M

查资料显示oracle系统smon进程会自动清除的，个人并不明确smon什么时候清除临时段。

做如下测试：

SQL> Alter DATABASE TEMPFILE 'D:\ORACLE\ORADATA\ZERO\TEMP.ORA' RESIZE
  2      1500M;

数据库已更改。

SQL> Alter DATABASE TEMPFILE 'D:\ORACLE\ORADATA\ZERO\TEMP.ORA' RESIZE
  2      900M;

数据库已更改。

SQL> Alter DATABASE TEMPFILE 'D:\ORACLE\ORADATA\ZERO\TEMP.ORA' RESIZE
  2      200M;
Alter DATABASE TEMPFILE 'D:\ORACLE\ORADATA\ZERO\TEMP.ORA' RESIZE
*
ERROR 位于第 1 行:
orA-03297: 文件包含在请求的 RESIZE 值以外使用的数据

证明temp表空间被限制在了900M，新建表空间：

SQL> Create
  2      TEMPORARY TABLESPACE "TEMP2" TEMPFILE
  3      'D:\ORACLE\ORADATA\ZERO\TEMP2.ora' SIZE 200M EXTENT
  4      MANAGEMENT LOCAL UNIFORM SIZE 1M;

表空间已创建。

SQL> Alter DATABASE DEFAULT TEMPORARY TABLESPACE "TEMP2";

数据库已更改。

然后执行sql语句

SQL> Select * From test.sal_salary ss order By ss.jsdjgz;

该语句结果较多，就不列出了，查看新临时表空间的使用情况：

大小200M，已用67M，执行下面的语句：

SQL> Alter DATABASE TEMPFILE 'D:\ORACLE\ORADATA\ZERO\TEMP2.ORA' RESIZE
  2       100M;

数据库已更改。

SQL> Alter DATABASE TEMPFILE 'D:\ORACLE\ORADATA\ZERO\TEMP2.ORA' RESIZE 70m;

数据库已更改。
SQL> Alter DATABASE TEMPFILE 'D:\ORACLE\ORADATA\ZERO\TEMP2.ORA' RESIZE 67m
Alter DATABASE TEMPFILE 'D:\ORACLE\ORADATA\ZERO\TEMP2.ORA' RESIZE 67m
*
ERROR 位于第 1 行:
orA-03297: 文件包含在请求的 RESIZE 值以外使用的数据

进行如下操作：

SQL> shtudown immediate;
SP2-0734: 未知的命令开头 "shtudown i..." - 忽略了剩余的行。
SQL> shutdown immediate;
数据库已经关闭。
已经卸载数据库。
orACLE 例程已经关闭。
SQL> startup;
orACLE 例程已经启动。

Total System Global Area  135338868 bytes
Fixed Size                   453492 bytes
Variable Size             109051904 bytes
Database Buffers           25165824 bytes
Redo Buffers                 667648 bytes
数据库装载完毕。
数据库已经打开。
SQL> Alter DATABASE TEMPFILE 'D:\ORACLE\ORADATA\ZERO\TEMP2.ORA' RESIZE 67m;
Alter DATABASE TEMPFILE 'D:\ORACLE\ORADATA\ZERO\TEMP2.ORA' RESIZE 67m
*
ERROR 位于第 1 行:
orA-03297: 文件包含在请求的 RESIZE 值以外使用的数据

SQL> Alter DATABASE TEMPFILE 'D:\ORACLE\ORADATA\ZERO\TEMP2.ORA' RESIZE 70m;

数据库已更改。

SQL> Alter DATABASE TEMPFILE 'D:\ORACLE\ORADATA\ZERO\TEMP2.ORA' RESIZE 200m;

数据库已更改。

SQL> Alter DATABASE TEMPFILE 'D:\ORACLE\ORADATA\ZERO\TEMP2.ORA' RESIZE 70m;

数据库已更改。

SQL> Alter DATABASE TEMPFILE 'D:\ORACLE\ORADATA\ZERO\TEMP2.ORA' RESIZE 67m;
Alter DATABASE TEMPFILE 'D:\ORACLE\ORADATA\ZERO\TEMP2.ORA' RESIZE 67m
*
ERROR 位于第 1 行:
orA-03297: 文件包含在请求的 RESIZE 值以外使用的数据

SQL>

切换回原有的temp表空间，并重启数据库：

SQL> Alter DATABASE DEFAULT
  2      TEMPORARY TABLESPACE "TEMP";

数据库已更改。
SQL> shutdown immediate;
数据库已经关闭。
已经卸载数据库。
orACLE 例程已经关闭。
SQL> startup;
orACLE 例程已经启动。

Total System Global Area  135338868 bytes
Fixed Size                   453492 bytes
Variable Size             109051904 bytes
Database Buffers           25165824 bytes
Redo Buffers                 667648 bytes
数据库装载完毕。
数据库已经打开。
SQL>
SQL> drop  TABLESPACE temp2 including contents and datafiles;

表空间已丢弃。

目前从表象看temp表空间的已使用为0，但是执行如下脚本：

SQL> Select * From test.sal_salary ss order By ss.jsdjgz;
执行完之后，temp表空间的已用变为894M。

结果证明在重启数据库之后其实oracle并没有释放temp表空间被占用的部分，虽然从表象看是已经释放了，但是一旦再次有问题排序出现，马上temp表空间的大小就增大至上次释放之前的大小。不知道这个到底是Oracle该版本的bug还是Oracle就是这么处理temp表空间的。

6、重建表空间：
C:\Documents and Settings\zero>sqlplus "/ as sysdba"

SQL*Plus: Release 9.2.0.1.0 - Production on 星期五 12月 7 18:23:03 2007

Copyright (c) 1982, 2002, oracle Corporation.  All rights reserved.

连接到:
oracle9i Enterprise Edition Release 9.2.0.1.0 - Production
With the Partitioning, OLAP and oracle Data Mining options
JServer Release 9.2.0.1.0 - Production

SQL> Create
  2      TEMPORARY TABLESPACE "TEMP2" TEMPFILE
  3      'D:\ORACLE\ORADATA\ZERO\TEMP2.ora' SIZE 200M EXTENT
  4      MANAGEMENT LOCAL UNIFORM SIZE 1M;

表空间已创建。

SQL> Alter DATABASE DEFAULT TEMPORARY TABLESPACE "TEMP2";

数据库已更改。
SQL> drop tablespace temp including contents and datafiles;

表空间已丢弃。

SQL> Create
  2      TEMPORARY TABLESPACE "TEMP" TEMPFILE
  3      'D:\ORACLE\ORADATA\ZERO\TEMP1.ora' SIZE 200M REUSE AUTOEXTEND
  4      ON NEXT  100M MAXSIZE UNLIMITED EXTENT MANAGEMENT LOCAL
  5      UNIFORM SIZE 1024K;

表空间已创建。

SQL> Alter DATABASE DEFAULT TEMPORARY TABLESPACE "TEMP";

数据库已更改。

SQL> drop tablespace temp2 including contents and datafiles;

表空间已丢弃。

SQL>
至此关于temp表空间的历险结束了，虽然最终没有达到我所想的手动释放表空间的效果，不过还是有收获的，发贴以供大家讨论，谢谢！]]>

http://kanoe.cn/default.asp?id=197 <![CDATA[oracle的recyclebin:类似BIN$4UCNzAupjLYOaRzow==$0的对象]]> 独木舟 http://kanoe.cn/ master@kanoe.cn 2010-02-12T18:05:26+08:00 2010-02-12T18:05:26+08:00

2、删除的表系统会自动给他重命名就是你看到的【BIN$】开头的名字

3、通过 show recyclebin 命令可以查看被删掉的表的详细信息，或者查询
select * from recyclebin;

4、收回表的命令：
   flashback table 原表名 to before drop;

5、清空回收站的命令：
   purge recyclebin;

6、如果不想删除的表经过回收站
   drop table 表名 purge;
   或者停用数据库的回收战功能
   10.1版本中，修改隐藏参数 _recyclebin
      alter system set "_recyclebin" = false;
   10.2版本中，
      alter system set recyclebin = off;
]]>

http://kanoe.cn/default.asp?id=196 <![CDATA[缩小数据文件尺寸报ORA-03297的处理办法[转]]]> 独木舟 http://kanoe.cn/ master@kanoe.cn 2010-02-12T17:57:46+08:00 2010-02-12T17:57:46+08:00

使用Alter TABLE table SHRINK SPACE CASCAD后大部分数据文件可以调整，当试图调整其中一个数据文件尺寸的时候报
RA-03297: file contains used data beyond requested RESIZE value
说明这个文件不能通过降低hwm来释放空间了。

数据库版本：oracle 10.2.1
--找到数据文件对应的文件号
SQL>select file#,name from v$datafile where name like '%BASEINFO.dbf';
5                  /data/eucpdb/eucpdb/BASEINFO.dbf

找到文件中最大的块号
SQL>select max(block_id) from dba_extents where file_id=5 ；

1213833

--查看数据库块大小
SQL>show parameter db_block_size

db_block_size integer 8192

计算一下文件中最大使用块占用的位置
SQL>select 1213833*8/1024 from dual;

9483.0703125 M

--为了验证上面做法的准确性，下面做一个试验

--调整前数据文件大小为10000M
--现在调整数据库文件为9500M
SQL>Alter DATABASE DATAFILE '/data/eucpdb/eucpdb/BASEINFO.dbf' RESIZE 9500M
  2  /

数据库已更改

--调整文件为 9400m

SQL>Alter DATABASE DATAFILE '/data/eucpdb/eucpdb/BASEINFO.dbf' RESIZE 9400M
  2  /

SQL> Alter DATABASE DATAFILE '/data/eucpdb/eucpdb/BASEINFO.dbf' RESIZE 9400M;
Alter DATABASE DATAFILE '/data/eucpdb/eucpdb/BASEINFO.dbf' RESIZE 9400M
*
第 1 行出现错误:
orA-03297: 文件包含在请求的 RESIZE 值以外使用的数据

--看来了上面的计算是准确的

SQL> col segment_name format a30
SQL> SET LIN 200
SQL> select segment_name,segment_type,tablespace_name,extent_id,bytes,blocks from dba_extents where file_id=5 and   block_id='1213833';

SEGMENT_NAME                   SEGMENT_TYPE       TABLESPACE_NAME                 EXTENT_ID      BYTES     BLOCKS
------------------------------ ------------------ ------------------------------ ---------- ---------- ----------
REGISTRYINFO                   TABLE              BASEINFO                               25     524288         64

SQL>

SQL>  Alter TABLE eucpmanager.REGISTRYINFO SHRINK SPACE CASCADE;

表已更改。

创建一个新的表空间，把block_id比较高的几个表移出表空间

SQL> Create SMALLFILE TABLESPACE "BASEINFO_BAK" DATAFILE '/data/eucpdb/eucpdb/baseinfo_bak.dbf' SIZE 100M LOGGING EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO
  2  /

表空间已创建。

SQL> alter user eucpmanager quota unlimited on BASEINFO_BAK;

用户已更改。

把block_id比较高的几个表移动到新的表空间

Select DISTINCT SEGMENT_NAME FROM DBA_EXTENTS Where TABLESPACE_NAME='BASEINFO' AND FILE_ID=5 and block_id>1159985 and segment_type='TABLE' ;

SQL> Select distinct  'alter table '|| SEGMENT_NAME||' move tablespace baseinfo_bak; ' FROM DBA_EXTENTS Where TABLESPACE_NAME='BASEINFO' AND FILE_ID=5 and block_id>1159985 and segment_type='TABLE' ;

'AlterTABLE'||SEGMENT_NAME||'MOVETABLESPACEBASEINFO_BAK;'
----------------------------------------------------------------------------------------------------------------------------
alter table ENTERPRISESERVICEINFO move tablespace baseinfo_bak;
alter table REGISTRYFEEDETAILEX move tablespace baseinfo_bak;
alter table ENTERPRISEROUTE move tablespace baseinfo_bak;
alter table REGISTRYAUTHINFO move tablespace baseinfo_bak;
alter table ENTERPRISEBASEINFO move tablespace baseinfo_bak;

SQL> alter table ENTERPRISESERVICEINFO move tablespace baseinfo_bak;
alter table REGISTRYFEEDETAILEX move tablespace baseinfo_bak;
alter table ENTERPRISEROUTE move tablespace baseinfo_bak;
alter table REGISTRYAUTHINFO move tablespace baseinfo_bak;
alter table ENTERPRISEBASEINFO move tablespace baseinfo_bak;
表已更改。

SQL>
表已更改。

SQL>
表已更改。

SQL>
表已更改。

告警日志中会出现下面的内容，索引需要重建
Thu Apr 24 14:20:21 2008
Some indexes or index [sub]partitions of table EUCPMANAGER.ENTERPRISEBASEINFO have been marked unusable

把下面的执行结果的语句执行所有重建
Select distinct  'alter INDEX '|| SEGMENT_NAME||' REBUILD TABLESPACE BASEINFO_BAK; ' FROM DBA_EXTENTS Where TABLESPACE_NAME='BASEINFO' AND FILE_ID=5 and block_id>1159985 and segment_type='INDEX' ;

alter INDEX PK_ENTERPRISEBASEINFO REBUILD TABLESPACE BASEINFO_BAK;
alter INDEX PK_REGISTRYINFO REBUILD TABLESPACE BASEINFO_BAK;
alter INDEX PK_REGISTRYFEEDETAILEX REBUILD TABLESPACE BASEINFO_BAK;
alter INDEX UNI_REGISTRYAUTHINFO REBUILD TABLESPACE BASEINFO_BAK;
alter INDEX UNI_REGISTRYAUTHINFO REBUILD TABLESPACE BASEINFO_BAK;
alter INDEX UNI_REGISTRYAUTHINFO REBUILD TABLESPACE BASEINFO_BAK;
alter INDEX UNI_REGISTRYAUTHINFO REBUILD TABLESPACE BASEINFO_BAK;
alter INDEX UNI_REGISTRYAUTHINFO REBUILD TABLESPACE BASEINFO_BAK;

再次修改数据文件大小

SQL>  select max(block_id) from dba_extents where file_id=5 ;

MAX(BLOCK_ID)
-------------
         3209

SQL> Alter DATABASE DATAFILE '/data/eucpdb/eucpdb/BASEINFO.dbf' RESIZE 1000m;

数据库已更改。

数据库文件的空间已经调整成功了

SQL>

--把挪走的表在挪回来

SQL> alter table ENTERPRISESERVICEINFO move tablespace baseinfo;
alter table REGISTRYFEEDETAILEX move tablespace baseinfo;
alter table ENTERPRISEROUTE move tablespace baseinfo;
alter table REGISTRYAUTHINFO move tablespace baseinfo;
alter table ENTERPRISEBASEINFO move tablespace baseinfo;
alter table registryinfo move tablespace baseinfo;
表已更改。

SQL>
表已更改。

--重建索引
SQL>
SQL>
SQL> Alter INDEX PK_REGISTRYINFO REBUILD TABLESPACE BASEINFO;
Alter INDEX AK_REGISTRYCODE_REGISTRYINFO REBUILD TABLESPACE BASEINFO;
Alter INDEX PK_ENTERPRISEBASEINFO REBUILD TABLESPACE BASEINFO;
Alter INDEX PK_ENTERPRISESERVICEINFO REBUILD TABLESPACE BASEINFO;
Alter INDEX UNI_REGISTRYAUTHINFO REBUILD TABLESPACE BASEINFO;
Alter INDEX PK_REGISTRYFEEDETAILEX REBUILD TABLESPACE BASEINFO;

索引已更改。

SQL> Select COUNT(*) FROM DBA_SEGMENTS Where TABLESPACE_NAME='BASEINFO_BAK' ;

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

已经没有对象在新建的这个表空间了。现在删除掉

SQL> drop tablespace baseinfo_bak;

表空间已删除。

到此调整已经结束了。
其实调整方法有很多，如用imp/exp等
如果我的做法有什么不足之处请执教，谁有更好的办法欢迎提供，本人水平有限。
]]>

http://kanoe.cn/default.asp?id=195