老熊的三分地-Oracle、UNIX

我们知道，在Oracle 10g中，如果数据库实例hang住了，应用及sqlplus都不能连接时，可以用sqlplus -prelim连接数据库。那么sqlplus连接时，加上-prelim这个参数有什么特别的地方呢？下面，让我们来研究一下：

测试环境：Linux AS4上的Oracle 10.2.0.1，客户端(sqlplus)版本为Windows 2003下的10.2.0.1。

首先在数据库上启用10046事件：

SQL> alter system set events ‘10046 trace name context forever’;

System altered.

先用普通的方式连接：

D:\>sqlplus /nolog

SQL*Plus: Release 10.2.0.1.0 - Production on 星期六 11月 15 15:36:02 2008

Copyright (c) 1982, 2005, Oracle. All rights reserved.

SQL> conn sys/manage@xty as sysdba
已连接。
SQL> exit
从 Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production
With the Partitioning, OLAP and Data Mining options 断开

再看看加prelim参数时的情况：

D:\>sqlplus -prelim /nolog

SQL*Plus: Release 10.2.0.1.0 - Production on 星期六 11月 15 15:36:34 2008

Copyright (c) 1982, 2005, Oracle. All rights reserved.

SQL> conn sys/manage@xty as sysdba
初级连接已建立
SQL> exit
从 ORACLE 断开

从上面的信息可以看到，在使用prelim连接时，提示为“初级连接已建立”，退出sqlplus没有显示banner。
再看看数据库的10046 trace：

从生成的trace文件中，可以发现在正常连接时，连接上数据库后，sqlplus自动执行了下面的SQL：

ALTER SESSION SET NLS_LANGUAGE= ‘SIMPLIFIED CHINESE’ NLS_TERRITORY= ‘CHINA’ NLS_CURRENCY= ‘￥’ NLS_ISO_CURRENCY= ‘CHINA’ NLS_NUMERIC_CHARACTERS= ‘.,’ NLS_CALENDAR= ‘GREGORIAN’ NLS_DATE_FORMAT= ‘DD-MON-RR’ NLS_DATE_LANGUAGE= ‘SIMPLIFIED CHINESE’ NLS_SORT= ‘BINARY’ TIME_ZONE= ‘+08:00′ NLS_COMP= ‘BINARY’ NLS_DUAL_CURRENCY= ‘￥’ NLS_TIME_FORMAT= ‘HH.MI.SSXFF AM’ NLS_TIMESTAMP_FORMAT= ‘DD-MON-RR HH.MI.SSXFF AM’ NLS_TIME_TZ_FORMAT= ‘HH.MI.SSXFF AM TZR’ NLS_TIMESTAMP_TZ_FORMAT= ‘DD-MON-RR HH.MI.SSXFF AM TZR’

select value$ from props$ where name = ‘GLOBAL_DB_NAME’

select SYS_CONTEXT(’USERENV’, ‘SERVER_HOST’), SYS_CONTEXT(’USERENV’, ‘DB_UNIQUE_NAME’), SYS_CONTEXT(’USERENV’, ‘INSTANCE_NAME’), SYS_CONTEXT(’USERENV’, ‘SERVICE_NAME’), INSTANCE_NUMBER, STARTUP_TIME, SYS_CONTEXT(’USERENV’, ‘DB_DOMAIN’) from v$instance where INSTANCE_NAME=SYS_CONTEXT(’USERENV’, ‘INSTANCE_NAME’)

select decode(failover_method, NULL, 0 , ‘BASIC’, 1, ‘PRECONNECT’, 2 , ‘PREPARSE’, 4 , 0), decode(failover_type, NULL, 1 , ‘NONE’, 1 , ‘SESSION’, 2, ‘SELECT’, 4, 1), failover_retries, failover_delay, flags from service$ where name = :1

而sqlplus使用prelim连接上数据库后，没有生成10046 trace文件，看起来没有执行SQL，也就是没有执行任何初始化动作和查询必要的信息。也许这也就是称之为“初级连接”的来历吧。

