存档

文章标签 ‘oracle’

oracle 里面 kill session

2008年10月7日 wd 没有评论

eygle 有篇文章讲了这个,之前也看过。昨天实际操作了一下。

因为如 eygle 所讲,kill 了 session 之后,操作系统里面的进程资源有时候不一定会立即释放,所以最好在 kill 之前就找到系统的进程 id,这样,如果不释放的时候,可以直接kill。省的之后找起来麻烦。

昨天操作的时候有这么几个步骤

  1. select * from v$session where username like ‘UP’ –先找到这个用户的 session。
  2. select * from v$sql a, v$session b where b.username = ‘UP’ and a.sql_id = b.sql_id –找出来这个用户这些 session 对应的 sql 语句,好确认 session 的 id。
  3. select * from v$process a, v$session b where a.addr = b.paddr and b.username like ‘UP’ and b.sid = xxx –找出来他的系统进程id,就是那个 spid。
  4. ALTER SYSTEM KILL SESSION ‘sid, serial#’ –可以实施kill了,可能会提示你marked for kill,有必要的话,在os级别kill前面找出来的 spid。
分类: Linux 标签: ,

ORA-00257 和 ORA-19815

2008年9月6日 wd 没有评论

这几天遇到了这两个错误,记录一下。

使用 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删掉才行,具体怎么搞我也不会。。。汗。。

分类: Mail 标签:

oracle 的 job 又遇到问题了

2007年6月29日 wd 没有评论

还是高级复制的问题,这次可能是因为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 字段就是对于的语句。

分类: Linux, Other 标签: , ,

为resin配置oracle连接池

2007年6月27日 wd 没有评论

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,官方文档也有说明

分类: Linux, Other 标签: ,

oracle 的高级复制出了点问题,记录下解决办法

2007年5月18日 wd 没有评论

早上来了同事就来找我,有两台同步的服务器数据库没有同步成功,查查咋回事。

一台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。

分类: Linux, Other 标签:

oracle在rh里面的安装流程

2007年3月14日 wd 没有评论

第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。
阅读全文…

分类: Linux, Other 标签:

oracle 文本界面的安装

2007年3月14日 wd 没有评论

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密码,就可以开始安装了。

分类: Linux, Other 标签:

昨天操作了好多次oracle的备份和恢复

2006年11月9日 wd 没有评论

oracle的数据库文件一旦建立就会一直占用磁盘空间,表空间用尽的时候,就需要为表空间添加数据文件。可是,从表里面删除数据的时候,表空间却不会释放,所以磁盘空间占用只会越来越大。前段时间一个数据库的表空间不足了,放数据的分区也磁盘空间不足了,必须得想办法释放一下空间才行,操作说起来其实也简单,就是倒腾。

操作值钱咱先给现在的表空间做一个备份。然后新建一个用户,给这个用户建立表空间,按照备份的大小添加数据文件。然后将备份导入新的表空间,切换应用使用的用户。删除之前用户的表空间,删除数据文件。然后给他重新建立表空间数据文件,切换回来。然后将新的用户里面的数据导出,导入到旧的用户下面。这样就操作完了。

导出导入的时候可以按照exp和imp帮助里面的那个例子,row=n表示不倒数据,只导结构。这样导出似乎也会有些问题,什么seq不会倒出来,需要重新弄,不太明白这个。

分类: Other 标签: , ,

数据恢复步骤

2006年8月5日 wd 没有评论
切换到oracle用户
sqlplus
conn / AS sysdba
DROP user <USER> cascade;
CREATE user <USER> IDENTIFIED BY <PASSWORD> DEFAULT tablespace <TABLESPACE>;
exit
imp <USER>/<PASSWORD> file=<FILE_NAME> fromuser=<USER> touser=<USER>
*为要恢复的用户,为其密

分类: Other 标签: ,

Oracle数据库日常维护手册

2006年8月5日 wd 没有评论

Oracle数据库日常维护手册

Oracle数据库运行期间,DBA应该对数据库的运行日志及表空间的使用情况进行监控,及早发现数据库中存在的问题。

一、Oracle警告日志文件监控

Oracle在运行过程中,会在警告日志文件(alert_SID.log)中记录数据库的一些运行情况:

●数据库的启动、关闭,启动时的非缺省参数;

●数据库的重做日志切换情况,记录每次切换的时间,及如果因为检查点(checkpoint)操作没有执行完成造成不能切换,会记录不能切换的原因;

●对数据库进行的某些操作,如创建或删除表空间、增加数据文件;

●数据库发生的错误,如表空间不够、出现坏块、数据库内部错误(ORA-600)

DBA应该定期检查日志文件,根据日志中发现的问题及时进行处理

问题处理

启动参数不对检查初始化参数文件

因为检查点操作或归档操作没有完成造成重做日志不能切换如果经常发生这样的情况,可以考虑增加重做日志文件组;想办法提高检查点或归档操作的效率;

有人未经授权删除了表空间检查数据库的安全问题,是否密码太简单;如有必要,撤消某些用户的系统权限

出现坏块检查是否是硬件问题(如磁盘本生有坏块),如果不是,检查是那个数据库对象出现了坏块,对这个对象进行重建

表空间不够增加数据文件到相应的表空间

出现ORA-600根据日志文件的内容查看相应的TRC文件,如果是Oraclebug,要及时打上相应的补丁

阅读全文…

分类: Other 标签: ,