mengxb001

topas KBPS问题 查看全文

AIX Version 5.1

$uptime
09:03AM up 13723 days, 1:01, 3 users, load average: 3.02, 3.05, 3.42

这个主机已经运行了37.5年了！

今天在AIX主机上的主机碰到问题了，undo慢了后，报错，查询dba_undo_extents报ORA-00600错误，在metalink上查看是一个在9205上的一个已知的bug，查看一下竟然没有针对IBM的补丁，如果要姐姐只能升级到大版本。

在什么情况下,oracle会认为已经统计的信息失效 查看全文

自己今天了下copy的试验，采用两个实例，copy采用不同方式(create,insert,append,replace)测试过程中，copy一个10G大小大的表，undo的freespace不足100M，过程中发现undo一直在变化，证实了copy和dml操作是同应的效果，看来还是采用DB_LINK＋DDL倒数据的好，copy的一个优点就是可以分批提交，可以减少对网络的压力。

select 'alter system kill session '||chr(39)||sid||','||serial#||chr(39)||';' from v$session

=

select 'alter system kill session '||''''||sid||','||serial#||''''||';' from v$session

用wrap命令，如（假定你的存储过程保存为a.sql）
wrap iname=a.sql
PL/SQL Wrapper: Release 9.2.0.1.0 - Production on Tue JAN 16 22:26:48 2007
Copyright (c) Oracle Corporation 1998, 2000. All Rights Reserved.
Processing a.sql to a.plb
提示a.sql转换为a.plb，这就是加密了的脚本，执行a.plb即可生成加密了的存储过程

SQL> select * from test;

A B C
---------- ---------- ----------
11 1 .5
11 2 .21
11 3 .25
12 1 .24
12 2 .3
12 3 .22

6 rows selected.

SQL> select a,
2 sum(decode(b,1,c)) xiangmu1,
3 sum(decode(b,2,c)) xiangmu2,
4 sum(decode(c,3,c)) xiangmu3
5 from test
6 group by a;

A XIANGMU1 XIANGMU2 XIANGMU3
---------- ---------- ---------- ----------
11 .5 .21
12 .24 .3

SQL> l
1 select a,
2 sum(decode(b,1,c)) xiangmu1,
3 sum(decode(b,2,c)) xiangmu2,
4 sum(decode(c,3,c)) xiangmu3
5 from test
6* group by a
SQL> l4
4* sum(decode(c,3,c)) xiangmu3
SQL> c/sum(decode(c,3,c))/sum(decode(b,3,c))
4* sum(decode(b,3,c)) xiangmu3
SQL> l
1 select a,
2 sum(decode(b,1,c)) xiangmu1,
3 sum(decode(b,2,c)) xiangmu2,
4 sum(decode(b,3,c)) xiangmu3
5 from test
6* group by a
SQL> r
1 select a,
2 sum(decode(b,1,c)) xiangmu1,
3 sum(decode(b,2,c)) xiangmu2,
4 sum(decode(b,3,c)) xiangmu3
5 from test
6* group by a

A XIANGMU1 XIANGMU2 XIANGMU3
---------- ---------- ---------- ----------
11 .5 .21 .25
12 .24 .3 .22

cp之间没有设置字符集，导致倒进去的数据显示为乱码

length是字的长度，lengthb是字节的长度，字符集为UTF8

SQL> create table test(a varchar2(20));

Table created

SQL> insert into test values('2');

1 row inserted

SQL> insert into test values('12');

1 row inserted

SQL> insert into test values('四大皆空');

1 row inserted

SQL> commit;

Commit complete

SQL> select * from test;

A
--------------------
2
12
四大皆空

SQL> select a from test where length(a)!=lengthb(a);

A
--------------------
四大皆空

SQL> select a from test where asciistr(a) not like '%%';

A
--------------------
2
12

SQL> select a from test where asciistr(a) like '%%';

A
--------------------
四大皆空

SQL>

有人说SQL*Plus Copy Command复制数据时不经过Buffer，不写回滚段，copy不产生undo，所以速度是非常快的,但是还是产生大量的归档，比CTAS还要大；而有人经过实验发现SQL*Plus Copy Command并不像想象中的那么快，甚至慢得让人难以接受。对于数据的复制，我也曾经测试过CTAS这种方法还是不错的，不会产生undo，CTAS是ddl操作，速度应该是最快的，不过CTAS过程中会用到temp表空间，难道真是象drop表一样，先把表改成temp表交给smon处理。copy具体测试步骤如下：

