1.每天固定时间运行，比如早上8:10分钟：Trunc(Sysdate+1) + (8*60+10)/24*60

2.Toad中提供的：

每天：trunc(sysdate)+1

每周：trunc(sysdate)+7

每月：trunc(sysdate)+30

每个星期日：next_day(trunc(sysdate),'SUNDAY')

每天6点：trunc(sysdate)+1+6/24

半个小时：sysdate+30/1440

3.每个小时的第15分钟运行，比如：8:15，9:15，10:15...：trunc(sysdate,'hh')+75/1440。原先我设置的是trunc(sysdate,'hh')+15/1440，发现居然不行。

二。JOB为什么不运行？

1.先来了解一下JOB的参数说明：与job相关的参数一个是job_queue_processes，这个是运行JOB时候所起的进程数，当然系统里面JOB大于这个数值后，就会有排队等候的，最小值是0，表示不运行JOB，最大值是36，在OS上对应的进程时SNPn，9i以后OS上管理JOB的进程叫CJQn。可以使用下面这个SQL确定目前有几个SNP/CJQ在运行。

select * from v$bgprocess，这个paddr不为空的snp/cjq进程就是目前空闲的进程，有的表示正在工作的进程。

另外一个是job_queue_interval，范围在1--3600之间，单位是秒，这个是唤醒JOB的process，因为每次snp运行完他就休息了，需要定期唤醒他，这个值不能太小，太小会影响数据库的性能。

2.诊断：先确定上面这两个参数设置是否正确，特别是第一个参数，设置为0了，所有JOB就不会跑，确认无误后，我们继续向下。

3.使用下面的SQL察看JOB的的broken,last_date和next_date，last_date是指最近一次job运行成功的结束时间，next_date是根据设置的频率计算的下次执行时间，根据这个信息就可以判断JOB上次是否正常，还可以判断下次的时间对不对，SQL如下：

select * from dba_jobs

有时候我们发现他的next_date是4000年1月1日，说明job要不就是在running，要不就是状态是break(broken=Y)，如果发现JOB的broken值为Y，找用户了解一下，确定该JOB是否可以broken，如果不能broken，那就把broken值修改成N，修改再使用上面的SQL察看就发现他的last_date已经变了，JOB即可正常运行，修改broken状态的SQL如下：

 declare

BEGIN

DBMS_JOB.BROKEN(<JOB_ID>,FALSE);

END;

4.使用下面的SQL查询是否JOB还在Running

select * from dba_jobs_running

如果发现JOB已经Run了很久了还没有结束，就要查原因了。一般的JOB running时会锁定相关的相关的资源，可以查看一下v$access和v$locked_object这两个view，如果发现其他进程锁定了与JOB相关的Object，包括PKG/Function/Procedure/Table等资源，那么就要把其他进程删除，有必要的话，把JOB的进程也删除，再重新跑看看结果。

5.如果上面都正常，但是JOB还不run，怎么办？那我们要考虑把JOB进程重启一次，防止是SNP进程死了造成JOB不跑，指令如下：

alter system set job_queue_processes=0 --关闭job进程，等待5--10秒钟

alter system set job_quene_processes=5 --恢复原来的值

6.Oracle的BUG

Oracle9i里面有一个BUG，当计数器到497天时，刚好达到它的最大值，再计数就会变成-1，继续计数就变成0了，然后计数器将不再跑了。如果碰到这种情况就得重启数据库，我们这边有一个生产型的数据库版本是9205，就发生过这样一次问题，后来和用户约时间重启后就没问题了。但是其他的Oracle7345和Oracle8i的数据库没有发现这个问题。

7.数据库上的检查基本上就这多，如果JOB运行还有问题，那需要配合用户察看一下是否是程序本身的问题，比如处理的资料量大，或者网络速度慢等造成运行时过长，那就需要具体情况具体分析了。我们可以通过下面的SQL手工执行一下JOB看看：

declare

begin

dbms_job.run(<job>_ID)

end;

如果发现JOB执行不正常，就要结合程序具体分析一下。

原因：
dbstart和dbshut脚本文件中ORACLE_HOME_LISTNER的设置有问题，分别打开两个文件找到：用vi编辑dbstart，ORACLE_HOME_LISTNER=$1,修改为
ORACLE_HOME_LISTNER=$ORACLE_HOME
 
 
然后保存退出，此时再运行dbstart，已经不报错了，但是没有任何反应，ps一下进程，没有oracle的进程，说明oracle实例没有正常启动。
 
