早上做个实验,update数据的时候报错ora-30036:无法按8扩展段（在还原表空间‘undotbs_new’中）

1.查询了一下undo表空间的使用,发现已经超过了80%

SELECT a.tablespace_name as tablespace_name,
       to_char(b.total/1024/1024,999999.99) as Total,
       to_char((b.total-a.free)/1024/1024,999999.99) as Used,
       to_char(a.free/1024/1024,999999.99) as Free,
       to_char(round((total-free)/total,4)*100,999.99) as Used_Rate
FROM (SELECT tablespace_name, sum(bytes) free FROM DBA_FREE_SPACE GROUP BY tablespace_name) a,
     (SELECT tablespace_name, sum(bytes) total FROM DBA_DATA_FILES GROUP BY tablespace_name ) b
WHERE a.tablespace_name=b.tablespace_name
  AND a.tablespace_name='UNDOTBS_NEW'
ORDER BY a.tablespace_name;

2.将undo表空间大小重新加大点,解决问题~
这几天安装oracle,检查包的时候,发现一些包没有装上,使用rpm来装的时候,又发现包的依耐性很重,所以就搭建一个本地的源,使用yum install来安装.

1.挂载安装介质 

2.vi /etc/yum.repos.d/server.repo

3.如果安装软件包提示没有key的话导入key

1.查看版本
2.管理
当服务器没有装图形化界面的时候,如不能使用xhost之类的命令,就不能使用vnc了,那这个时候可以使用xmanager来代替

1.网上可以下载一个xmanager企业版,下载完后打开Xbrowser,在help-->about Xbrowser中输入注册码

2.在服务器端
DISPLAY=192.168.X.X:0.0
export DISPLAY
echo $DISPLAY

3.使用xmanager的xshell来打开图形化界面.(有可能会提醒运行一个rootpre之类的脚本) 在虚拟机上起动系统的时候,每次都发现Sendmail服务很费时间,决定将其关闭了,反正也没怎么用.
1.关闭sendmail服务

2.关闭sendmail自启动

[root@node1 ~]# chkconfig sendmail off

直接alter index xxx rebuild tablespace xxx 不得行.
要酱紫,移动表的时候顺带一起移动:
1.报错:
2.出错原因:缺少系统安装包:rpm -ivh libXp-1.0.0-8.i386.rpm      摘要: oracle读取数据的最小单位是块.oracle读取数据的最大限制取决于OS和oracle对多块读I/O的限制(db_file_multiblock_read_count).物理上来说,一个sql读取某个记录,得将记录读取到DB Cache中,然后才能从中或者,这个称为物理读.如果这个数据已经存在于DB Cache中,那么前台进程可以直接冲DB Cache中读取数据,这个称谓逻辑读.逻辑上来说,有...  阅读全文 监控flash_recovery_area的使用情况可以查询2个视图:
1.V$FLASH_RECOVERY_AREA_USAGE:displays usage information about flashback recovery areas
2.V$RECOVERY_FILE_DEST:displays information about the disk quota and current disk usage in the flash recovery area.
1.先将备份的控制文件和数据文件copy到原来的位置
2.mount数据库
3.RECOVER DATABASE USING BACKUP CONTROLFILE
4.ALTER DATABASE OPEN RESETLOGS;

代码如下:
直接摘录2段话:
1.Set NORESETLOGS case
The following commands will create a new control file and use it to open the database.
Data used by Recovery Manager will be lost.
Additional logs may be required for media recovery of offline.
Use this only if the current versions of all online logs are available.

2.Set RESETLOGS case
The following commands will create a new control file and use it to open the database.
Data used by Recovery Manager will be lost.
The contents of online logs will be lost and all backups will be invalidated.
Use this only if online logs are damaged. 1.控制文件全部丢失,在线重做日志丢失,如果有备份的2进制的控制文件也不能使用,为什么呢?因为用备份的控制文件进行恢复时(RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CANCEL),由于使用了备份的控制文件，备份之后的归档日志信息丢失,所以需要在线重做日志来进行介质恢复,而当前的情况是在线重做日志也丢失了,所以只能进行手工创建控制文件.
2.以alter database open resetlogs打开数据库
2.1如果当初关闭数据库时是非正常关闭,那么在打开数据库之前应该先RECOVER DATABASE USING BACKUP CONTROLFILE
3.添加temp文件

代码如下:

SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> host del D:\oracle\product\10.2.0\oradata\suredd\control*.ctl

SQL>  host del D:\oracle\product\10.2.0\oradata\suredd\redo*.log

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