由于使用prelim方式连接，没有执行sql语句的，所以在数据库的某些hang住的情况下，能够连接上数据库。比如由于library cache latch 被长时间持有不能释放，不能解析SQL语句引起的hang。有的人会说，我的应用刚连上去还没做任何操作就hang住了。这只是表面现象，连接上数据库后，一般都会做一些初始化的操作，如设定环境之类的。

sqlplus -prelim能够在数据库hang住的情况下连接数据库，但只能说是连接，并不代表能够做很多操作。比如执行SQL查询。这种情况下，可能最有用的就是使用oradebug。

本文只是简单地“inside”，其实并不很深入，Oracle还会有其他的跟prelim有关的东西，是我们还没发现的。有兴趣的朋友，可以进一步研究。比如通过抓取tns包进行分析等等。

明天，儿子就两岁了。

儿子很很喜欢飞机，天上有飞机飞过，总要抬头看看，直到看不见为止。经常缠着我们在网上找飞机图片给他看。现在至少是能分辨客机和直升机了，不过他更喜欢直升机。

儿子很喜欢建筑相关的东西，喜欢看修房子，喜欢混凝土车，喜欢挖掘车。不知道他为什么会有这种奇特的喜好？似乎小孩对什么东西都是很新奇的。

儿子常常说的话是，“爸爸是老帅哥，超超是小帅哥”

儿子常常让他妈妈做的事情是，“画鱼摆摆吹泡泡”

儿子最喜欢的电视节目是每晚19点CCTV3的“动物世界”

在儿子两岁之即，特记之。

前面两篇文章简要介绍了db_block_checking和db_block_checksum参数，并提到这两个参数对性能的影响。下面做个测试：

首先建一个测试表，并设置db_block_checking和db_block_checksum为false：

SQL> create table t2 (a int) tablespace test;

表已创建。
SQL> alter system set db_block_checking=false;

系统已更改。

SQL> alter system set db_block_checksum=false;

向测试表T2中四次分别插入100，000行数据：

SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 06.02
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.02
SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 05.04
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.02
SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 07.04
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.01
SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 07.04
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.01

四次数据插入中，最长的时间为7.04秒，最短时间为5.05秒，平均6.29秒。

下面再看看将这两个参数设置为true的测试结果：

SQL> alter system set db_block_checking=true;

系统已更改。

SQL> alter system set db_block_checksum=true;

系统已更改。

SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 11.02
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.02
SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 12.01
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.02
SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 09.00
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.04
SQL> begin
2 for i in 1..100000 loop
3 insert into t2 values(i);
4 end loop;
5 end;
6 /

PL/SQL 过程已成功完成。

已用时间: 00: 00: 11.04
SQL> commit;

提交完成。

已用时间: 00: 00: 00.00
SQL> alter system checkpoint;

系统已更改。

已用时间: 00: 00: 01.02

在上面的测试中，四次数据插入，最长的时间为12.01秒，最短时间为9.00秒，平均为10.77秒。

可以看出，这两者的差别是相当显著的，这两者参数设置为false时比设置为true竟然快了40%以上。不过这只是个简单的测试，实际情况可能没那么突出，但差异在10%以上是有可能的。

值得注意的是，性能上的差异，主要是由于CPU的消耗造成的，对于CPU资源不足的系统，将这两个参数设置为TRUE无疑会增大CPU的负担，引起性能问题。同时还会引起redo copy latch的持有时间增加和引起这个latch的竞争。

另外，由于不管db_block_checking和db_block_checksum这两个参数的值为何值，SYSTEM表空间都会进行做checking和checksum，除非把隐含参数_db_always_check_system_ts设置为FALSE，当然为了SYSTEM表空间数据安全，不建议将这个隐含参数值设置为FALSE。因此，不要将用户表和索引放到SYSTEM空间中。

