eygle 有篇文章讲了这个，之前也看过。昨天实际操作了一下。
因为如 eygle 所讲，kill 了 session 之后，操作系统里面的进程资源有时候不一定会立即释放，所以最好在 kill 之前就找到系统的进程 id，这样，如果不释放的时候，可以直接kill。省的之后找起来麻烦。
昨天操作的时候有这么几个步骤
- select * from v$session where username like ‘UP’ –先找到这个用户的 session。
- select * from v$sql a, v$session b where b.username = ‘UP’ and a.sql_id = b.sql_id –找出来这个用户这些 session 对应的 sql 语句，好确认 session 的 id。
- select * from v$process a, v$session b where a.addr = b.paddr and b.username like ‘UP’ and b.sid = xxx –找出来他的系统进程id，就是那个 spid。
- ALTER SYSTEM KILL SESSION ‘sid, serial#’ –可以实施kill了，可能会提示你marked for kill，有必要的话，在os级别kill前面找出来的 spid。
这几天遇到了这两个错误，记录一下。
使用 perl 的 DBI 连接的时候，会提示 ora-00257 错误，这个用 三qlplus 估计也是一样的错误，注意时远程连接才出错。
DBI connect('host=db8.xxx;sid=nirv3','sirenmon',...) failed: ORA-00257: archiver error. Connect internal only, until freed. (DBD ERROR: OCISessionBegin) at ./check_sdsdb line 26
CRITICAL : Can't connect "db8.sds.cnb.yahoo.com"同时，数据库的alert 里面有下面的信息
Errors in file /home/oracle/app/diag/rdbms/nirv/nirv3/trace/nirv3_arc1_9507.trc:
ORA-19815: WARNING: db_recovery_file_dest_size of 268435456000 bytes is 100.00% used, and has 0 remaining bytes available.
************************************************************************
You have following choices to free up space from flash recovery area:
1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,
then consider changing RMAN ARCHIVELOG DELETION POLICY.
2. Back up files to tertiary device such as tape using RMAN
BACKUP RECOVERY AREA command.
3. Add disk space and increase db_recovery_file_dest_size parameter to
reflect the new space.
4. Delete unnecessary files using RMAN DELETE command. If an operating
system command was used to delete files, then use RMAN CROSSCHECK and
DELETE EXPIRED commands.
************************************************************************
ARCH: Archival stopped, error occurred. Will continue retrying
ORACLE Instance nirv3 - Archival Error
登陆上数据库看看
SQL> show parameter archive
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
archive_lag_target integer 0
log_archive_config string dg_config=(stb1)
log_archive_dest string
log_archive_dest_1 string location="USE_DB_RECOVERY_FILE
log_archive_dest_10 string
log_archive_dest_2 string
log_archive_dest_3 string
log_archive_dest_4 string
log_archive_dest_5 string
log_archive_dest_6 string
log_archive_dest_7 string
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
log_archive_dest_8 string
log_archive_dest_9 string
log_archive_dest_state_1 string ENABLE
log_archive_dest_state_10 string enable
log_archive_dest_state_2 string ENABLE
log_archive_dest_state_3 string enable
log_archive_dest_state_4 string enable
log_archive_dest_state_5 string enable
log_archive_dest_state_6 string enable
log_archive_dest_state_7 string enable
log_archive_dest_state_8 string enable
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
log_archive_dest_state_9 string enable
log_archive_duplex_dest string
log_archive_format string %s_%t_%r_%a.arc
log_archive_local_first boolean TRUE
log_archive_max_processes integer 4
log_archive_min_succeed_dest integer 1
log_archive_start boolean FALSE
log_archive_trace integer 0
standby_archive_dest string ?/dbs/arch
SQL> select * from v$log;
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARCHIV STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- ------ -------------------------------- ------------- ------------
1 1 221250 52428800 1 YES INACTIVE 5082709437 05-SEP-08
2 1 221252 52428800 1 NO INACTIVE 5082713458 05-SEP-08
3 2 270972 52428800 1 YES INACTIVE 5082699510 05-SEP-08
4 2 270975 52428800 1 NO CURRENT 5082713581 05-SEP-08
9 1 221251 52428800 1 NO INACTIVE 5082712943 05-SEP-08
10 2 270973 52428800 1 YES INACTIVE 5082705151 05-SEP-08
11 1 221253 52428800 1 NO CURRENT 5082713765 05-SEP-08
12 2 270974 52428800 1 NO INACTIVE 5082711887 05-SEP-08
13 3 275581 52428800 1 NO INACTIVE 5082712519 05-SEP-08
14 3 275582 52428800 1 NO CURRENT 5082713078 05-SEP-08
15 3 275579 52428800 1 NO INACTIVE 5082710114 05-SEP-08
GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARCHIV STATUS FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- ------ -------------------------------- ------------- ------------
16 3 275580 52428800 1 NO INACTIVE 5082711321 05-SEP-08
12 rows selected.
SQL> ????select value from v$diag_info where name ='Diag Trace';
VALUE
------------------------------------------------------------------------------------------------------------------------------------------------------
/home/oracle/app/diag/rdbms/nirv/nirv3/trace
SQL> select * from V$FLASH_RECOVERY_AREA_USAGE;
FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
---------------------------------------- ------------------ ------------------------- ---------------
CONTROL FILE 0 0 0
REDO LOG 0 0 0
ARCHIVED LOG 100 0 13109
BACKUP PIECE 0 0 0
IMAGE COPY 0 0 0
FLASHBACK LOG 0 0 0
FOREIGN ARCHIVED LOG 0 0 0
7 rows selected.
SQL> show parameter db_recovery_file_dest_size
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
db_recovery_file_dest_size big integer 250G
SQL> show parameter DB_RECOVERY_FILE_DEST
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
db_recovery_file_dest string /sds/oradata
db_recovery_file_dest_size big integer 250G
SQL> alter system set db_recovery_file_dest_size=300G;
System altered.
SQL> show parameter DB_RECOVERY_FILE_DEST
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
db_recovery_file_dest string /sds/oradata
db_recovery_file_dest_size big integer 300G
SQL> select * from V$FLASH_RECOVERY_AREA_USAGE;
FILE_TYPE PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES
---------------------------------------- ------------------ ------------------------- ---------------
CONTROL FILE 0 0 0
REDO LOG 0 0 0
ARCHIVED LOG 83.41 0 13115
BACKUP PIECE 0 0 0
IMAGE COPY 0 0 0
FLASHBACK LOG 0 0 0
FOREIGN ARCHIVED LOG 0 0 0
7 rows selected.可以看到空间是 83% 了，数据库应该就好了。不过这个是治标不治本的操作，需要把archive log删掉才行，具体怎么搞我也不会。。。汗。。
还是高级复制的问题，这次可能是因为job执行过程中，对方机器刚好重启导致的。反正job是卡在那里了，都10多天了。
查看 dba_jobs_running 表，可以看到卡住的job的 job_id 和 sid 。查看 dba_jobs 表，可以看到相应 job 的信息，this_date 如果有数据的话，表示的是 job 开始执行的时间，next_date 是下次执行 job 的时间，如果 job 正常执行完毕，那么 this_date 应该是空的。根据 sid 还可以查看 v$session_wait 和 v$session 里面的这个 job 的一些状态。
尝试了下面的方法来重新运行job，当时好像不好用，不过今天来看的时候，job是执行了。现在也不清楚是不是我这个操作起作用了，真晕。
SQL> exec dbms_job.broken(109,true);
PL/SQL procedure successfully completed.
SQL> commit;
Commit complete.
SQL> select job,sid from dba_jobs_running;
JOB SID
---------- ----------
109 656
SQL> select saddr,sid,serial#,paddr,username,status from v$session where username = 'REPADMIN';
SADDR SID SERIAL# PADDR USERNAME STATUS
-------- ---------- ---------- -------- ------------------------------ --------
973CF8C4 626 27 98F96BB8 REPADMIN ACTIVE
973D2E7C 629 10 98F88670 REPADMIN ACTIVE
973F11F4 656 10 98F88174 REPADMIN ACTIVE
SQL> alter system kill session '656,10';
System altered.
SQL> select saddr,sid,serial#,paddr,username,status from v$session where username = 'REPADMIN';
no rows selected
SQL> select job,sid from dba_jobs_running;
no rows selected
SQL> select job,log_user,last_date,next_date from dba_jobs where log_user='REPADMIN';
JOB LOG_USER LAST_DATE
---------- ------------------------------ -------------------
NEXT_DATE
-------------------
106 REPADMIN 2007-06-28 16:25:43
2007-06-28 16:35:43
109 REPADMIN 2007-06-28 16:07:38
4000-01-01 00:00:00
110 REPADMIN 2007-06-28 16:25:43
2007-06-28 16:35:43
SQL> exec dbms_job.broken(109,false,sysdate);
PL/SQL procedure successfully completed.
SQL> commit;
Commit complete.
SQL> select job,log_user,last_date,next_date from dba_jobs where log_user='REPADMIN';
JOB LOG_USER LAST_DATE
---------- ------------------------------ -------------------
NEXT_DATE
-------------------
106 REPADMIN 2007-06-28 16:25:43
2007-06-28 16:35:43
109 REPADMIN 2007-06-28 16:07:38
2007-06-28 16:28:40
110 REPADMIN 2007-06-28 16:25:43
2007-06-28 16:35:43此后就我所知道的，就只能等着了。dbms_job.run(job_id) 也可以让 job 立即执行。关键是看 this_date ，他的值就是开始执行 job 的时间，job 如果执行时间太长，而下次执行又太快的话，可能也会导致问题。所以还可以尝试手动执行 job 看看。 dba_jobs 的 waht 字段就是对于的语句。
resin 2.x 的配置方法和 3.x 的方法有区别。按照官方文档，做下面的配置。
<database>
<jndi-name>oraPool</jndi-name>
<driver>
<type>oracle.jdbc.pool.OracleConnectionPoolDataSource</type>
<url>jdbc:oracle:thin:@localhost:1521:dbname</url>
<user>username</user>
<password>password</password>
</driver>
#....
</database> 在上面的 …. 这里还可以添加其他的配置信息。配置好之后启动resin，会发现提示类似下面的信息。
conf/resin.conf:218: java.lang.ClassNotFoundException: oracle.jdbc.pool.OracleConnectionPoolDataSource
提示没有找到连接oracle数据库的jdbc驱动。这个驱动在oracle的安装目录里面有。比如我这里是在 /db/oracle/10.1.0/product/10g/jdbc/lib/ 。里面好多文件，具体都什么作用可以看这里。
复制这个目录里面的 classes12.jar 和 nls_charset12.jar 到resin的 lib 目录下面，重新启动 resin 就可以了。本文完成过程中参考了这篇文章。如何使用这个pool，官方文档也有说明。
早上来了同事就来找我，有两台同步的服务器数据库没有同步成功，查查咋回事。
一台A，从B处同步。蒙了一下，果然有个dba_jobs表，呵呵。
SELECT job,log_user,last_date,next_date,failures,broken,what FROM dba_jobs;
在A处执行上面的命令，好像repadmin的job都在正常执行。
在B处执行上面的命令，能查到类似下面的信息
JOB LOG_USER LAST_DATE
---------- ------------------------------ -------------------
NEXT_DATE FAILURES B
------------------- ---------- -
47 repadmin 2006-05-16 19:37:29
4001-01-01 00:00:00 16 Y
显然是job挂了。查看了一下挂的时间，原来是联通机房机柜断电那天，A机器在联通机房，那天断电了6个小时。B机器上面的同步尝试了16次之后就挂起了。解决方法也不难，用repadmin用户登录，然后执行下面的语句，谁的job只能由谁来执行：
EXECUTE DBMS_JOB.broken(47,false,sysdate);
47是job id，sysdate表示当前时间。等会再看吧，执行成功之后会把 failures 重新计数，B变成N。
第1部分 安装操作系统
首先需要安装系统….Red Hat Enterprise Linux 2.1，Red Hat Enterprise Linux 3，Novell SUSE Linux Enterprise Server 8 是通过 oracle 10g认证的三个linux发行套件，不知道oracle 10.3有没有对这个修改。默认情况下，oracle 10g只能在rh的这两个版本安装，如果不是上面两个，运行安装程序会直接打印错误。不过也有方法在别的版本安装的，后面有说明。
按照上一篇文章，安装linux的时候可以不选择图形界面，这样还可以节省不少空间。按照oracle的文档，说需要安装下面的这些软件包。
rpm -q gcc make binutils openmotif setarch compat-db compat-gcc \
compat-gcc-c++ compat-libstdc++ compat-libstdc++-devel
我实际安装过程中，compat-gcc compat-gcc-c++ compat-libstdc++ compat-libstdc++-devel 这几个包我没有安装也可以安装oracle。
阅读全文…
oracle 的手册里面讲的通常都是图形界面下面的安装，就是用oracle登录桌面，然后运行安装程序的方法。可实际上维护服务器的时候，大多用的还是远程文本界面。这样很有必要看看如何通过文本界面来安装oracle。
oracle本身的安装程序也提供了这个方法，就是使用 responseFile 。这个 responseFile 其实就是在图形界面安装的时候的一些选择，保存到文件之后，直接告诉安装程序从这里读取设置就好了。将oracle的安装文件 ship.db.lnx32.cpio.gz 解压：
gunzip ship.db.lnx32.cpio.gz
cpio -idmv < ship.db.cpio
这样可以看到有个Disk1的文件夹，里面有个response目录，里面好多response文件，不过我还不知道这些有什么区别，里面设置项也很多，还没弄明白。我使用的不是这里的response文件。是通过下面的方法获取的rsp文件。
可以通过在记录模式中运行软件或通过手动编辑示例响应文件来创建响应文件。以下是一个基本演示：
1. 用此命令启动 OUI 来创建响应文件：
./runInstaller -record -destinationFile /tmp/recorded.rsp
2. 选择您需要的所有部分（源目标目录、主目录、主目录名、产品）。
3. 当您看到 Summary 屏幕时，不要单击 Install，而是单击 Cancel。
4. 仔细查看在 tmp/recorded.rsp 中创建的结果响应文件。如果需要，可以手动编辑该文件，只要您遵守使用规定的格式即可（请参见文档）。
5. 现在如下执行静默安装：
./runInstaller -silent -responseFile /tmp/recorded.rsp
在运行脚本时将会报告安装的进度。
如果您由于响应文件中的条目不正确而遇到安装故障，安装将失败并显示一条诊断消息。详细信息可在 oraInventory/logs 目录中找到。在每次使用响应文件运行 OUI 时，会创建具有 installActions-<时间戳>.log 和 silentInstall<时间戳>.log 格式名称的日志。
这样，只需要找台机器在图形界面下面运行一下安装程序，生成一个rsp文件，然后放到真正需要安装的服务器上面，修改一下安装路径，设置一下sys密码，就可以开始安装了。
oracle的数据库文件一旦建立就会一直占用磁盘空间，表空间用尽的时候，就需要为表空间添加数据文件。可是，从表里面删除数据的时候，表空间却不会释放，所以磁盘空间占用只会越来越大。前段时间一个数据库的表空间不足了，放数据的分区也磁盘空间不足了，必须得想办法释放一下空间才行，操作说起来其实也简单，就是倒腾。
操作值钱咱先给现在的表空间做一个备份。然后新建一个用户，给这个用户建立表空间，按照备份的大小添加数据文件。然后将备份导入新的表空间，切换应用使用的用户。删除之前用户的表空间，删除数据文件。然后给他重新建立表空间数据文件，切换回来。然后将新的用户里面的数据导出，导入到旧的用户下面。这样就操作完了。
导出导入的时候可以按照exp和imp帮助里面的那个例子，row=n表示不倒数据，只导结构。这样导出似乎也会有些问题，什么seq不会倒出来，需要重新弄，不太明白这个。
Oracle数据库日常维护手册
在Oracle数据库运行期间，DBA应该对数据库的运行日志及表空间的使用情况进行监控，及早发现数据库中存在的问题。
一、Oracle警告日志文件监控
Oracle在运行过程中，会在警告日志文件(alert_SID.log)中记录数据库的一些运行情况:
●数据库的启动、关闭，启动时的非缺省参数;
●数据库的重做日志切换情况，记录每次切换的时间，及如果因为检查点(checkpoint)操作没有执行完成造成不能切换，会记录不能切换的原因;
●对数据库进行的某些操作，如创建或删除表空间、增加数据文件;
●数据库发生的错误，如表空间不够、出现坏块、数据库内部错误(ORA-600)
DBA应该定期检查日志文件，根据日志中发现的问题及时进行处理
问题处理
启动参数不对检查初始化参数文件
因为检查点操作或归档操作没有完成造成重做日志不能切换如果经常发生这样的情况，可以考虑增加重做日志文件组;想办法提高检查点或归档操作的效率;
有人未经授权删除了表空间检查数据库的安全问题，是否密码太简单;如有必要，撤消某些用户的系统权限
出现坏块检查是否是硬件问题(如磁盘本生有坏块)，如果不是，检查是那个数据库对象出现了坏块，对这个对象进行重建
表空间不够增加数据文件到相应的表空间
出现ORA-600根据日志文件的内容查看相应的TRC文件，如果是Oracle的bug，要及时打上相应的补丁
阅读全文…
近期评论