Total System Global Area  612368384 bytes
Fixed Size                  1250428 bytes
Variable Size             226495364 bytes
Database Buffers          377487360 bytes
Redo Buffers                7135232 bytes
SQL> edit
已写入 file afiedt.buf

  1  CREATE CONTROLFILE REUSE DATABASE "SUREDD" RESETLOGS  ARCHIVELOG
  2      MAXLOGFILES 16
  3      MAXLOGMEMBERS 3
  4      MAXDATAFILES 100
  5      MAXINSTANCES 8
  6      MAXLOGHISTORY 292
  7  LOGFILE
  8    GROUP 1 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\SUREDD\REDO01.LOG'  SIZE 50M,
  9    GROUP 2 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\SUREDD\REDO02.LOG'  SIZE 50M,
 10    GROUP 3 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\SUREDD\REDO03.LOG'  SIZE 50M
 11  DATAFILE
 12    'D:\ORACLE\PRODUCT\10.2.0\ORADATA\SUREDD\SYSTEM01.DBF',
 13    'D:\ORACLE\PRODUCT\10.2.0\ORADATA\SUREDD\SYSAUX01.DBF',
 14    'D:\ORACLE\PRODUCT\10.2.0\ORADATA\SUREDD\USERS01.DBF',
 15    'D:\ORACLE\PRODUCT\10.2.0\ORADATA\SUREDD\EXAMPLE01.DBF',
 16    'D:\ORACLE\PRODUCT\10.2.0\ORADATA\SUREDD\DDTESTTBS02.DBF',
 17    'D:\ORACLE\PRODUCT\10.2.0\ORADATA\SUREDD\UNTOTBS_NEW_01.DBF'
 18* CHARACTER SET ZHS16GBK
SQL> /

控制文件已创建。

SQL> ALTER DATABASE OPEN RESETLOGS;

数据库已更改。

SQL> ALTER TABLESPACE TEMP ADD TEMPFILE 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\SUREDD\TEMP01.DBF'
  2       SIZE 20971520  REUSE AUTOEXTEND ON NEXT 655360  MAXSIZE 32767M;

表空间已更改。

SQL> select * from dd.t1;

        ID NAME
---------- ----------
         1 test1
         2 test2

SQL> 

     摘要: 1.错误描述:在做一次恢复后,数据库能正常打开,数据表也能正常查询,但过不了多久数据库会自动down掉 2.查看alert日志,发现如下信息 Thu May 05 13:30:26 2011 Flush retried for xcb 0x333acd74, pmd 0x33bdaa68 D...  阅读全文 1.将备份的控制文件(这里的备份指的是2进制的备份文件,非trace那个)copy到原来的位置
2.启动到mount状态
3.recover database using backup controlfile until cancel
4.再找重做联机日志恢复数据
5.alter database open resetlogs

代码如下:
1.归档日志已经备份并被删除掉原来的
2.在执行一些恢复操作时,可能会使用到以前的归档日志,但这个时候∵已经在原来的位置将归档日志删除,所以恢复时如果使用到归档日志的话会报错说找不着文件
3.解决方法:将归档日志copy回原来的位置,恢复时指定新的位置,或者使用SET LOGSOURCE,指向新的归档位置

代码如下:
1.还是用UE破坏所有的控制文件,并做checkpoint
2.连接数据库,将数据库启动到nomount状态
3.创建controlfile为noresetlog
4.recover数据库
5.归档所有日志
6.open数据库
7.添加temp表空间的数据文件

过程如下:
第一种情况:损坏的控制文件的磁盘位置仍能使用
1.将好的控制文件copy过去
2.startup

第二种情况:损坏的控制文件的磁盘位置不可用
1.在新的位置将好的控制文件copy过去
2.修改spfile,使得里面的控制文件的路径指向正确
3.startup 1.将数据库abort掉,然后破坏对应的数据文件
2.startup数据库,因为此时被破坏了,所以数据库只能到mount状态
3.当前情况是没有数据文件的备份,但是有完好的归档
4.∴可以利用create datafile来进行恢复
具体参看代码:


注意:在这个地方要求:需要表空间创建后所有的归档日志，且控制文件中必须包含受损文件名

如果不是这样子的话,则会出现下面的情况:

SQL> select status from v$instance;

STATUS
------------
OPEN

SQL> SELECT * FROM V$RECOVER_FILE;

     FILE# ONLINE  ONLINE_ ERROR                                                                CHANGE# TIME
---------- ------- ------- ----------------------------------------------------------------- -------
         6 OFFLINE OFFLINE FILE NOT FOUND                                                             0


SQL> alter database create datafile 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\SUREDD\DDTESTTBS02.DBF'
  2  as 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\SUREDD\DDTESTTBS01.DBF';
alter database create datafile 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\SUREDD\DDTESTTBS02.DBF'
*
第 1 行出现错误:
ORA-01178: 文件 6 在最后一个 CREATE CONTROLFILE 之前创建, 无法重新创建
ORA-01110: 数据文件 6: 'D:\ORACLE\PRODUCT\10.2.0\ORADATA\SUREDD\DDTESTTBS02.DBF'

查询联机文档:

ORA-01178: file string created before last CREATE CONTROLFILE, cannot recreate
Cause: Attempted to use ALTER DATABASE CREATE DATAFILE to recreate a datafile that existed at the last CREATE CONTROLFILE command. The information needed to recreate the file was lost with the control file that existed when the file was added to the database.
Action: Find a backup of the file, and recover it. Do incomplete recovery to time before file was originally created.

那只有用备份的数据文件进行恢复了.

由此可见,有备份是多么的重要啊!!! 1.先备份数据文件

2.用UE将ddtest对应的数据文件破坏
3.直接shutdown abort,再startup

