Linux下Oracle9iRMAN备份及恢复步骤介Word文件下载.docx

Linux下Oracle9iRMAN备份及恢复步骤介Word文件下载.docx

《Linux下Oracle9iRMAN备份及恢复步骤介Word文件下载.docx》由会员分享，可在线阅读，更多相关《Linux下Oracle9iRMAN备份及恢复步骤介Word文件下载.docx（15页珍藏版）》请在冰点文库上搜索。

configurecontrolfileautobackupon;

（打开控制文件与服务器参数文件的自动备份）

configurecontrolfileautobackupformatfordevicetypediskto'

/backup1/ctl_%F'

（设置控制文件与服务器参数文件自动备份的文件格式）

4、查看所有设置：

showall

5、查看数据库方案报表：

reportschema;

6、备份全库：

backupdatabaseplusarchivelogdeleteinput;

（备份全库及控制文件、服务器参数文件与所有归档的重做日志，并删除旧的归档日志）

7、备份表空间：

backuptablespacesystemplusarchivelogdeleteinput;

（备份指定表空间及归档的重做日志，并删除旧的归档日志）

8、备份归档日志：

backuparchivelogalldeleteinput;

9、复制数据文件：

copydatafile1to'

/oracle/dbs/system.copy'

10、查看备份和文件复本：

listbackup;

11、验证备份：

validatebackupset3;

12、从自动备份中恢复服务器参数文件：

startupnomount;

（启动实例）

restorespfiletopfile'

/backup1/mydb.ora'

fromautobackup;

（从自动备份中恢复服务器参数文件）

13、从自动备份中恢复控制文件：

restorecontrolfileto'

/backup1'

（从自动备份中恢复控制文件）

14、恢复和复原全数据库：

shutdownimmediate；

（立即关闭数据库）

RMAN>

exit（退出）

%mv/oracle/dbs/tbs_12.f/oracle/dbs/tbs_12.bak（将数据文件重命名）

%mv/oracle/dbs/tbs_13.f/oracle/dbs/tbs_13.bak（将数据文件重命名）

%mv/oracle/dbs/tbs_14.f/oracle/dbs/tbs_14.bak（将数据文件重命名）

%mv/oracle/dbs/tbs_15.f/oracle/dbs/tbs_15.bak（将数据文件重命名）

%rmantarget=rman/rman@mydb（启动恢复管理器）

startuppfile=/oracle/admin/mydb/pfile/initmydb.ora

（指定初始化参数文件启动数据库）

restoredatabase；

（还原数据库）

recoverdatabase；

（恢复数据库）

alterdatabaseopen；

（打开数据库）

15、恢复和复原表空间：

sql'

altertablespaceusersofflineimmediate'

；

（将表空间脱机）

exit（退出恢复管理器）

%mv/oracle/dbs/users01.dbf/oracle/dbs/users01.bak（将表空间重命名）

restoretablespaceusers；

（还原表空间）

recovertablespaceusers；

（恢复表空间）

altertablespaceusersonline'

（将表空间联机）

16、增量备份与恢复：

第一天的增量基本备份：

backupincrementallevel=0databaseplusarchivelogdeleteinput；

第二天的增量差异备份：

backupincrementallevel=2databaseplusarchivelogdeleteinput；

第三天的增量差异备份：

第四天的增量差异备份：

backupincrementallevel=1databaseplusarchivelogdeleteinput；

第五天的增量差异备份：

第六天的增量差异备份：

第七天的增量差异备份：

增量恢复：

exit

%mv/oracle/dbs/tbs_12.f/oracle/dbs/tbs_12.bak

%mv/oracle/dbs/tbs_13.f/oracle/dbs/tbs_13.bak

%mv/oracle/dbs/tbs_14.f/oracle/dbs/tbs_14.bak

%mv/oracle/dbs/tbs_15.f/oracle/dbs/tbs_15.bak

%rmantarget=rman/rman@mydb

alterdatabaseopen.

采用OracleArchiveLog模式和非ArchiveLog模式对备份恢复的影响

备份的目的在于，当系统或数据库出现问题时，能够快速将数据库进行恢复。

对于Oracle数据库，一般有两种备份方式：