今天自己电脑上面测试数据库，一个数据文件坏了，非system表空间，我干脆就把那个文件给删掉了，打开后出错，使用alter database create datafile添加文件，然后recover datafile解决。后来自己测试了一下在resetlogs前创建的表空间，是无法使用这种方法恢复的，看来resetlogs还是要谨慎使用。

SQL> startup
ORACLE 例程已经启动。
Total System Global Area 43063740 bytes
Fixed Size 453052 bytes
Variable Size 33554432 bytes
Database Buffers 8388608 bytes
Redo Buffers 667648 bytes
数据库装载完毕。
ORA-01157: 无法标识/锁定数据文件 3 - 请参阅 DBWR 跟踪文件
ORA-01110: 数据文件 3: 'D:ORACLEORADATATESTUSERS01.DBF'
SQL> alter database create datafile 'D:ORACLEORADATATESTUSERS01.DBF'
2 as 'D:ORACLEORADATATESTUSERS01.DBF';

数据库已更改。

SQL> recover datafile 3;
完成介质恢复。
SQL> alter database open;

数据库已更改。

测试步骤如下：

Oracle9i开始引入在线重定义表(Redefine Tables Online)的功能,通过调用dbms_redefinition包，可以在修改表结构的同时允许DML操作。

在线重定义表的主要功能：

• 修改表的存储参数
• 在同一个schema下将表移动到不同的tablespace
• 增加并行查询支持
• 添加或删除分区支持
• 重建表以减少碎片
• 将堆表变为索引组织表或相反
• 添加或删除列

在线重定义表的需要以下权限：

• execute_catalog_role
• create any table
• alter any table
• drop any table
• lock any table
• select any table

在线重定义后的结果:

• 原表已经根据中间表的结构重新定义
• 在start_redef_table()和finish_redef_table()之间定义在中间表上的触发器、索引、约束和授权，现在定义在原始重定义表上。中间表上disabled的约束在原始表上处于enabled状态。
• 原始表上定义的触发器、索引、约束和授权建立在中间表上，并会在删除中间表时删除。原始表上原来enabled状态的索引，建立在中间表上，并处于disabled状态。
• 任何定义在原始表上的存储过程和游标都会变为INVALID，当下次调用时后自动进行编译。
• 如果执行过程中出现错误或者人为选择退出的话，可以执行DBMS_REDEFINITION.ABORT_REDEF_TABLE()过程。

在线重定义的一些限制：

• 如果使用基于主键的方式，则原表后重定义后的表必须有相同的主键
• 如果使用基于ROWID的方式，则不能是索引组织表
• 如果原表上有物化视图或者物化视图日志，则不能在线重定义
• 物化视图容器表或者高级队列表不能在线重定义
• 索引组织表的溢出表不能在线重定义
• 拥有BFILE，LOGN列的表不能在线重定义
• Cluster中的表不能在线重定义
• sys和system下的表不能在线重定义
• 临时表不能在线重定义
• 不支持水平数据子集
• 在列映射时只能使用有确定结果的表达式，如子查询就不行
• 如果中间表有新增列，则不能有NOT NULL约束
• 原表和中间表之间不能有引用完整性
• 在线重定义无法采用nologging

SELECT DBMS_METADATA.GET_DDL('USER','TEST') FROM dual

SELECT DBMS_METADATA.GET_GRANTED_DDL('ROLE_GRANT','TEST') FROM dual

SELECT DBMS_METADATA.GET_GRANTED_DDL('SYSTEM_GRANT','TEST') FROM dual

SELECT DBMS_METADATA.GET_GRANTED_DDL('OBJECT_GRANT','TEST') FROM dual

增加freelists可以减少等待时间，多个freelists导致所需的空间比绝对的要多，测试过程如下： 查看全文

alter table test move后面如果不加表空间，默认是当前的表空间

前阵子看到index表空间居高不下，即使是delete也不会释放index表空间，truncate 可以释放index表空间，delete是无法释放index看来应该是高水位应该有关系。对于index自己进行了一下测试，发现采用相同数据index表空间没有变化，采用不同数据时候index表空间增长，index表空间可以采用rebuild和truncate方法释放index表空间。测试步骤如下： 查看全文

前阵子看到索引一直居高不下，所以个人做了如下测试，测试思路主要是插入数据删掉后再插入数据(相同和不同两种)查看索引的使用情况增长还是不便，测试后发现使用相同数据，索引占用空间不会增长，使用不同数据发现索引占用表空间会增长。delete和update时候索引也会更新，索引表空间会增长，要解决索引中的碎片，可以rebuild index。