4.查找需要恢复的数据文件

5.将备份的数据文件直接copy到原位置(因为此时为mount状态,所以可以直接copy,不用offline),再recover,再打开数据库。如果是打开的，(此时做了alter system checkpoint 也能使得表空间不可用),那就将对应的表空间先offline，再执行recover，执行完recover后，再将表空间online。
注:dd.t1这个表在ddtest这个表空间上

至此恢复完成.

1.进行联机表空间备份的步骤

ALTER TABLESPACE BEGIN BACKUP 和ALTER TABLESPACE END
BACKUP 命令之间的间隔时间应尽量缩短，因为修改后的块写入重做日志文件
将导致生成更多的重做信息。因此建议每次执行一个表空间的联机备份。

2.备份状态信息,查询的视图:
(1)V$BACKUP:以确定哪些文件处于备份模式。发出ALTER TABLESPACE BEGIN BACKUP 命令后，状态将更改为ACTIVE。备份文件后，“状态” (STATUS) 列的值将更改为NOT ACTIVE。
(2)V$DATAFILE_HEADER：表空间的数据文件的FUZZY 列中的值将更改为YES，表明相应的文件处于备份模式。
ALTER TABLESPACE END BACKUP 命令后，FUZZY 列的值将更改为NULL

3.联机表空间备份过程中出现故障
查询V$BACKUP 以检查备份状态

4.只读表空间备份
ALTER TABLESPACE query_data READ ONLY;
(1)发出ALTER TABLESPACE 命令后，会对所有与表空间相关联的数据文件执行检查点。然后使用当前SCN 冻结文件头。
(2)使表空间成为只读状态之后，必须备份该表空间的所有数据文件。
DBW0 进程只写入其表空间处于读写模式的数据文件，正常的检查点也只对这些文件执行。

5.只读表空间备份问题
(1)在将表空间更改为只读后，只需要一个备份。
(2)在使表空间成为读写状态之后，应恢复按照正常备份日程对该表空间进行备份。
(3)控制文件必须能正确标识处在只读模式下的表空间；否则，必须恢复该表空间。

6.手动备份控制文件
(1)创建二进制映像

(2)创建文本跟踪文件

(3)以下命令更改数据库配置并导致控制文件更改：

7.使用DBVERIFY 实用程序验证备份
(1)用于确保备份数据库或数据文件在还原之前是有效的
(2)遇到数据损坏问题时可作为有用的诊断辅助工具
(3)使用:%dbv file=/ORADATA/u03/users01.dbf logfile=dbv.log

V$ARCHIVED_LOG：显示控制文件中的归档日志信息
V$ARCHIVE_DEST：对于当前例程，说明所有归档日志目标、当前值、模式和状态。
    INACTIVE 状态表示该目标未定义。VALID 状态表示该目标已启用且没有错误。
要检查每个目标的错误和发生错误的日志序列号，可使用以下查询：
V$LOG_HISTORY：包含控制文件中的日志文件信息
V$DATABASE：归档的当前状态
V$ARCHIVE_PROCESSES：提供有关例程的各种ARCH 进程的状态的信息
    ACTIVE 状态表明进程已启动并正在运行。当前正在归档的进程的状态为BUSY。正忙的进程的LOG_SEQUENCE 列显示该进程正在归档的当前日志序列号

1.LOG_ARCHIVE_DEST_n最多可指定十个归档目标
可以是本地归档:log_archive_dest_1 = "LOCATION=/archive1"
指定的位置必须是有效的，并且不能是一个NFS 装载的目录

也可以是远程归档:log_archive_dest_2 = "SERVICE=standby_db1"
指定的服务名通过使用本地的tnsnames.ora 文件进行解析

2.LOG_ARCHIVE_DEST_n 选项
(1)将归档位置设置为MANDATORY 或OPTIONAL。
MANDATORY:表示必须成功完成归档到该目标的操作才可以覆盖联机重做日志文件。
OPTIONAL:表示即使联机重做日志文件尚未成功地归档到该目标，也可以重新使用。这是缺省设置
(2)在出现故障之后、重试之前定义时间
REOPEN:REOPEN 属性定义发生故障时是否必须重新尝试归档到目标。如果为关键字REOPEN指定了值，如REOPEN=600，则若发生故障，在经过指定时间（以秒计）后，归档程序将尝试写入该目标。缺省值为300 秒。归档到目标的尝试次数没有限制。归档中的所有错误将在主站点的警报文件中报告。
如果未指定REOPEN，则可选目标上的错误将被记录并忽略。不再将重做日志发送到这些目标。在归档成功之前，强制目标上的错误将导致无法重新使用联机重做日志。只要归档不成功，归档目标的状态就设置为ERROR。