“物理备份”和“逻辑备份”。

“物理备份”指的是以copy数据文件方式进行备份；

“逻辑备份”指的是用export等方式将数据从数据库中抽取出来。

物理备份又可以分为冷备份和热备份。

以下是各种备份的说明及前提条件。

-ColdBackup（冷备份）主要指在关闭数据库的状态下进行的数据库完全备份，备份内容包括所有数据文件、控制文件、联机日志文件、ini文件。

-HotBackup（热备份）指在数据库处于运行状态下，对数据文件和控制文件进行备份，要使用热备份必须将数据库运行在（ArchiveLog）归档方式下。

-Export（逻辑备份）这是最简单的备份方法，可按数据库中某个表、某个用户或整个数据库来导出，并且支持全部、累计、增量三种方式。

使用这种方法，数据库必须处于打开状态，而且如果数据库不是在restrict状态将不能保证导出数据的一致性。

“物理备份”方式以相当于copy数据文件的方式进行备份，恢复时可以快速以相当于copy的方式将备份的数据copy回来，所以备份速度特别是恢复速度非常快。

如果不采用ArchiveLog模式运行Oracle数据库，只有两种可用的备份方法：

冷备份或export逻辑备份。

根据关键业务服务器的特点，停下数据库进行冷备份是根本不可能的，因此如果不采用ArchiveLog，只能进行逻辑备份。

如果仅采用“逻辑备份”方式，恢复时会有以下两个主要问题：

1.无法恢复到最近时间点的数据。

只能恢复到上一次export时的数据状态，当天的数据将丢失。

ArchiveLog模式下的物理备份可以用数据文件备份及ArchiveLog备份，将数据库恢复到数据库失败前的时间点，不会丢失数据。

2.完成恢复可能需要很长时间。

恢复只能用import方法进行，所以需要的时间包括：

a.createdatabase及所有的tablespace:

以每2分钟初始化一个2G的数据文件来计算，建立一个400G的Oracle数据库需要约6.7个小时。

b.import。

时间较难确定，但保守估计应在10个小时以上（如果import过程中出现问题，恢复时间将延长）

3.恢复时步骤较多，易出现人为故障。

由于这些原因，一般备份/恢复时都把export/import的方式做为辅助备份/恢复方式，对一些重要的表进行二级保护。

这种备份方式也称为“逻辑备份”方式，当某些重要的表被意外删除时可进行逻辑import恢复。

而对于整个数据库的日常备份/恢复，需要采用“物理备份”方式，即以相当于copy数据文件的方式进行备份，恢复时可以快速以相当于copy的方式将备份的数据copy回来。

一般物理备份/恢复都采用OracleRMAN工具来进行。

下面是“逻辑备份”与“物理备份”在数据库故障时的恢复比较：

1.Oracle逻辑错误造成无法启动

逻辑恢复:

重新createdatabase及各tablespace，import。

可恢复到上次export的数据

物理恢复:

将所有datafilecopy回来，并利用archivelog将数据库recover到故障前的状态

2.某一个datafile故障或丢失

将该datafilecopy回来

3.某一个tablespace故障

将该tablespacecopy回来

4.意外droptable

Import该table

将备份恢复到另一服务器上，export该table，在原数据库中

大数据量处理及存储代码优化过程

1.原始场景再现：

该模块主要是客户端负责上传一个包含手机号码的txt，其中一行一个手机号码。

服务端读取并解析该文件，解析过程中需要做有效性验证。

例如：

号码位数，是有效数字及是否在有效号段之内。

最后保存数据到DB。

该包含手机号码文件数据在20W到200W之间。

2.问题所在

在客户端上传20W数据的时候，后台相应很慢，查看后台的CPU及内存

mpstat-PALL1 

//查看LINUX系统内存及CPU的消耗情况

发现CPU一直处在100%状态下，而且消耗的时间很长。

近十分钟也没有回复到客户端。

3.问题详解

首先查看代码。

列下原代码思路:

1）使用apache的公用包来处理文件的上传，保存客户端文件到服务器

2）打开读取文件IO，及写日志IO，读取文件信息，到一个LIST中。

3）双重遍历LIST，进行查重操作。

重复数据记录到日志文件中