此时的原因是在/etc/oratab的设置问题，我们vi一下，发现
zgz:/home/oracle/product/10g:N
最后设置的是"N"（我的环境中只有一个实例，因此只有一行配置语句），我们需要把“N”修改为“Y”。
 
以上的工作做好之后，dbstart就可以正常使用了：
 
[oracle@redhat bin]$ lsnrctl start                                   --“启动监听”
LSNRCTL for Linux: Version 10.2.0.1.0 - Production on 14-OCT-2009 19:44:53
Copyright (c) 1991, 2005, Oracle.  All rights reserved.
Starting /home/oracle/product/10g/bin/tnslsnr: please wait...
TNSLSNR for Linux: Version 10.2.0.1.0 - Production
System parameter file is /home/oracle/product/10g/network/admin/listener.ora
Log messages written to /home/oracle/product/10g/network/log/listener.log
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC2)))
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=redhat)(PORT=1522)))
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC2)))
STATUS of the LISTENER
------------------------
Alias                     LISTENER
Version                   TNSLSNR for Linux: Version 10.2.0.1.0 - Production
Start Date                14-OCT-2009 19:44:53
Uptime                    0 days 0 hr. 0 min. 0 sec
Trace Level               off
Security                  ON: Local OS Authentication
SNMP                      OFF
Listener Parameter File   /home/oracle/product/10g/network/admin/listener.ora
Listener Log File         /home/oracle/product/10g/network/log/listener.log
Listening Endpoints Summary...
  (DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC2)))
  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=redhat)(PORT=1522)))
Services Summary...
Service "PLSExtProc" has 1 instance(s).
  Instance "PLSExtProc", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully
[oracle@redhat bin]$ dbstart                                   --“启动数据库实例”
Processing Database instance "zgz": log file /home/oracle/product/10g/startup.log
[oracle@redhat bin]$ dbshut                                    --“关闭数据库实例”
[oracle@redhat bin]$ lsnrctl stop                              --“关闭监听”
LSNRCTL for Linux: Version 10.2.0.1.0 - Production on 14-OCT-2009 19:45:33
Copyright (c) 1991, 2005, Oracle.  All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC2)))
The command completed successfully
 
二、如何使数据库实例和linux系统一起启动
在/etc/rc.d/rc.local中加入如下语句即可实现同系统启动实例：
su - oracle -c "lsnrctl start"
su - oracle -c "dbstart" 

l         隔离级别定义了事务与事务之间的隔离程度。

l         隔离级别与并发性是互为矛盾的：隔离程度越高，数据库的并发性越差；隔离程度越低，数据库的并发性越好。

l         ANSI/ISO SQL92标准定义了一些数据库操作的隔离级别：

l          未提交读（read uncommitted）

l          提交读（read committed）

l          重复读（repeatable read）

l          序列化（serializable）

l         通过一些现象，可以反映出隔离级别的效果。这些现象有：

l          更新丢失（lost update）：当系统允许两个事务同时更新同一数据是，发生更新丢失。

l          脏读（dirty read）：当一个事务读取另一个事务尚未提交的修改时，产生脏读。

l          非重复读（nonrepeatable read）：同一查询在同一事务中多次进行，由于其他提交事务所做的修改或删除，每次返回不同的结果集，此时发生非重复读。(A transaction rereads data it has previously read and finds that another committed transaction has modified or deleted the data.  )

l          幻像（phantom read）：同一查询在同一事务中多次进行，由于其他提交事务所做的插入操作，每次返回不同的结果集，此时发生幻像读。(A transaction reexecutes a query returning a set of rows that satisfies a search condition and finds that another committed transaction has inserted additional rows that satisfy the condition.  )

l         下面是隔离级别及其对应的可能出现或不可能出现的现象

ORACLE的隔离级别

l         ORACLE提供了SQL92标准中的read committed和serializable，同时提供了非SQL92标准的read-only。

l          read committed：

l         这是ORACLE缺省的事务隔离级别。

l         事务中的每一条语句都遵从语句级的读一致性。

l         保证不会脏读；但可能出现非重复读和幻像。

l          serializable：

l         简单地说，serializable就是使事务看起来象是一个接着一个地顺序地执行。

l         仅仅能看见在本事务开始前由其它事务提交的更改和在本事务中所做的更改。