1.在10g中,如果启用了归档模式,则自动归档,即使log_archive_start为false
2.在9i中要启用自动归档的话,需要alter system archive log start to '/path'
3.如果数据库设置了db_recovery_file_dest,就不能设置log_archive_dest
4.默认的归档日志存放于db_recovery_file_dest中,如果设置了log_archive_dest_n,那么归档日志不再存放于db_recovery_file_dest中,而是存放于设置的log_archive_dest_n目录中,如果想要归档日志继续存放在db_recovery_file_dest中,可以通过如下命令
alter system set log_archive_dest_2='location=USE_DB_RECOVERY_FILE_DEST';
5.log_archive_dest只能与 log_archive_duplex_dest共存,作用一样
6.如果设置的log_archive_dest_n不正确，那么ORACLE会在设置的上一级目录归档
7.指定多个archive进程工作 log_archive_max_process,最多10个
8.alter system archive log current通知server process去将写满的联机重做日志归档,用于手工归档
9.归档日志格式(log_archive_format):s/S:log sequence number,t/T:thread number,如果为单实例的话,thread===1

NOARCHIVELOG 模式
缺省情况下，数据库是以NOARCHIVELOG 模式创建的。

1.在NOARCHIVELOG 模式下操作数据库时有以下特性：
(1)重做日志文件以循环的方式使用。
(2)重做日志文件可以在检查点发生之后立即重新使用。
(3)重做日志被覆盖后，介质恢复将只能恢复到上一次完全备份。

2.NOARCHIVELOG 模式的含义
(1)如果某个表空间由于故障而不可用，将无法继续对数据库进行操作，除非删除了该表空间或从备份还原了整个数据库。
(2)只能在数据库关闭时对数据库执行操作系统备份。而且，必须使用NORMAL、IMMEDIATE 或TRANSACTIONAL 选项关闭数据库。
(3)必须在每次备份时完整备份所有的数据文件和控制文件。尽管也可以备份联机重做日志文件，但这是不必要的。由于此类备份中日志文件是一致的，无需恢复，因此，不需要备份联机日志。
(4)如果联机重做日志文件已被覆盖，则将丢失上次完全备份后的所有数据。

3.NOARCHIVELOG 模式下的介质恢复选项
必须从数据库的完全备份中还原数据文件和控制文件。如果使用导出实用程序来备份数
据库，则可使用导入实用程序还原丢失的数据。但是，通过这种方法恢复的数据并不完
整，在导出后执行的事务处理工作将丢失。

ARCHIVELOG 模式
在发生检查点并且已经通过ARCn 后台进程备份重做日志文件之前，不能重新使用填满的重做日志文件。控制文件中将有一个条目记录归档日志文件的日志序列号。
对数据库的最新更改在任何时候均可用于例程恢复，而归档重做日志文件可以用于介质恢复。

1.归档要求
(1)数据库必须处于ARCHIVELOG 模式。通过发出命令将数据库置于ARCHIVELOG 模式可以更新控制文件。可以启用ARCn 后台进程来实现自动归档。
(2)应该有足够的资源来存放生成的归档重做日志文件。

2.将数据库设置为ARCHIVELOG 模式的含义
(1)出现介质故障时，可以防止数据库丢失数据。
(2)可以在数据库联机时对其进行备份。
(3)由于介质故障导致表空间（非SYSTEM）脱机时，数据库的其余部分仍可用，因为表空间（非SYSTEM）可以在数据库打开时恢复。

3.介质恢复选项
(1)无论数据库处于联机或脱机状态，都可以还原损坏文件的备份副本，并使用归档日志文件将数据文件更新为当前的版本。
(2)可以将数据库恢复至特定的时间点。
(3)可以将数据库恢复至指定归档日志文件的末尾。
(4)可以将数据库恢复至特定的系统更改号(SCN)。

4.在设置归档日志模式时，应该考虑以下因素：
下述情况中，NOARCHIVELOG 模式可能比较合适：
 (1)容许备份之间的数据损失（在开发、培训期间等）
 (2)重新应用事务处理（从批处理文件）的速度更快
 (3)数据极少更改（非OLTP）
下述情况中，ARCHIVELOG 模式则更合适：
 (1)无法关闭数据库以执行关闭的数据库的备份
 (2)不允许数据损失
 (3) 使用归档重做日志文件比重新应用事务处理(OLTP) 更易于恢复

RAID 0+ 1
优点：
正常使用中,考虑性能上讲,RAID0+1 好,就是先做RAID 0 条带,再做 RAID 1 MIRROR,这样写入速度快,读的速度和RAID1＋0一样.
缺点,一旦一个硬盘坏了,一半的硬盘无法工作,如果1个条带上各坏1个硬盘（RAID0+1只有2个条带）,GAME OVER....即使是只有一个硬盘坏了,做数据恢复也很慢,因为一半的硬盘要rebuild（大家该知道为什么吧）.

RAID 1+0
优点 数据安全性好,只要不是1个条带上的2个硬盘同时坏,没有问题,还可以继续跑数据.数据恢复快.
缺点 写性能稍微比RAID 0+1 差（读性能一样）

这里举个例子,20个硬盘
做RAID 0＋1,共2个条带做MIRROR,每个条带10个硬盘,如果坏了1个硬盘,只能是另外一个完好的条带（10个硬盘）同时工作,这边条带9个好的硬盘也要休息.

做RAID 1＋0,共10个条带,每个条带2个硬盘做MIRROR,如果坏了1个硬盘,没关系,其它19个硬盘还要同时工作,只要不是坏在一个MIRROR里面的,没事.