前阵子在pub中看到一个网友关于迁移的问题，从as3 32位到as3 64位，没有环境测试，oracle是支持文件直接拷贝的，拷贝完毕后编译一下就可以，迁移过去可能会出现一些存储过程不能用，执行一下utlrp.sql即可

xzh2000在oracle中国发了这么一个sql，感到很疑惑：

前阵子碰到一个select系统表慢的问题，不知道到底什么原因，在网上搜索了一下，看到好几年前的一个老帖子chao_ping曾经提到关于这个问题，不过也不是很肯定到底是不是move了系统表的问题，chao_ping说oracle也不支持移动系统表，有可能出现问题，于是在pub中发了帖子，问关于表是否被move过，bt给出了一个看的方法，不过也不能肯定一定是被move过，不过表被move过肯定object_id 和 data_object_id 是不一致，表被truncate过也是不一致的，看来表被move过是没有办法查看了

set serveroutput on size 20000
set linesize 80

declare
cursor c_map(p_file_id number) is
(select file_id,block_id,blocks,'X' used
from dba_extents where file_id=p_file_id
union
select file_id,block_id,blocks,'=' used
from dba_free_space where file_id=p_file_id
) order by 1,2,3;
cursor c_file is
select file_name,file_id,blocks/400 bsize from dba_data_files;
j number :=1;
xsize number;
begin
for r_file in c_file
loop
dbms_output.put_line('Map of '||r_file.file_name);
for r_map in c_map(r_file.file_id)
loop
for i in 1..r_map.blocks/r_file.bsize
loop
dbms_output.put(R_MAP.USED);
if j>=80 then
j :=1;dbms_output.new_line;
else
j := j+1;
end if;
end loop;
end loop;
dbms_output.new_line;j:=1;
end loop;
end;
/

最近发的帖子少了，再看一些dmt和lmt东西，数据库空间不够下载10g时候把9i也一起搞掉了，搞了一天才搞好，dmt表空间管理方式必须是系统表空间是dmt管理表空间管理方式，才可以建立dmt的表空间，同时也可以建lmt的空间。在dmt方式下permanent和temporary表空间都可以使用alter system coalesce收缩表空间，还可以实现之间相互转换，dmt是通过修改数据字典管理表空间，存在一些性能问题，要实现dmt到lmt转换，建议不要使用dbms_space_admin.TABLESPACE_MIGRATE_TO_LOCAL转换，这样也没有消除碎块，建议采用alter table move的办法。

lmt 有很大优越性，但我觉得也缺少了一些灵活性。比如：
在dmt模式下，可以限制某个表的最大extents 值 ，但在lmt下就实现不了了！

最近有很多垃圾评论，关闭评论功能

unix:
[/app/oracle]$ exp user/user tables=test query="where a=3" file=/app/oracle/test.dmp log=/app/oracle/test.log

Export: Release 9.2.0.5.0 - Production on Fri Jan 19 14:29:58 2007

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

Connected to: Oracle9i Enterprise Edition Release 9.2.0.5.0 - 64bit Production
With the Partitioning, Oracle Label Security, OLAP and Oracle Data Mining options
JServer Release 9.2.0.5.0 - Production
Export done in US7ASCII character set and UTF8 NCHAR character set
server uses UTF8 character set (possible charset conversion)

About to export specified tables via Conventional Path ...
. . exporting table TEST 1 rows exported
Export terminated successfully without warnings.

window:
C:>exp test/test@xb tables=test query="where a=1" file=d:test.dmp log=d:tes
t.log

Export: Release 9.2.0.1.0 - Production on 星期三 12月 20 14:41:46 2006

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
已导出 ZHS16GBK 字符集和 AL16UTF16 NCHAR 字符集

即将导出指定的表通过常规路径 ...
. . 正在导出表 TEST 2 行被导出
在没有警告的情况下成功终止导出。

Dependent on operating system and database creation options; maximum of 20,000 x (database block size)

以8K为例子：

controlfile size=20000*8/1024=156.25M

When does SMON coalesce?

o. SMON wakes itself every 5 minutes and checks for tablespaces with
default pctincrease != 0.

How to identify whether SMON is coalescing

o. Check whether there are a large number of free extents that might
be being coalesced by running the following query a few times:

SELECT COUNT(*) FROM DBA_FREE_SPACE;