在启用一起特定的功能后，SYSTEM表空间中一些表和索引会增长很快。比如启用了审计并且将审计日志存储到数据库中，则AUD$和FGA_LOG$会迅速增长；如果使用高级复制，DEF$_AQCALL表会增加很快，并且如果要复制的数据量比较大，则这个表上的DML是非常多的，在这样的情况会下，会消耗更多的CPU和引起性能降低。如果使用了审计和高级复制，建议将AUD$、FGA_LOG$、DEF$_AQCALL迁移到其他表空间，一方面避免产生大量数据使得SYSTEM表空间过大，另一方面则是避免出现本文提到的性能问题。不过这些表都是特殊的对象，最好在Oracle技术支持指导下进行。DEF$_AQCALL的迁移，请参考metalink doc ID 1037317.6 “Moving the Replication Queue Tables (DEF$) Out of the System Tablespace”；AUD$的迁请参考metalink doc ID 72460.1 “Moving AUD$ to Another Tablespace and Adding Triggers to AUD$”

对这两个参数引起的性能差异的深入分析，有兴趣的可参考Oracle hidden costs revealed, Part2 - Using DTrace to find why writes in SYSTEM tablespace are slower than in others

这两个参数不光对DML，对读也是有性能影响的。db_block_checksum参数对读的性能影响和测试，有兴趣的可参考ixora上的文章Note the db_block_checksum parameter setting

在之前的一篇文章db_block_checking和db_block_checksum，简要地描述了db_block_checking和db_block_checksum这两个参数的作用以及性能方面的影响。在10gR1及这前的版本中，这两个参数可以设置为false和true。而在10gR2版本中，这两个参数发生了一点变化。

先来看看db_block_checking，这个参数现在有四个可能的设置：

• OFF - 与原来的FALSE一样，对非SYSTEM表空间的块关闭检查，这个值在设置时仍然可以用false。
• LOW - 只检查块头。这个检查发生在当块的内容在内存中发生改变时，比如UPDATE、INSERT、DELETE等，以及将块从磁盘读入、RAC结点间块的传输。
• MEDIUM - 比LOW更高一级，还包括了非IOT的表的块内部检查（即不仅仅是块头）。
• FULL - 与原来的TRUE一样，与MEDIUM相比，还包括了索引块的检查。

再看看db_block_checksum这个参数有什么变化：

• OFF - 与原来的FALSE一样，只会给SYSTEM表空间的块计算checksum值。
• TYPICAL - 与原来的TRUE一样，Oracle在向磁盘写入块时计算checksum值，下次读入时进行校验。
• FULL - 这是新增的值，Oracle不关在写入块时计算checksum值，而且在更改块（比如执行UPDATE语句等）之前对checksum值进行校验，同时在更改块之后对checksum值进行重新计算。另外Oracle也会在写入日志块时，计算块的checksum。这个设置大大增加了系统负荷，大约带来了4-5%的负荷。而TYPICAL值会带来1-2%的负荷。

Oracle数据库的global_name，在Database Link与GLOBAL_NAMES参数一文中提到了，设置global_names初始化参数为true后，本地的数据库链接名称必须与远程数据库的global_name相同，才能正常使用数据库链接。那么怎么查询数据库的global_name呢？

SQL> col global_name for a30
SQL> select * from global_name;

GLOBAL_NAME
------------------------------
DMDB

那么怎么样修改global_name？

ALTER DATABASE
RENAME GLOBAL_NAME TO NEW_NAME;

注意不要直接用update global_name set global_name=”将global_name设置为空，否则数据库不能启动，会报ORA-00600[18061] 或 ORA-00600[18062]这样的错误。 只有用备份进行恢复后才能打开。（参见metalink note 743676.1）。

那么global_name到底是个什么对象呢？

SQL> select owner,object_name,object_type from dba_objects where object_name=’GLOBAL_NAME’;

OWNER OBJECT_NAME OBJECT_TYPE
---------- -------------------- --------------------
SYS GLOBAL_NAME VIEW
PUBLIC GLOBAL_NAME SYNONYM

SQL> select text from dba_views where view_name=’GLOBAL_NAME’;

TEXT
----------------------------------------------------------------
select value$ from sys.props$ where name = ‘GLOBAL_DB_NAME’

可以看到global_name实际上是一个视图，来源于sys.props$表，而这个表是非常重要的一个关于数据库属性的表，不要随意更改此表的内容，否则将引起无可预料的、无法挽回的损失。

在用alert database rename global_name时，如果设置了global_name类似于”dmdb.com”这样的名称，则以后更改名称，则没有常规的办法去掉”.”分隔符了。