建议,硬盘很多时,同时坏的几率就比较大,建议使用安全系数高的RAID 1+0,宁愿损失点性能（其实差不多).
如果仅仅是4块硬盘或者不考虑安全,不是关键业务,只是为了追求速度快感,你可以选择RAID 0+1

RAID是通过磁盘阵列与数据条块化方法相结合,以提高数据可用率的一种结构.IBM早于1970年就开始研究此项技术.RAID 可分为RAID级别1到RAID级别6, 通常称为:RAID 0, RAID 1, RAID 2, RAID 3,RAID 4, RAID 5,RAID6.每一个RAID级别都有自己的强项和弱项. "奇偶校验"定义为用户数据的冗余信息, 当硬盘失效时,可以重新产生数据.

RAID 0: RAID 0 并不是真正的RAID结构, 没有数据冗余. RAID 0 连续地分割数据并并行地读/写于多个磁盘上. 因此具有很高的数据传输率. 但RAID 0在提高性能的同时,并没有提供数据可靠性,如果一个磁盘失效,将影响整个数据.因此RAID 0 不可应用于需要数据高可用性的关键应用.
RAID 1: RAID 1通过数据镜像实现数据冗余,在两对分离的磁盘上产生互为备份的数据. RAID 1可以提高读的性能, 当原始数据繁忙时,可直接从镜像拷贝中读取数据.RAID 1是磁盘阵列中费用最高的, 但提供了最高的数据可用率. 当一个磁盘失效,系统可以自动地交换到镜像磁盘上, 而不需要重组失效的数据.
RAID 2: 从概念上讲, RAID 2 同RAID 3类似, 两者都是将数据条块化分布于不同的硬盘上, 条块单位为位或字节.然而RAID 2 使用称为"加重平均纠错码"的编码技术来提供错误检查及恢复.这种编码技术需要多个磁盘存放检查及恢复信息, 使得RAID 2技术实施更复杂.因此,在商业环境中很少使用.
RAID 3: 不同于RAID 2, RAID 3使用单块磁盘存放奇偶校验信息. 如果一块磁盘失效, 奇偶盘及其他数据盘可以重新产生数据. 如果奇偶盘失效,则不影响数据使用.RAID 3对于大量的连续数据可提供很好的传输率, 但对于随机数据, 奇偶盘会成为写操作的瓶颈.
RAID 4: 同RAID 2, RAID 3一样, RAID 4, RAID 5也同样将数据条块化并分布于不同的磁盘上, 但条块单位为块或记录. RAID 4使用一块磁盘作为奇偶校验盘, 每次写操作都需要访问奇偶盘, 成为写操作的瓶颈. 在商业应用中很少使用.
RAID 5: RAID 5没有单独指定的奇偶盘, 而是交叉地存取数据及奇偶校验信息于所有磁盘上.在RAID5 上, 读/写指针可同时对阵列设备进行操作, 提供了更高的数据流量.RAID 5更适合于小数据块, 随机读写的数据.RAID 3 与RAID 5相比, 重要的区别在于RAID 3每进行一次数据传输,需涉及到所有的阵列盘.而对于RAID 5来说, 大部分数据传输只对一块磁盘操作, 可进行并行操作.在RAID 5中有"写损失", 即每一次写操作,将产生四个实际的读/写操作, 其中两次读旧的数据及奇偶信息, 两次写新的数据及奇偶信息.
RAID 6: RAID 6 与RAID 5相比,增加了第二个独立的奇偶校验信息块. 两个独立的奇偶系统使用不同的算法, 数据的可靠性非常高.即使两块磁盘同时失效,也不会影响数据的使用.但需要分配给奇偶校验信息更大的磁盘空间, 相对于RAID 5有更大的"写损失".RAID 6 的写性能非常差, 较差的性能和复杂的实施使得RAID 6很少使用.

web服务器数据库服务器分离-->垂直分割(按功能)-->分布式(按用户数)-->增加数据缓存层

页面静态化(apache?)
存储分离,页面图片分开
数据库的水平分割和垂直分割
各层的缓存技术:Oracle(cache group),hibernate(session缓存,sessionFactory缓存,好像名字叫Ehcache ),memcache,oscache
负载均衡:集群? 7层模型每一层都有解决方案

这个类型支持前后滚动取得纪录next（）、previous()，回到第一行first()，同时还支持要去的ResultSet中的第几行absolute（int n），以及移动到相对当前行的第几行relative(int n)，要实现这样的ResultSet在创建Statement时用如下的方法。
Statement st = conn.createStatement(int resultSetType, int resultSetConcurrency)
ResultSet rs = st.executeQuery(sqlStr)
其中两个参数的意义是：
resultSetType是设置ResultSet对象的类型可滚动，或者是不可滚动。取值如下：
ResultSet.TYPE_FORWARD_ONLY只能向前滚动
ResultSet.TYPE_SCROLL_INSENSITIVE和Result.TYPE_SCROLL_SENSITIVE这两个方法都能够实现任意的前后滚动，使用各种移动的ResultSet指针的方法。二者的区别在于前者对于修改不敏感，而后者对于修改敏感。
resultSetConcurency是设置ResultSet对象能够修改的，取值如下：
ResultSet.CONCUR_READ_ONLY 设置为只读类型的参数。
ResultSet.CONCUR_UPDATABLE 设置为可修改类型的参数。
所以如果只是想要可以滚动的类型的Result只要把Statement如下赋值就行了。
Statement st = conn.createStatement(Result.TYPE_SCROLL_INSENITIVE,
ResultSet.CONCUR_READ_ONLY);
ResultSet rs = st.excuteQuery(sqlStr)；