If the count returned is dropping while SMON is working, it is
likely that SMON is coalescing free space.

The DROP_SEGMENTS event
~~~~~~~~~~~~~~~~~~~~~~~
Available from 8.0 onwards.

DESCRIPTION
Finds all the temporary segments in a tablespace which are not
currently locked and drops them.
For the purpose of this event a "temp" segment is defined as a
segment (seg$ entry) with TYPE#=3. Sort space in a TEMPORARY
tablespace does not qualify under this definition as such
space is managed independently of SEG$ entries.

PARAMETERS
level - tablespace number+1. If the value is 2147483647 then
temp segments in ALL tablespaces are dropped, otherwise, only
segments in a tablespace whose number is equal to the LEVEL
specification are dropped.

NOTES
This routine does what SMON does in the background, i.e. drops
temporary segments. It is provided as a manual intervention tool which
the user may invoke if SMON misses the post and does not get to
clean the temp segments for another 2 hours. We do not know whether
missed post is a real possibility or more theoretical situation, so
we provide this event as an insurance against SMON misbehaviour.

Under normal operation there is no need to use this event.

It may be a good idea to
alter tablespace <tablespace> coalesce;
after dropping lots of extents to tidy things up.

*SQL Session (if you can connect to the database):
alter session set events 'immediate trace name DROP_SEGMENTS level TS#+1';

The TS# can be obtained from v$tablespace view:
select ts# from v$tablespace where name = '<Tablespace name>';

Or from SYS.TS$:

select ts# from sys.ts$ where name = '<Tablespace name>' and online$ != 3;

If ts# is 5, an example of dropping the temporary segments in that tablespace
would be:

alter session set events 'immediate trace name DROP_SEGMENTS level 6';

set define off解决

缓冲区高速缓冲中的块基本上在两个不同的列表中管理。块的赃列，需要用数据库DBWn写入。随后，是一个不脏的块的列表。在过去oracle8以及以前版本是最近最少使用（Least Recently Used，LRU）列表。块以使用的顺序列出。在8i以后版本中，算法略有改动。不在使用过去的以某种物理顺序排列的块列表，oracle8i使用了一个"接触技术"计划。每次在缓存中接触一个块时候，它有效的增加与块的计数器。
SELECT FILE_ID,BLOCK_ID FROM DBA_EXTENTS WEHRE SEGMENT_NAME='&TABLE_NAME' AND OWNER='&OWNER'
SELECT TCH FROM X$BH WHERE FILE#=&FILE_ID AND DBABLK=&BLOCK_ID
每次接触那个块，计数会上升。缓存不再象以前那样移动到表的头部，它停留在它在表中的位置，接触技术增加，块将自然的趋向于在表中不时的移动，以为块从列表取出，并且放到了脏表。同时，当他们重用时，当缓冲区高速缓存实际上充满时，一些带有小的接触技术的块背从列表中取出，它将以新的数据替换列表中适合的地方。用于管理这些列表中的全部算法相当复杂，频繁 使用的块将被高速缓冲存储，使用不频繁的块不会长时间在高速缓冲存储。

9I：

RESETLOGS

Specify RESETLOGS to reset the current log sequence number to 1 and discards any redo information that was not applied during recovery, ensuring that it will never be applied. This effectively discards all changes that are in the redo log, but not in the database.

You must specify RESETLOGS to open the database after performing media recovery with an incomplete recovery using the RECOVER clause or with a backup control file. After opening the database with this clause, you should perform a complete database backup.

10G：

RESETLOGS | NORESETLOGS This clause determines whether Oracle Database resets the current log sequence number to 1, archives any unarchived logs (including the current log), and discards any redo information that was not applied during recovery, ensuring that it will never be applied. Oracle Database uses NORESETLOGS automatically except in the following specific situations, which require a setting for this clause:

You must specify RESETLOGS:

After performing incomplete media recovery or media recovery using a backup controlfile

After a previous OPEN RESETLOGS operation that did not complete

After a FLASHBACK DATABASE operation

If a created controlfile is mounted, then you must specify RESETLOGS if the online logs are lost, or you must specify NORESETLOGS if they are not lost.

以前很少碰到过lob这样类型的字段，最近出现中出现了很多LOBSEGMENT，而且占有很大的表空间，lob类型的字段由数据库自动管理，一个字段对应一个LOBSEGMENT和一个LOBINDEX， 在dba_segment中看到的表大小不包括lob字段的大小。

