早上做个实验,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) 更易于恢复