SQL> select * from global_name;

GLOBAL_NAME
------------------------------
DMDB

SQL> alter database rename global_name to dmdb.com;

Database altered.

SQL> select * from global_name;

GLOBAL_NAME
------------------------------
DMDB.COM

SQL> alter database rename global_name to dmdb.cn;

Database altered.

SQL> select * from global_name;

GLOBAL_NAME
------------------------------
DMDB.CN

SQL> alter database rename global_name to dmdb;

Database altered.

SQL> select * from global_name;

GLOBAL_NAME
------------------------------
DMDB.CN

SQL> alter database rename global_name to dm;

Database altered.

SQL> select * from global_name;

GLOBAL_NAME
------------------------------
DM.CN

SQL> alter database rename global_name to dm.com.cn;

Database altered.

SQL> select * from global_name;

GLOBAL_NAME
------------------------------
DM.COM.CN

SQL> alter database rename global_name to dmdb;

Database altered.

SQL> select * from global_name;

GLOBAL_NAME
------------------------------
DMDB.COM.CN
SQL> alter database rename global_name to dmdb.net;

Database altered.

SQL> select * from global_name;

GLOBAL_NAME
------------------------------
DMDB.NET

要去掉点分隔符，只有用update：

SQL> update global_name set global_name=’DMDB’;

1 row updated.

SQL> commit;

Commit complete.

SQL> select * from global_name;

GLOBAL_NAME
------------------------------
DMDB

如果一个表的外键引用的是另一个用户的表，需要特别的权限吗？答案就是refrences权限。虽然一个schema（用户）下表的外键引用的是其他schema（用户）的表，是一种不太好的设计。但现实中仍然会有这种情况。下面来看看reference的作用：

测试环境：
Oracle 10.2.0.1
Redhat Linux AS4
数据库里用于测试的两个用户test1和test2，只有connect角色权限和表空间使用权限。

SQL> connect / as sysdba
Connected.
SQL> create table test1.t1 as select * from dba_objects where rownum< =1000;

Table created.

SQL> create table test2.t2 as select * from dba_objects where rownum< =1000;

Table created.

SQL> alter table test1.t1 add constraint pk_t1 primary key(object_id);

Table altered.

现在，我们用用户test2连接到数据库，在表test2.t2的object_id字段上增加一个外键，外键引用test1.t1表的object_id字段：

SQL> connect test2/test
Connected.
SQL> alter table t2 add constraint fk_t2 foreign key (object_id) references test1.t1(object_id);
alter table t2 add constraint fk_t2 foreign key (object_id) references test1.t1(object_id)
*
ERROR at line 1:
ORA-00942: table or view does not exist

我们将test1.t1表的查询权限赋给test2：

SQL> grant select on test1.t1 to test2;

Grant succeeded.

再次增加外键：

SQL> alter table t2 add constraint fk_t2 foreign key (object_id) references test1.t1(object_id);
alter table t2 add constraint fk_t2 foreign key (object_id) references test1.t1(object_id)
*
ERROR at line 1:
ORA-01031: insufficient privileges

可以看到报权限不足。我们再看看如果将DBA权限给test2会怎么样：

SQL> connect / as sysdba
Connected.
SQL> grant dba to test2;
Grant succeeded.

SQL> connect test2/test
Connected.
SQL> alter table t2 add constraint fk_t2 foreign key (object_id) references test1.t1(object_id);
alter table t2 add constraint fk_t2 foreign key (object_id) references test1.t1(object_id)
*
ERROR at line 1:
ORA-01031: insufficient privileges

还是报权限不足。

SQL> connect / as sysdba
Connected.
SQL> revoke dba from test2;

Revoke succeeded.
SQL> grant references on test1.t1 to test2;

Grant succeeded.
SQL> connect test2/test
Connected.
SQL> alter table t2 add constraint fk_t2 foreign key (object_id) references test1.t1(object_id);

Table altered.
SQL> select owner,constraint_name,constraint_type,table_name,r_owner,r_constraint_name,status,validated,invalid from user_constraints;