l         保证不会出现非重复读和幻像。

l         Serializable隔离级别提供了read-only事务所提供的读一致性（事务级的读一致性），同时又允许DML操作。

l         如果有在serializable事务开始时未提交的事务在serializable事务结束之前修改了serializable事务将要修改的行并进行了提交，则serializable事务不会读到这些变更，因此发生无法序列化访问的错误。（换一种解释方法：只要在serializable事务开始到结束之间有其他事务对serializable事务要修改的东西进行了修改并提交了修改，则发生无法序列化访问的错误。）

l         If a serializable transaction contains data manipulation language (DML) that attempts to update any resource that may have been updated in a transaction uncommitted at the start of the serializable transaction, （并且修改在后来被提交而没有回滚），then the DML statement fails. 返回的错误是ORA-08177: Cannot serialize access for this transaction。

l         ORACLE在数据块中记录最近对数据行执行修改操作的N个事务的信息，目的是确定是否有在本事务开始时未提交的事务修改了本事务将要修改的行。具体见英文：Oracle permits a serializable transaction to modify a data row only if it can determine that prior changes to the row were made by transactions that had committed when the serializable transaction began. To make this determination efficiently, Oracle uses control information stored in the data block that indicates which rows in the block contain committed and uncommitted changes. In a sense, the block contains a recent history of transactions that affected each row in the block. The amount of history that is retained is controlled by the INITRANS parameter of CREATE TABLE and ALTER TABLE. Under some circumstances, Oracle may have insufficient history information to determine whether a row has been updated by a "too recent" transaction. This can occur when many transactions concurrently modify the same data block, or do so in a very short period. You can avoid this situation by setting higher values of INITRANS for tables that will experience many transactions updating the same blocks. Doing so will enable Oracle to allocate sufficient storage in each block to record the history of recent transactions that accessed the block.

l          The INITRANS Parameter：Oracle stores control information in each data block to manage access by concurrent transactions. Therefore, if you set the transaction isolation level to serializable, you must use the ALTER TABLE command to set INITRANS to at least 3. This parameter will cause Oracle to allocate sufficient storage in each block to record the history of recent transactions that accessed the block. Higher values should be used for tables that will undergo many transactions updating the same blocks.

l          read-only：

l         遵从事务级的读一致性，仅仅能看见在本事务开始前由其它事务提交的更改。

l         不允许在本事务中进行DML操作。

l         read only是serializable的子集。它们都避免了非重复读和幻像。区别是在read only中是只读；而在serializable中可以进行DML操作。

l         Export with CONSISTENT = Y sets the transaction to read-only.

l          read committed和serializable的区别和联系：

l         事务1先于事务2开始，并保持未提交状态。事务2想要修改正被事务1修改的行。事务2等待。如果事务1回滚，则事务2（不论是read committed还是serializable方式）进行它想要做的修改。如果事务1提交，则当事务2是read committed方式时，进行它想要做的修改；当事务2是serializable方式时，失败并报错“Cannot serialize access”，因为事务2看不见事务1提交的修改，且事务2想在事务一修改的基础上再做修改。具体见英文：Both read committed and serializable transactions use row-level locking, and both will wait if they try to change a row updated by an uncommitted concurrent transaction. The second transaction that tries to update a given row waits for the other transaction to commit or roll back and release its lock. If that other transaction rolls back, the waiting transaction (regardless of its isolation mode) can proceed to change the previously locked row, as if the other transaction had not existed. However, if the other (blocking) transaction commits and releases its locks, a read committed transaction proceeds with its intended update. A serializable transaction, however, fails with the error "Cannot serialize access", because the other transaction has committed a change that was made since the serializable transaction began.

l         read committed和serializable可以在ORACLE并行服务器中使用。

l          关于SET TRANSACTION READ WRITE：read write和read committed 应该是一样的。在读方面，它们都避免了脏读，但都无法实现重复读。虽然没有文档说明read write在写方面与read committed一致，但显然它在写的时候会加排他锁以避免更新丢失。在加锁的过程中，如果遇到待锁定资源无法锁定，应该是等待而不是放弃。这与read committed一致。

l         语句级的读一致性

l          ORACLE保证语句级的读一致性，即一个语句所处理的数据集是在单一时间点上的数据集，这个时间点是这个语句开始的时间。

l          一个语句看不见在它开始执行后提交的修改。