由于lob segment采用了自己特殊的一致性读的实现，不是使用undo tablespace来保留前映象，而是当发生update时在lob segment内分配一个chunk去插入一条新的记录。这样的话，如果一条记录修改了多次，那么它就存在多个版本，对于很大的lob对象来说，这是十分浪费空间的。所以oracle需要有一个办法来控制这个保留前映象的空间的大小，pctversion就是为了实现这个功能的。pctversion是一个百分比的值，就是当前所有lob空间中用来存放前映象的百分比，如果前映象的空间大于pctversion了，那么oracle将会重用这些前映象空间而不去扩展。

注意：关于lob的retention参数,这个与undo表空间的undo_retention是一致的,如果你的lob更新较小,就可以通过修改undo_retention来调整lob前映象的失效时间,由于lob的retention参数是与undo_retention保持一致,所以修改undo_retention来说,一定要慎重,毕竟它将会影响库中所有lob字段的retention参数.

最近不知道怎么搞的自己电脑总是有一些文件丢失，没有办法只有解决啊。今天碰到了undo没有了，只好使用undo_management=MANUAL，offline后重建了，步骤如下：

SQL> startup pfile='D:oracleadminmengpfileinit.ora'
ORACLE 例程已经启动。

Total System Global Area 135338868 bytes
Fixed Size 453492 bytes
Variable Size 109051904 bytes
Database Buffers 25165824 bytes
Redo Buffers 667648 bytes
数据库装载完毕。
ORA-01157: 无法标识/锁定数据文件 6 - 请参阅 DBWR 跟踪文件
ORA-01110: 数据文件 6: 'D:ORACLEORADATAMENGUNDOTBS01.DBF'

SQL> alter database datafile 6 offline drop;

数据库已更改。

SQL> show parameter undo

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_management string MANUAL
undo_retention integer 10800
undo_suppress_errors boolean FALSE
undo_tablespace string UNDO

SQL> alter database open;

数据库已更改。

SQL> create undo tablespace undo datafile 'D:oracleoradatamengundo01.dbf' size 200M autoextend off;

表空间已创建。

SQL> drop tablespace undotbs1;

表空间已丢弃。

SQL> create spfile from pfile='D:oracleadminmengpfileinit.ora';

文件已创建。

SQL> startup force
ORACLE 例程已经启动。

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

NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_management string MANUAL
undo_retention integer 10800
undo_suppress_errors boolean FALSE
undo_tablespace string UNDO
SQL> alter system set undo_management=AUTO scope=spfile;

系统已更改。

SQL> startup force
ORACLE 例程已经启动。

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

最近电脑不知道怎么就把当前的redo搞没有了，数据库是归档模式下的，但是没有全库备份，没有办法了，就使用强制性恢复，在init.ora中加入_allow_resetlogs_corruption=TRUE

恢复步骤如下：

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
数据库装载完毕。
ORA-00313: 无法打开日志组 2 (线程 1) 的成员
ORA-00312: 联机日志 2 线程 1: 'D:ORACLEORADATAMENGREDO02.LOG'
SQL> shutdown immediate;
ORA-01109: 数据库未打开
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup pfile='D:oracleadminmengpfileinit.ora'
ORACLE 例程已经启动。

Total System Global Area 135338868 bytes
Fixed Size 453492 bytes
Variable Size 109051904 bytes
Database Buffers 25165824 bytes
Redo Buffers 667648 bytes
数据库装载完毕。
ORA-00313: 无法打开日志组 2 (线程 1) 的成员
ORA-00312: 联机日志 2 线程 1: 'D:ORACLEORADATAMENGREDO02.LOG'

SQL> recover database until cancel;
完成介质恢复。
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR 位于第 1 行:
ORA-01092: ORACLE 例程终止。强行断开连接
至此恢复完毕，在resetlogs时候出现什么错误不要管，查找资料的时候强调一定要恢复后做个export，由于是个人测试环境就不管那么多，看看究竟能出现什么问题。

在有些时候我们可能因为种种原因需要迁移数据从一个DB到另外一个DB，DBA不知道所有的密码。当然我们可以告诉user新设定的password，可是对user来说可能不是很方便。我们可以采用简单的方法来实现恢复原来DB中的密码。通过一下方法来实现：