OWNER CONSTRAINT_NAME C TABLE_NAME R_OWNER R_CONSTRAINT_NAME STATUS VALIDATED INVALID
---------- -------------------- - ---------- ---------- -------------------- ---------- ---------- ----------
TEST2 FK_T2 R T2 TEST1 PK_T1 ENABLED VALIDATED

我们看到将test1.t1表的references权限给test2后，外键增加成功。
如果这个时候取消这个权限，会怎么样？

SQL> revoke references on test1.t1 from test2;
revoke references on test1.t1 from test2
*
ERROR at line 1:
ORA-01981: CASCADE CONSTRAINTS must be specified to perform this revoke

可以看到由于已经有了引用其他表的外键，不能直接取掉这个权限。

SQL> revoke references on test1.t1 from test2 cascade constraints;

Revoke succeeded.

再看看test2用户的外键：

SQL> select owner,constraint_name,constraint_type,table_name,r_owner,r_constraint_name,status,validated,invalid from user_constraints;

no rows selected

加了cascade constraints之后的取消权限语句，直接导致了test2用户上的外键被删除。

SQL> grant references on test1.t1 to dba;

Grant succeeded.

SQL> grant dba to test2;

Grant succeeded.
SQL> connect test2/test
Connected.
SQL> alter table t2 add constraint fk_t2 foreign key (object_id) references test1.t1(object_id);
alter table t2 add constraint fk_t2 foreign key (object_id) references test1.t1(object_id)
*
ERROR at line 1:
ORA-01031: insufficient privileges

如上面所示，references权限只能直接赋予给用户，通过角色赋予用户，没有作用。另外，没有系统级的references权限，如references any table等。

SQL> grant references on test1.t1 to test2;

Grant succeeded.

SQL> grant references on test1.t1 to dba;

Grant succeeded.

SQL> select * from role_tab_privs where privilege like ‘%REFERENCES%’;

no rows selected

SQL> select grantee,owner,table_name,grantor,privilege from dba_tab_privs where privilege like ‘%REFERENCES%’;

GRANTEE OWNER TABLE_NAME GRANTOR PRIVILEGE
------------ ---------- -------------------- ---------- ---------------
SYSTEM SYS INCEXP SYS REFERENCES
SYSTEM SYS INCVID SYS REFERENCES
SYSTEM SYS INCFIL SYS REFERENCES
TEST2 TEST1 T1 TEST1 REFERENCES

我们看到将references赋给role并没有起作用，虽然grant语句没有报错，但在role_tab_privs中并没有记录。
虽然DBA角色没有references权限，但是可以将任意一个表的references权限赋给他人（这是因为DBA角色具有GRANT ANY OBJECT PRIVILEGE权限）。SYS也需要显式的某个表上赋予references权限才能引用那个表。

SQL> create table t3 as select * from dba_objects where object_id< =1000;

Table created.
SQL> alter table t3 add constraint fk_t3 foreign key (object_id) references test1.t1(object_id);
alter table t3 add constraint fk_t3 foreign key (object_id) references test1.t1(object_id)
*
ERROR at line 1:
ORA-01031: insufficient privileges
SQL> grant dba to test2;

Grant succeeded.
SQL> connect test2/test
Connected.
SQL> grant references on test1.t1 to sys;

Grant succeeded.
SQL> connect / as sysdba
Connected.
SQL> alter table t3 add constraint fk_t3 foreign key (object_id) references test1.t1(object_id);

Table altered

今天是2008年10月22日，农历戊子年九月二十四。

今天是我的法律意义上的生日。虽然很早以前在办户籍时把我的出生日期给搞错了，提前了一个月。但到如今只有将错就错了。

今天是我儿子农历两岁生日，看着儿子一天天长大，那种快乐实不足以用言语来表达。祝福他永远快乐地成长下去。

三年前的今天，我正在当新郎官。

今天是个有意义的日子。

环境：HP-UX 11.31
Oracle 9.2.0.8

数据库异常崩溃，询问维护人员之前有大量数据操作。查看alert日志：