4）遍历LIST进行有效位数的校验。

5）遍历LIST进行是否为有效数字验证。

6）遍历该LIST，组装为数据库存储对象传递到DAO层，DAO层再次遍历对象容器，将插入对象添加到了批量提交的LIST中。

最后将20W的数据一次性批量提交

4.问题解决思路

第一次改动：

仔细查看代码我们可以很清晰的看出，问题主要在两块：

一是数据的有效性检查，原代码采用了多次循环遍历的方式处理，很耗CPU。

故首先将多次遍历的处理应该缩减为一次遍历即可，但是仔细想想其中存在一个查重的处理操作，故我们将原本用list存储的方式改为SET存储的方式，因为set不会存储重复的数据，这样可以达到查重的效果。

Key:

HashSet底层使用hash数组实现的，其原理就是当保存一个对象的时候，首先调用该对象的hashCode方法，获得hash码与原数组及数组子链表中的数据进行比较，若是相同的话则不进行插入操作，再不存在的情况下，才进行存储。

由于String类型已经实现了hashCode方法，所以我们不需要实现该方法若是其他类型的对象我们则需要实现该方法。

二就是数组存储的地方了，原代码采用了几十万条数据的一次批量提交，当然很消耗资源，代码回复给客户端慢。

这里我采用了ORACLE写一个存储过程，JAVA端传递一个数组给ORACLE，有存储过程来处理大数据量，这样就将服务器的压力转移到ORACLE安装的的那台服务器。

好的，第一次改动过完成。

重启TOMCAT试下。

结果当我们只上传20W数据的时候，发现还是很慢很慢，回头又仔细看代码，打断点。

再调试的过程中，发现在我只采用一个遍历循环的时候，CPU就一直处理100%，原来在处理这20W数据的时候，CPU就一直处理很高的状态了，那该怎么办呢？

这个时候就是第二次改动了

第二次改动：

个人经验，一般处理这种大数据量有两种方法，其实这两次方法的本质是一样的，就是为了降低CPU。

第一种是在我们在遍历循环的时候，在循环遍历到一定数量的时候，进行Thread.sleep（5）操作，带该线程睡眠片刻

Java代码 

For（intI=0;

I<

list.size（）;

i++） 

{ 

//…业务处理 

If（3000==i） 

Thread.sleep（5） 

} 

强制CPU暂时不处理该线程。

第二种方法就是采用流控的方式，流控的原理就是我们有一个初始量，循环过程中我们累加这个量，当达到一定量的时候，该线程进行wait（）操作，同时我们启动一个定时器，定时间周期对该变量进行清零操作，并唤醒该线程。

其中可能会出现两种情况，一是我们定时器的清零操作还没到，累积量就已经到了，那么该线程就会处在等待状态，等待清零时间到，唤醒线程。

二是累积量还没到，清零时间就到了，对线程进行清零，那么这个时候线程会一直处在一个运行状态，如果这个时候CPU使用率很高的话，就达不到我们需要的效果，所以该方式的控制就需要实际调整定时器的扫描周期、记累积量的值设定。

实际过程中需要调整两参数。

因为我们是将流控写成了一个工具类，所以不好贴出来，具体也就是上面所所得思路。

比较两种方法我们明显可以看出，采用流控的方式更佳，因为它是不阻塞线程，wait的方式。

第一次则是sleep，阻塞线程。

好，第二次改动已经完成了，我们就开工试试了。

当你怀着美好的愿望时，老天总是不能让你如意。

结果很失望，还是慢的一塌糊涂，然后不断的调整参数，结果还是没降下来。

这个时候我就开始反思了，难道这种方式有问题，再去打断点调试的过程发现，采用了流控后，在处理数据的时候是CPU确实是降下来了，但是还是存在一个问题，再没处理完一条记录后，都会有一个日志的记录，这个时候用的是bufferRead，结果我们在最后的close（）IO的时候，一次行将内存缓存中的数据库刷到文件，导致CPU及内存的过高。

知道原因后我开始了第三次的改动。

第三次改动：

这个时候，我采用了流控相同的思路，就是在处理完一定数据量的数据后，我们进行一次flush操作，将内存中数据刷到文件中，免得一次性刷，同时因为我们一般是整数的W级数据，所以定义一个常量为3000（全局多个地方需要刷数据，好改动），作为flush标示。