我们根据统计信息的详细程度可以设置不同的级别，每种级别见STATS$level_DESCRIPTION;
0： 一性性能统计:包含回退段状态、字典缓存、SGA、系统事件、后台事件、会话事件、系统统计、等待统计、锁统计、闩锁统计 
5： 增加了收集SQL的信息、并包括0级收集的信息。　　
6： 增强了在SQL收集信息方面的功能(列出占用资源较高的SQL),并包所有低级别的信息。 
7 增加了收集段级别的统计信息(如段的逻辑读与物理读、行锁、ITL及buffer busy waits), 并包括所有低级别的信息。 
10 :   增加了收集子LATCH锁的信息,并包括所有低级别的信息。 
　　如果你收用statspack确定热表及热索引,那就需要使用7/10的级别来收集快照。
9I默认是5级
我们可以手工修改这个级别：
永久修改收集级别
SQL>EXECUTE STATSPACK.SNAP(I_SNAP_LEVEL=>0,I_MODIFY_PARAMETER=>’TRUE’);
临时修改
SQL>EXECUTE STATSPACK.SNAP(I_SNAP_LEVEL=>0);

一些常用的动态性能试图
1.先来张总的

2.  实例级别统计

上面两个框是系统统计信息，包括了一些性能指标，有STAT关键字
下面两个框是事件统计信息，有EVENT关键字，包括了各种不同类型的等待事件信息

3.会话级别统计

上面三个框是会话的系统统计信息，包括了一些性能指标，有STAT关键字。
下面三个框是会话的事件统计信息，包括了该会话各种不同类型的等待事件信息，有EVENT或WAIT关键字。

4.这些事件都列在V$EVENT_NAME视图中，拥有以下字段：
EVENT#
事件号
NAME
事件名
PARAMETER1
第一个参数名
PARAMETER2
第二个参数名
PARAMETER3
第三个参数名

5.事件统计信息
V$SYSTEM_EVENT: 所有会话对一个事件的总等待，它是累计信息。
V$SESSION_EVENT: 每个会话对一个事件的总等待，它是累计信息。
V$SESSION_WAIT:正在等待的当前活动对一个事件的等待，它是实时状态。

6.V$SYSTEM_EVENT:整个实例某个特定等待事件的统计值


7.V$SESSION_EVENT: 

某个会话特定等待事件的统计值

8. V$SESSION_WAIT :当前会话正在等待的事件及统计信息,我们通过它能准确的发现当前性能问题的现象是什么

WAIT_TIME
非0:最近一次等待的时间, (当STATE为waited known time,单位为厘秒)
0:当前正在等待

STATE
waiting:
正在等待中,该状态,通常seconds_in_wait会有值
waited known time:
现在已经不等待了,但提供了详细的等待信息
waited short time:
现在已经不等待了,但提供了简短的等待信息

一.调优的目标:
1.减少响应时间
2.减少数据库块访问
3.尽量把常用的块CACHE到内存中,提高访问的速度
4.提高OLTP的吞吐量
5.设置系统的负载

二.数据库的系统响应时间:
response time = service time + wait time
service's meaning:cpu used by this session

时间单位:9i以后单位是百万分之一秒
其中Service Time = SQL解析时间 + 递归调用时间 + 其他时间

1.视图的使用
--实例级系统性能视图:v$sysstat
使用:(以CPU used by this session为例)

select * from v$sysstat t where t.name ='CPU used by this session';

--会话级系统性能试图:

select a.STATISTIC# from v$statname a  where a.NAME like '%CPU used by this session%';

找到STATISTIC#,代入到下面
--当前所有session的

select * from v$sesstat b where b.STATISTIC# = &STATISTIC#;

--自己的session的

select * from v$mystat c where c.STATISTIC# = &STATISTIC#;

--或者直接

select b.sid, a.STATISTIC#, a.name, b.value
  from v$statname a, v$mystat b
 where a.STATISTIC# = b.STATISTIC#;
 and a.name like '%xxxxxxx%'

2.sql解析时间(sql解析过程..比较重要,后面专门写一篇)

  select name, sid, value "Total parse Cpu time"
          from v$statname a, v$mystat b
         where a.name like '%parse%'
           and a.statistic# = b.statistic#

3.递归调用时间是用在语义分析阶段查找数据字典或者PLSQL内部包造成的解析所花的CPU时间

select * from v$statname a  where a.NAME like '%recursive cpu%';

实例级和会话级查询方法同上

4.其它CPU时间:通常占绝大多数，它是执行内存BUFFER搜索，索引和全表扫描涉及的IO操作所占有的CPU