Thu Oct 9 02:20:18 2008
Errors in file /oracle/OraHome1/rdbms/log/acct_ora_11361.trc:
ORA-00600: internal error code, arguments: [ktprhtnew6], [], [], [], [], [], [], []
Thu Oct 9 02:20:19 2008
Fatal internal error happened while SMON was doing active transaction recovery.
Thu Oct 9 02:20:19 2008
Errors in file /oracle/OraHome1/rdbms/log/acct_ora_11361.trc:
ORA-00600: internal error code, arguments: [ktprhtnew6], [], [], [], [], [], [], []
SMON: terminating instance due to error 600
Instance terminated by SMON, pid = 11361

检查trace文件，没有发现有用的信息。

重启数据库，数据库能打开，但不到一分钟实例就crash。在alert日志中的错误信息均如上所示。
在网上及在metalink中以ktprhtnew6为关键字搜索，没有找到相似的BUG和案例。同时当时手边是用的163拨号上网，速度非常慢，只有通过分析来解决问题。

仔细分析alert日志可以发现是在做事务恢复时SMON出错，导致实际中止：

Fatal internal error happened while SMON was doing active transaction recovery.

我们知道ORA-600错误后面参数，如果像ktprhtnew6这样的均表示出错的函数。这里可以看出是在做并行恢复：

[K]enerl [T]ransaction [P]arallel [R]ecovery

设置fast_start_parallel_rollback参数为false，关闭数据库的并行恢复功能，重启数据库，数据库正常，故障消失。
看起来这应该又是一个BUG。

Oracle的监听(Listener)在缺省情况下，会在文件中记录日志，记录数据库实例注册操作、客户端的连接等。缺省（没有设置log_file参数时）的文件是$ORACLE_HOME/network/log/listener.log。对于一些使用短连接的，频繁的连接数据库的应用，listener.log增长很快。有的可以在比较短的时间内（十几天）就可以超过2GB。对于一些平台的某些版本的Oracle，在监听日志增大到2GB以后会导致监听不能正常工作（我没遇到过，不过感兴趣的朋友可以在网上搜索一下，有这样的案例）。

对于这种listener.log增长非常迅速的系统，可以关闭监听日志，不让监听写日志到文件。也可以写个job定期清理。本文主要描述怎么样关闭监听日志：

可以在监听命令行接口中使用命令：
D:\>lsnrctl

LSNRCTL for 32-bit Windows: Version 9.2.0.1.0 - Production on 15-10月-2008 20:52:11

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

欢迎来到LSNRCTL，请键入”help”以获得信息。

LSNRCTL> set log_status off
正在连接到 (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=dreamf)(PORT=1521)))
LISTENER 参数 \log_status\ 被设为 OFF
命令执行成功
LSNRCTL> save_config
正在连接到 (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=dreamf)(PORT=1521)))
未保存对LISTENER所作的更改
命令执行成功
LSNRCTL>

我们可以在listener.ora文件中可以看到增加了下面的内容：

#----ADDED BY TNSLSNR 15-10月-2008 10:05:43---
LOGGING_LISTENER = OFF
#---------------------------------------------

所以我们也可以在listener.ora文件增加上面的内容来关闭监听日志。但是只有在监听重启后才会生效，而通过lsnrctl 这个命令接口设置，可以立即生效，Windows平台上的文件会立即关闭。因此可以利用这个特性，用来删除WINDOWS平台上的监听日志文件，因为不这样，在监听运行时监听日志是不能删除的。

2007年9月20日，我从四川的一个小城市来到了成都，来到了这个熟悉又陌生的地方。说这个地方熟悉，是因为我在这里读了四年书，工作的时候偶尔也会出差到这里，每次出远门也要路过这里。说这个地方陌生，则是对于我来说，不太爱动。这里读了四年书，生活了几年，去的地方少得可怜。

想想一年之前，毅然告别了生活、工作了八年多的地方，那时心里面是非常复杂的。徬徨、紧张、憧憬……不过还好，没多久就适应了新的生活和新的工作环境，也很喜欢新的工作，我想这是令我非常高兴的一件事。

成都是一个悠闲的城市，在这样一个地方，一年内体重也增加了好几斤。不过我本来就偏瘦，增加体重说明身体更好了^_^

我喜欢平淡而又充实的生活，所以没什么大喜大悲的事情。我喜欢这样的生活。

谈不上抒情，也没有抒情的文笔，简单记录之。