SQL> select 'alter user '||username||' identified by values '||password||''';'pw

from dba_users
SQL>

pw
--------------------------------------------------------------------------------
alter user SYS identified by values 'CACE121A6C13E121';
alter user SYSTEM identified by values '775951FD7097488E';
alter user DBSNMP identified by values 'E066D214D5421CCC';
alter user ARBOR identified by values '02FB980C90504CCE';
alter user TEST3 identified by values '970BAC04038635CD';
alter user PERFSTAT identified by values 'AC98877DE1297365';
alter user TOAD identified by values '4759257F78A8B5A3';
alter user MXB identified by values '66DEFEE314A63D8D';
alter user TEST6 identified by values '0AE1AAE2C08CD499';
alter user OUTLN identified by values '4A3BA55E08595C81';
alter user WMSYS identified by values '7C9BA362F8314299';

大家都知道在我们建立含有lob字段的表时，oracle会自动为lob字段建立两个单独的segment,一个用来存放数据，另一个用来存放索引，并且它们都会存储在对应表指定的表空间中。但是当我们用alter table tb_name move tablespace tbs_name;来对表做空间迁移时只能移动非lob字段以外的数据，而如果我们要同时移动lob相关字段的数据，我们就必需用如下的含有特殊参数据的文句来完成，它就是： alter table tb_name move tablespace tbs_name lob (col_lob1,col_lob2) store as(tablesapce tbs_name); 下面我们来看一个例子吧

SQL>select OWNER,SEGMENT_NAME,SEGMENT_TYPE,TABLESPACE_NAME from dba_segments where owner='TEST6'

OWNER SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME
----- ------------------------------ ------------------ ------------------------
TEST6 TEST_LOB TABLE TEST
TEST6 SYS_IL0000015539C00001$$ LOBINDEX TEST
TEST6 SYS_IL0000015539C00002$$ LOBINDEX TEST
TEST6 SYS_LOB0000015539C00001$$ LOBSEGMENT TEST
TEST6 SYS_LOB0000015539C00002$$ LOBSEGMENT TEST
SQL>alter table test6.test_lob move tablespace test1

Table altered.

SQL>select OWNER,SEGMENT_NAME,SEGMENT_TYPE,TABLESPACE_NAME from dba_segments where owner='TEST6'

OWNER SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME
----- ------------------------------ ------------------ ------------------------
TEST6 TEST_LOB TABLE TEST1
TEST6 SYS_IL0000015539C00001$$ LOBINDEX TEST
TEST6 SYS_IL0000015539C00002$$ LOBINDEX TEST
TEST6 SYS_LOB0000015539C00001$$ LOBSEGMENT TEST
TEST6 SYS_LOB0000015539C00002$$ LOBSEGMENT TEST

SQL>ALTER TABLE TEST6.TEST_LOB MOVE TABLESPACE TEST1 LOB(A,B) STORE AS(TABLESPACE TEST1);

Table altered.

SQL>select OWNER,SEGMENT_NAME,SEGMENT_TYPE,TABLESPACE_NAME from dba_segments where owner='TEST6';

OWNER SEGMENT_NAME SEGMENT_TYPE TABLESPACE_NAME
----- ------------------------------ ------------------ ------------------------
TEST6 TEST_LOB TABLE TEST1
TEST6 SYS_IL0000015539C00001$$ LOBINDEX TEST1
TEST6 SYS_IL0000015539C00002$$ LOBINDEX TEST1
TEST6 SYS_LOB0000015539C00001$$ LOBSEGMENT TEST1
TEST6 SYS_LOB0000015539C00002$$ LOBSEGMENT TEST1

在我们的DB中可能会有一些lob型的数据要来存放，我们知道它是如何存放的吗？我们知道在我们建一个表的时候，oracle对在对应的表空间在给我们一个segent中来存放数据，并且会因为数据量的增大再做扩展。但是当我们所建立的表中含有lob型的数据时，oracle会为每个lob字段生成一个独立的segment用来存放数据，同时也建立了独立的index segment .oracle对它们是单独管理的。

下面我们来看一个例子：

SQL>select owner,segment_name,segment_type from dba_segments where segment_type<>'TABLE' and owner='TEST6';
rows will be truncated

no rows selected

SQL>create table test6.test_lob(a blob,b blob);

Table created.

SQL>seelct owner,segment_name,segment_type from dba_segments where segment_type<>'TABLE' and owner='TEST6';
rows will be truncated

OWNER SEGMENT_NAME
------------------------------ -------------------------------------------------
TEST6 SYS_IL0000015534C00001$$
TEST6 SYS_IL0000015534C00002$$
TEST6 SYS_LOB0000015534C00001$$
TEST6 SYS_LOB0000015534C00002$$

SQL>drop table test6.test_lob;

Table dropped.

SQL> select owner,segment_name,segment_type from dba_segments where segment_type<>'TABLE' and owner='TEST6';
rows will be truncated

no rows selected

SELECT UTL_INADDR.GET_HOST_ADDRESS server_ip,
SYS_CONTEXT('userenv', 'ip_address') client_ip
FROM DUAL

SORT_AREA_SIZE is also used for inserts and updates to bitmap indexes. Setting this value appropriately results in a bitmap segment being updated only once for each DML operation, even if more than one row in that segment changes.

Larger values of SORT_AREA_SIZE permit more sorts to be performed in memory. If more space is required to complete the sort than will fit into the memory provided, then temporary segments on disk are used to hold the intermediate sort runs

The default is adequate for most OLTP operations. You might want to adjust this parameter for decision support systems, batch jobs, or large CREATE INDEX operations

HPUX系统日志文件位置/var/adm/syslog

今天在网上找到了一本expert one on one中文版电子书，欣喜若狂，下载后，便迫不及待的看起来，第一章 个人感觉还是感想比较多，告诉开发人员还是应该知道oracle是怎样工作的，了解锁，并发机制，TOM在稳重曾经提到“一个好的开发人员，并不一定是一个好的DBA，反之毅然”，DBA和开发人员所需的技能不同，性格也不同，文章中多次提到了关于绑定变量的问题，绑定变量确实很重要，文中提到了cursor_sharing这个参数，TOM用自己的例子证明了这个参数等于force并不是一个好的选择，从TOM的文中看出目前的开发人员对于oracle怎样工作还不是很清楚，要想做到可伸缩性确实很困难。

TOM关于锁的封锁策略：

1.只有当修改时，oracle在行级上锁定数据，不要把锁定上升倒块级或表级
2.oracle不会因为读取而锁定数据，简单读取不能在数据行上设置锁定，写入不阻塞读取
3.当一个数据写入器已经锁定了某行数据后，才阻塞其他人对该行的写入，输入的读取起不会阻塞数据的写入器

十进制和十六进制之间转换已经用了很多次，很熟悉，最近在网上看到了二进制和十进制转换感觉不错，在window下我们可以采用计算器，在unix下我们就没有办法了，只能用函数了。

十进制－十六进制

select to_char('123','xxxx') from dual;

TO_CH
-----
7b

十六进制－十进制

select to_number('ABC','xxxx') from dual;

TO_NUMBER('ABC','XXXX')
-----------------------
2748

二进制转换为十进制（此方法在9I中提供）

select bin_to_num(1,1,1,1) from dual;

BIN_TO_NUM(1,1,1,1)
-------------------
15

C:>echo %date%
2006-11-27 星期一

C:>echo %date:~1,10%
006-11-27

然后就可以在window下导出到dmp获得时间戳

exp username/pwd@orasid file=d:test-%date:0,10%.dmp

tkprof是用来分析oracle产成的跟踪文件的输出结果的可执行工具。

tkprof选项如下：

Usage: tkprof tracefile outputfile [explain= ] [table= ]
[print= ] [insert= ] [sys= ] [sort= ]
table=schema.tablename Use 'schema.tablename' with 'explain=' option.
explain=user/password Connect to ORACLE and issue EXPLAIN PLAN.
print=integer List only the first 'integer' SQL statements.
aggregate=yes|no
insert=filename List SQL statements and data inside INSERT statements.
sys=no TKPROF does not list SQL statements run as user SYS.
record=filename Record non-recursive statements found in the trace file.
waits=yes|no Record summary for any wait events found in the trace file.
sort=option Set of zero or more of the following sort options:
prscnt number of times parse was called
prscpu cpu time parsing
prsela elapsed time parsing
prsdsk number of disk reads during parse
prsqry number of buffers for consistent read during parse
prscu number of buffers for current read during parse
prsmis number of misses in library cache during parse
execnt number of execute was called
execpu cpu time spent executing
exeela elapsed time executing
exedsk number of disk reads during execute
exeqry number of buffers for consistent read during execute
execu number of buffers for current read during execute
exerow number of rows processed during execute
exemis number of library cache misses during execute
fchcnt number of times fetch was called
fchcpu cpu time spent fetching
fchela elapsed time fetching
fchdsk number of disk reads during fetch
fchqry number of buffers for consistent read during fetch
fchcu number of buffers for current read during fetch
fchrow number of rows fetched
userid userid of user that parsed the cursor

-------------------------------------------------------------

1估算表空间大小

块大小 －有效空间－有效空间百分比

2K －1958－96％

4K －4006－98％

8K －8102－99％

16K －16294－99％

2 估算索引大小

块大小 －有效空间－有效空间百分比

2K －1887－92％

4K －3935－96％

8K －8031－98％

16K －16221－99％

以表空间的为例子：

create table test(a varchar2(20),b char(20),c date)

1）每行的长度为47（注意varchar2是以实际长度为准，这里只是一个估算，以最大为准，如果有样例数据最近被分析过可以采用vsize行数统计长度，也可以看dba_tables中的avg_row_len，date占有7个字符）

2）pctfree＝10

3）行数＝10000

4）db_block_size=8K

对于8k的数据块，数据库可用的空间为8102，我们pctfree设置为10，每个数据库可以利用的空间为8102－8102×0.1＝0.89,所以10000行数据所需的空间为47×10000/1024/1024/0.89

通过10046事件看到rebuild和rebuild online是有区别的，rebuild是删掉后重建(ind_online$)，而rebuilid online是通过创建了一个中间表‘SYS_JOURNAL_15479’来实现的，不影响正常的生产活动，但是online需要占用一定的表空间，所以在online的时候应该估算下空间够不够。

在创建一个数据段时，需要指定一个pctfree值，pctfree参数通知数据库在每个数据库上保留多少剩余空间。当已经存储的数据块中的行需要update扩展长度的时候，需要使用这个空间。

如果对一个行的update操作，无法适应一个数据库，这个行可能要被移到令一个数据库，或与另一个块链接(chained)。如果存储的长度超过oracle块的大小，自动会有一个链接，并且这个连接是不可避免的，另外含有超过255行的表也总是会有行连接的，链接自然会影响性能。通过消除不必要的链接，可减少数据文件中返回数据所需要的物理读取次数。

通过创建数据段时候指定pctfree设置适合的值，就可以避免链接。

可以使用analyze命令收集有关数据库对象的统计值。基于成本的优化器，可以使用这些统计值来确定使用的最佳路径。analyze命令有一个选项，可以检测并记录表中行链接。

命令如下：

analyze table table_name list chained rows into chained_rows;

$ORACLE_HOME/rdbms/admin/utlchain.sql

在今天进行测试行链接，准备数据时候用copy loading数据，通过v$session_wait查看，看到一个log archived (needed)这样一个事件，查看数据库是归档模式的，但是log_archive_start＝false导致数据库hang住了，把数据库改未非归档模式下解决

往往我们在使用sql_trace或者10046等时间，需要查看.trc文件，下面提供两种方法：

1.oradebug setmypid;oradebug tracefile_name

2.使用sql语句

SELECT d.VALUE||'/'||LOWER(RTRIM(i.INSTANCE, CHR(0)))||'_ora_'||p.spid||'.trc' trace_file_name
FROM ( SELECT p.spid FROM sys.v$mystat m,sys.v$session s,sys.v$process p
WHERE m.statistic# = 1 AND s.SID = m.SID AND p.addr = s.paddr) p,
( SELECT t.INSTANCE FROM sys.v$thread t,sys.v$parameter v
WHERE v.NAME = 'thread' AND (v.VALUE = 0 OR t.THREAD# = TO_NUMBER(v.VALUE))) i,
( SELECT VALUE FROM sys.v$parameter WHERE NAME = 'user_dump_dest') d

个人喜欢第一种方法，便于记忆。

在eygle文件中看到了使用select dimlm from x$kccdi查看logmember个数，没有其他方法看到其他控制文件信息，今天无意中在网上看到使用oradebug方法查看控制文件信息，另外也可以使用

alter database backup controlfile to trace查看控制文件内容。

Control File是二进制文件，用普通的方法很难知道其中到底保存了什么内容，但是Oracle却提供了一个SQL*PLUS命令来将Control File的内容dump到文本文件中。

方法如下： 以SYSDBA身份登入SQL*PLUS

SQL> oradebug setmypid

SQL> oradebug dump controlf 3

将把control file dump到USER_DUMP_DEST初始化参数指定的目录下。

其中3为dump level。 level的解释如下：

1 ：only the file header

2 ：just the file header, the database info record, and checkpoint progress records

3 ：all record types, but just the earliest and latest records for circular reuse record types

4 ：as above, but includes the 4 most recent records for circular reuse record types

5+ ：as above, but the number of circular reuse records included doubles with each level