因为采用3000的话，最后一次我们刷的只有1000的数据量，同时关闭IO需要开销，所以能够在一定程度上降低CPU，同时发现在第一次flush的时候CPU会较高，越后CPU会越低，不知道什么原因。

Java代码

If（…） 

if（3000==i） 

read.flush（）l 

OK,又可以开工进行测试了，我是费了九牛二虎之力开动了TOMCAT（机子太差），哈哈，终于成功了。

CPU从原来的100%降到了10%左右，很有成就感，嘿嘿。

这样就将给测试区测试了。

但是，但是，测试告诉我一个很不幸的消息，CPU还是很高，这个是为什么呢？

仔细看看了，原来TMD应用的服务器跟DB在一台服务器上，气死老夫了。

采用一次性传递数据的片刻，ORACLE会使CPU会飙到100%，而且处理这么多数据的时候也会持续5s左右的时间一直处在该位。

这个时候咋办呢？

这个就需要第四次改动了。

第四次改动：

这个时候，首先改动的是存储过程，采用了动态变量绑定，同时调整commit;

的次数，在1000，3000，5000，10000条记录的时候提交数据，结果调试后，没什么改观，没则，只好换个思路。

启用存储过程，在java端想办法，最简单的方法还是启用原来的批量提交方式，修改为一定数量数据后提交，因为这个提交，并在提交后sleep，方式CPU一直处在这个状态。

伪代码就是

If（） 

//提交数据到DB 

//清零标示，清空临时list 

Thread.sleep（）;

就这么简单。

提交调试后，发现java端不会消耗很高的CPU，在第一次提交批量数据时会到30%左右，第二三次会降到15%左右，同时ORACLE消耗的CPU在第一次会100%，但是持续时间很短，就1s的时间，在达到这样的效果后，领导说可以了。

总算结束了这段优化过程。

简单的说，我这种方式不过是用时间换CPU的性能，只使用与对于时间要求不是很高，更要求CPU的性能的场景。

Oracle游标使用大全

我们将讨论各种用于访问ORACLE数据库的DDL和TCL语句。

查询

SELECT语句用于从数据库中查询数据，当在PL/SQL中使用SELECT语句时，要与INTO子句一起使用，查询的返回值被赋予INTO子句中的变量，变量的声明是在DELCARE中。

SELECT 

INTO语法如下：

SELECT[DISTICT|ALL]{*|column[,column,...]}

INTO（variable[,variable,...]|record）

FROM{table|（sub-query）}[alias]

WHERE............

PL/SQL中SELECT语句只返回一行数据。

如果超过一行数据，那么就要使用显式游标（对游标的讨论我们将在后面进行），INTO子句中要有与SELECT子句中相同列数量的变量。

INTO子句中也可以是记录变量。

%TYPE属性

在PL/SQL中可以将变量和常量声明为内建或用户定义的数据类型，以引用一个列名，同时继承他的数据类型和大小。

这种动态赋值方法是非常有用的，比如变量引用的列的数据类型和大小改变了，如果使用了%TYPE,那么用户就不必修改代码，否则就必须修改代码。

例：

v_empnoSCOTT.EMP.EMPNO%TYPE;

v_salaryEMP.SALARY%TYPE;

　不但列名可以使用%TYPE,而且变量、游标、记录，或声明的常量都可以使用%TYPE。

这对于定义相同数据类型的变量非常有用。

DELCARE

V_ANUMBER（5）:

=10;

V_BV_A%TYPE:

=15;

V_CV_A%TYPE;

BEGIN

DBMS_OUTPUT.PUT_LINE

（'

V_A='

||V_A||'

V_B='

||V_B||'

V_C='

||V_C）;

END

SQL>

/

V_A=10V_B=15V_C=

PL/SQLproceduresuccessfullycompleted.

SQL>

其他DML语句

其它操作数据的DML语句是:

INSERT、UPDATE、DELETE和LOCKTABLE,这些语句在PL/SQL中的语法与在SQL中的语法相同。

我们在前面已经讨论过DML语句的使用这里就不