select a.VALUE as "Total CPU",
       b.VALUE as "Parse CPU",
       c.VALUE as "Recursive CPU",
       a.VALUE - b.VALUE - c.VALUE as "Others"
  from v$sysstat a, v$sysstat b, v$sysstat c
 where a.NAME = 'CPU used by this session'
   and b.NAME = 'parse time cpu'
   and c.NAME = 'recursive cpu usage';

5.等待常是由于并发，需要等待别的会话处理完独占的资源后所花的时间，这通常也是最常见的性能问题.
如果等待时间（wait time）占响应时间(Pesponse time)的大多数时，我们需要减小等待时间来提高系统性能。我们需要剥离等待时间来分析和优化等待时间

   select d.EVENT, d.TIME_WAITED, d.AVERAGE_WAIT
     from v$system_event d
    where d.EVENT not in
          ('pmon timer', 'rdbms ipc message', 'smon timer',
           'virtual circuit status', 'SQL*Net message from client')

not in 里面的event通常被认为是不会产生等待的事件

三.相关视图
1.v$sysstat
这个使徒列出系统统计数据.为找到与每个统计数据号(STATISTIC#)关联的统计数据
名称，请参阅V$STATNAME.
列 数据类型 说明
STATISTIC# NUMBER 统计数据号
NAME VARCHAR2 统计数据名
CLASS NUMBER 统计数据类别:1(用户);2(重做);
4(排队);8(高速缓存);16(操
作系统);32(并行服务器);64
(SQL);128(调试)
VALUE NUMBER 统计数据值
CLASS NUMBER 统计数据类别:

2.v$sesstat
这个视图给出用户会话的统计数据.为了找到与每个统计数据号(STATISTIC#)有关的
统计数据名称，请参阅V$STATNAME.
列 数据类型 说明
SID NUMBER 会话标识符
STATISTIC# NUMBER 统计数据名(标识符)
VALUE NUMBER 统计数据值

3.v$mystat
这个视图包含当前会话的统计数据。
列 数据类型 说明
SID NUMBER 当前会话的ID
STATISTIC NUMBER 统计数据号
VALUE NUMBER 统计数据值

4.v$statname
这个视图显示列在V$SESSTAT 和V$SYSSTAT 表中的统计数据的解码统计数据名。详细信
息，请参阅V$SESSTAT 和SYSSTAT。
列 数据类型 说明
STATISTIC# NUMBER 统计数据号
NAME VARCHAR2 统计数据名。参见表B-13
CLASS NUMBER 1(用户);2(重做);4(排
队);8（高速缓存);16(操
作系统);32(并行服务器);
128(调试)

 

     摘要:     DB Name DB Id Instance ...  阅读全文

1.NESTED LOOP

 对于被连接的数据子集较小的情况，nested loop连接是个较好的选择。nested loop就是扫描一个表，每读到一条记录，就根据索引去另一个表里面查找，没有索引一般就不会是 nested loops。
一般在nested loop中， 驱动表满足条件结果集不大，被驱动表的连接字段要有索引，这样就走nstedloop。如果驱动表返回记录太多，就不适合nested loops了。如果连接字段没有索引，则适合走hash join，因为不需要索引。
可用ordered提示来改变CBO默认的驱动表，可用USE_NL(table_name1 table_name2)提示来强制使用nested loop。

2.HASH JOIN

 hash join是CBO 做大数据集连接时的常用方式。优化器扫描小表（或数据源），利用连接键（也就是根据连接字段计算hash 值）在内存中建立hash表，然后扫描大表，每读到一条记录就来探测hash表一次，找出与hash表匹配的行。
当小表可以全部放入内存中，其成本接近全表扫描两个表的成本之和。如果表很大不能完全放入内存，这时优化器会将它分割成若干不同的分区，不能放入内存的部分就把该分区写入磁盘的临时段，此时要有较大的临时段从而尽量提高I/O 的性能。临时段中的分区都需要换进内存做hash join。这时候成本接近于全表扫描小表+分区数*全表扫描大表的代价和。
    至于两个表都进行分区，其好处是可以使用parallel query，就是多个进程同时对不同的分区进行join，然后再合并。但是复杂。
使用hash join时，HASH_AREA_SIZE初始化参数必须足够的大，如果是9i，Oracle建议使用SQL工作区自动管理，设置WORKAREA_SIZE_POLICY 为AUTO，然后调整PGA_AGGREGATE_TARGET即可。
以下条件下hash join可能有优势：
两个巨大的表之间的连接。
在一个巨大的表和一个小表之间的连接。
可用ordered提示来改变CBO默认的驱动表，可用USE_HASH(table_name1 table_name2)提示来强制使用hash join。

3.SORT MERGE JOIN

sort merge join的操作通常分三步：对连接的每个表做table access full；对table access full的结果进行排序；进行merge join对排序结果进行合并。sort merge join性能开销几乎都在前两步。一般是在没有索引的情况下，9i开始已经很少出现了，因为其排序成本高，大多为hash join替代了。
通常情况下hash join的效果都比sort merge join要好，然而如果行源已经被排过序，在执行sort merge join时不需要再排序了，这时sort merge join的性能会优于hash join。
在全表扫描比索引范围扫描再通过rowid进行表访问更可取的情况下，sort merge join会比nested loops性能更佳。
可用USE_MERGE(table_name1 table_name2)提示强制使用sort merge join。

4.半连接
nested loops semi是nested loop连接的变种，又叫半连接。原理与nl相同，通常用于in,exist操作，这种操作join时候，通常查找到一条纪录就可以了，所以用semi表示。与semi相似的有一种叫anti，反连接，一般用于not in,not exists，也有nest loop anti和hash anti两种。

5.星形

常用于OLAP系统

1.观察cache size,观察主机内存情况,判断SGA的内存分配是否合理
2.观察load profile的transaction情况,判断系统的繁忙程度
3.观察load profile的parse和hard prase值,观察是否存在过多的硬解析
4.观察top5 timed event查看系统的瓶颈所在
5.关注6个order by的sql语句      摘要:         TABLE函数可接受查询语句或游标作为输入参数，并可输出多行数据。该函数可以平行执行，并可持续输出数据流，被称作管道式输出。应用TABLE函数可将数据转换分阶段处理，并省去中间结果的存储和缓冲表.         TABLE函数（它...  阅读全文 配置 ASMLib,遇到一个问题,如图:


可能的问题:
1.linux的selinux没有关闭
2.驱动不对.

1.关闭selinux
再重启:

2.如果第一个不能解决问题,再查看驱动是否正确.
注意标黄色的这个驱动应该为:oracleasm-2.6.9-78.ELsmp-2.0.5-1.el4.i686.rpm..
去oracle官网上找到该驱动并下载下来,重新安装.

搞定:

ORA-12514可能的原因:
1.主机没有启动数据库
2.主机有多个ip地址,没在/etc/hosts中配置全
3.监听器配置错误,一劳永逸的方法是采用静态注册的方式

硬解析需要更多的内存空间, 更多的并发控制对于频繁执行的语句性能会显著的降低,所以对相似的语句只有某些数值变化的语句改写成完全相同的文本,我们称其为绑定.

手工绑定:

不绑定:

系统绑定:
CURSOR_SHARING
exact:文本完全相同的SQL语句才可共享cursor, exact必须精确
force:server 端强制绑定变量
similar:存在histogram(直方图)时对于不同的变量值重新解析,相当于SIMILAR=EXACT, 不存时与force一样

1.

SQL> create table testlong(l1 long,id int);

表已创建。

SQL>
SQL> insert into testlong values('aaaaaaaa',1);

已创建 1 行。

SQL> commit;

提交完成。

2. 3. 4. 1.查看表的使用情况的一些指标

2.其中的8192可以查DBA_TABLESPACES (TS$)获取

Oracle 10g默认的归档日志存放在flash_recovery_area，如果归档日志超过了默认值的大小,则会报ORA-16014的错误.

1.出错

2.查看归档日志区的大小

3.检查flash recovery area的使用情况


4.计算后,发现使用了2.96G>2G,将值设为4G,重新启动,成功
1. create user aaa identified by 123 123需要用引号
2. 查看当前有什么权限,查看session_privs
3. 查看当前有什么角色,查看session_roles
4. 让用户的口令失效alter user xxx password expire
5. 回收的系统权限不递归,对象权限会级联
6. create database时,如果文件已经存在，不能直接覆盖原来文件,使用REUSE语句
7. alter system disable/enable restricted session;


 

改动之前:

SID_LIST_LISTENER =

  (SID_LIST =

    (SID_DESC =

      (SID_NAME = PLSExtProc)

      (ORACLE_HOME = C:\oracle\product\10.2.0\db_1)

      (PROGRAM = extproc)

    )

  )

 

LISTENER =

  (DESCRIPTION_LIST =

    (DESCRIPTION =

      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))

      (ADDRESS = (PROTOCOL = TCP)(HOST = sure1212)(PORT = 1521))

    )

  )

在netmanager中添加数据库的监听 

改动之后:

SID_LIST_LISTENER =

  (SID_LIST =

    (SID_DESC =

      (SID_NAME = PLSExtProc)

      (ORACLE_HOME = C:\oracle\product\10.2.0\db_1)

      (PROGRAM = extproc)

    )

    (SID_DESC =

      (GLOBAL_DBNAME = TEST.SURE)

      (ORACLE_HOME = C:\oracle\product\10.2.0\db_1)

      (SID_NAME = test)

    )

  )

 

LISTENER =

  (DESCRIPTION_LIST =

    (DESCRIPTION =

      (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1))

    )

    (DESCRIPTION =

      (ADDRESS = (PROTOCOL = TCP)(HOST = sure1212)(PORT = 1521))

    )

  )

1.

SQL> drop user sysman cascade;

用户已删除。

SQL> drop role MGMT_USER;

角色已删除。

SQL> drop user MGMT_VIEW cascade;

用户已删除。

SQL> drop public synonym MGMT_TARGET_BLACKOUTS;

同义词已删除。

SQL> drop public synonym SETEMVIEWUSERCONTEXT;

同义词已删除。

2.emca -deconfig dbcontrol db -repos drop

3.emca -config dbcontrol db -repos create