l          对于DML语句，它看不见由自己所做的修改，即DML语句看见的是它本身开始执行以前存在的数据。

l         事务级的读一致性

l          事务级的读一致性保证了可重复读，并保证不会出现幻像。

l         设置隔离级别

l          设置一个事务的隔离级别

l         SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

l         SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;

l         SET TRANSACTION READ ONLY;

l         设置增个会话的隔离级别

l         ALTER SESSION SET ISOLATION_LEVEL SERIALIZABLE;

l         ALTER SESSION SET ISOLATION_LEVEL READ COMMITTED;

脏读 （dirty read）事务T1更新了一行记录的内容，但是并没有提交所做的修改。事务T2读取更新后的行，然后T1执行回滚操作，取消了刚才所做的修改。现在T2所读取的行就无效了。

不可重复读取 （nonrepeatable read）事务T1读取一行记录，紧接着事务T2修改 了T1刚才读取的那一行记录。然后T1又再次读取这行记录，发现与刚才读取的结果不同。这就称为“不可重复”读，因为T1原来读取的那行记录已经发生了变化。

幻像读取 （phantom read）事务T1读取一条指定的WHERE子句所返回的结果集。然后事务T2新插入 一行记录，这行记录恰好可以满足T1所使用的查询条件中的WHERE 子句的条件。然后T1又使用相同的查询再次对表进行检索，但是此时却看到了事务T2刚才插入的新行。这个新行就称为“幻像”，因为对T1来说这一行就像突 然出现的一样。

2.事务的隔离级别

从级别低到高依次为：

READ UNCOMMITTED 幻像读、不可重复读和脏读都允许。

READ COMMITTED 允许幻像读、不可重复读，但不允许脏读。

REPEATABLE READ 允许幻像读，但不允许不可重复读和脏读。InnoDB默认级别

SERIALIZABLE 幻像读、不可重复读和脏读都不允许。

但是InnoDB的可重复读隔离级别和其他数据库的可重复读是有区别的，不会造成幻象读（phantom read）。

ORACLE数据库支持 READ COMMITTED 和 SERIALIZABLE ，不支持 READ UNCOMMITTED 和 REPEATABLE READ 。

3.测试：

1）并发更新 ，表tab1 的一条记录id=1 num=1，两个session分别执行事务1，2

分别输入下面的语句

事务1 (session1) ：

           start transaction;

           update tab1 set num=num+1 where id=1；

=========

一条记录被更新，select发现num=2;

事务2 (session2)：

           start transaction;

           update tab1 set num=num+1 where id=1;

=========

事务2会被阻塞，然后session1输入commit;提交事务1。此时事务2更新成功。

session1 select一下会发现num还是2（不允许脏读 ）；session2 select 一下 num 为3（update可以得到最新提交过的数据然后更新，但是如果没有update，一直是select 的话select得到的num一直是1 ），然后commit；

session1 select 发现num为3 ，session2 select 发现num为3；

所以，事务中update是有行写锁（排他锁）的，不会发生： 脏读和不可重复读（对于自身有update的事务，update之后是可以读到最新数据的，这属于例外？^_^ ），

2）关于幻象读 ，innodb默认事务隔离级别是不会出现的；摘自网上，测试通过：

mysql> set autocommit=off;
Query OK, 0 rows affected (0.00 sec)

session 1 创建表并插入测试数据

mysql> create table test(i int) engine=innodb;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into test values(1);
Query OK, 1 row affected (0.00 sec)
session 2 查询，没有数据，正常，session1没有提交，不允许脏读

mysql> select * from test;
Empty set (0.00 sec)
session 1 提交事务

mysql> commit;
Query OK, 0 rows affected (0.00 sec)
session 2 查询，还是没有数据，没有产生幻象读

mysql> select * from test;
Empty set (0.00 sec)
4.最后，现在应该知道数据库并发控制并不复杂，交给数据库的事务就行，mysql 选用innodb引擎，不会出现：“不可重复读”（就是在事务1进行数据修改的时候，事务2读取的数据是没修改 之前的数据，事务1提交的时候，事务2再次读取的时候得到的是修改后的数据，单个事务内所读数据不一致），“脏读”，“幻象读”；

 关于innodb锁机制的详细解释，参见《mysql手册》-“15.2.10 .  InnoDB 事务模型和锁定”。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/todd_liu/archive/2010/09/10/5875650.aspx