2022年9月

1:vi /etc/oratab

colystdb:/opt/app/oracle/product/19.3.0:Y

2:vim /usr/bin/oracle.sh

#! /bin/bash 
#  script  For oracle19c.service
/opt/app/oracle/product/19.3.0/dbhome_1/bin/lsnrctl start
/opt/app/oracle/product/19.3.0/dbhome_1/bin/dbstart /opt/app/oracle/product/19.3.0/dbhome_1

3:chmod 777 /usr/bin/oracle.sh
4:vi /etc/systemd/system/oracle19c.service

[Unit]
Description=Oracle19c
After=syslog.target network.target
[Service]
LimitMEMLOCK=infinity
LimitNOFILE=65535
Type=oneshot
RemainAfterExit=yes
User=oracle
Environment="ORACLE_HOME=/opt/app/oracle/product/19.3.0/dbhome_1"
ExecStart=/usr/bin/oracle.sh
[Install]
WantedBy=multi-user.target

5:systemctl enable oracle19c
6:systemctl is-enabled oracle19c.service #查看服务是否是开机自启动
————————————————
版权声明:本文为CSDN博主「BK_小小关」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/m0_54434140/article/details/123400477

1.查询系统当前SCN两条命令
SQL> select current_scn from v$database;
SQL> select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER

------------------------

1781893

另一个查SCN的方法,稍有延迟是因为执行命令的间隔,其实也是实时的了

SCNSYS@ bys3>oradebug dumpvar sga kcsgacn_

ORA-00079: variable kcsgacn_ not found
SYS@ bys3>oradebug dumpvar sga kcsgscn_
kcslf kcsgscn_ [2000EFC0, 2000EFE0) = 00000000 001976D2 000001E9 00000000 00000000 00000000 00000000 2000EDCC
SYS@ bys3>select to_number('1976D2','xxxxxxxxxxxx') a from dual;
A

----------

1668818
SYS@ bys3>select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER

------------------------

1668853
再一个通过内部表查询SCN的:

SYS@ bys3>select max(ktuxescnw*power(2,32)+ktuxescnb) from x$ktuxe;
MAX(KTUXESCNW*POWER(2,32)+KTUXESCNB)

------------------------------------

1669208
SYS@ bys3>select dbms_flashback.get_system_change_number from dual;
GET_SYSTEM_CHANGE_NUMBER

------------------------

1669219

2.数据库全局-检查点 SCN,在控制文件中。
SYS@bys1> select dbid,checkpoint_change# from v$database;
DBID CHECKPOINT_CHANGE#

--------- ------------------

3957527513 1753478

3.当前数据文件检查点SCN。在控制文件中、数据文件头中。即checkpoint scn,表示该数据文件最近一次执行检查点操作时的SCN
SQL> select name,checkpoint_change# from v$datafile;
NAME CHECKPOINT_CHANGE#

-------------------------------------------------- ------------------

/u01/oradata/bys1/system01.dbf 1753478
/u01/oradata/bys1/sysaux01.dbf 1753478
SQL> select file#,name,checkpoint_change#,to_char(checkpoint_time,'yyyy-mm-dd hh24:mi:ss') cptime from v$datafile;

FILE# NAME CHECKPOINT_CHANGE# CPTIME


     1 /u01/oradata/bys1/system01.dbf                                1753478 2013-09-11 23:00:52
     2 /u01/oradata/bys1/sysaux01.dbf                                1753478 2013-09-11 23:00:52

4.查询数据文件头SCN,在控制文件中、数据文件头
SQL> select name,checkpoint_change# from v$datafile_header;
NAME CHECKPOINT_CHANGE#


/u01/app/oracle/oradata/bys001/system01.dbf 1198546

5.数据文件结束SCN,在数据文件头,控制文件中。
LAST_CHANGE#,如果数据库非正常关闭值为NULL。正常关闭是关闭时的SCN。
实例恢复就是在打开数据库时检查此参数确定是否需要恢复。
数据库OPEN时LAST_CHANGE#也为NULL,因为不确定SCN多少时关闭。
SQL> select name,last_change# from v$datafile;
NAME LAST_CHANGE#


/u01/app/oracle/oradata/bys001/system01.dbf

6.日志中所含SCN范围
BYS@ bys3>select GROUP#,sequence#,STATUS,FIRST_CHANGE#,to_char(FIRST_TIME,'yyyy/mm/dd:hh24:mi:ss') firsttime,NEXT_CHANGE#,to_char(NEXT_TIME,'yyyy/mm/dd:hh24:mi:ss') nexttime from V$log;

GROUP# SEQUENCE# STATUS FIRST_CHANGE# FIRSTTIME NEXT_CHANGE# NEXTTIME


     1        145 CURRENT                2910938 2013/12/15:10:06:41    2.8147E+14                                               ------当前REDO日志,所以下一次切换的SCN是无穷大,切换时间为空。
     2        143 INACTIVE               2865685 2013/12/14:20:36:08      2883589 2013/12/15:02:00:55
     3        144 INACTIVE               2883589 2013/12/15:02:00:55      2910938 2013/12/15:10:06:41

————————————————
版权声明:本文为CSDN博主「还不算晕」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/haibusuanyun/article/details/11590735

RMAN-20208: UNTIL CHANGE is before RESETLOGS change 问题小计
转载:https://blog.csdn.net/cqrw65623/article/details/100266149
cqrw65623

于 2013-07-30 13:25:39 发布

342
收藏
文章标签: 数据库

RMAN-20208: UNTIL CHANGE is before RESETLOGS change 问题小计

RMAN> restore database until scn 1045382;

Starting restore at 2013-07-27 04:15:37
using channel ORA_DISK_1
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 07/27/2013 04:15:38
RMAN-20208: UNTIL CHANGE is before RESETLOGS change

RMAN> list incarnation;

List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time


1 1 RACDB 819075368 PARENT 1037818 2013-07-26 23:36:49
2 2 RACDB 819075368 PARENT 1041997 2013-07-27 00:39:28
3 3 RACDB 819075368 CURRENT 1045383 2013-07-27 01:30:52

根据我们想恢复到SCN,明确我们应该使用incarnation 2
RMAN> reset database to incarnation 2;
RMAN> restore database until scn 1045382;
RMAN> recover database until scn 1045382;
SQL> alter database open resetlogs;

到此问题解决!!

问题解决方法来源
官档:http://docs.oracle.com/cd/B19306_01/backup.102/b14194/rcmsynta050.htm

Examples

Resetting RMAN to a Previous Incarnation in NOCATALOG Mode: Example In NOCATALOG mode, you must mount a control file that knows about the incarnation that you want to recover. The following scenario makes an old incarnation of database trgt current again:

CONNECT TARGET / NOCATALOG

step 1: start and mount a control file that knows about the incarnation to which

you want to return. if the current control file does not know about it, then

you must restore an older control file

STARTUP NOMOUNT;
RESTORE CONTROLFILE UNTIL TIME 'SYSDATE-250';
ALTER DATABASE MOUNT;

step 2: obtain the primary key of old incarnation

LIST INCARNATION OF DATABASE trgt;

List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time


1 2 TRGT 1334358386 PARENT 154381 OCT 30 2001 16:02:12
1 116 TRGT 1334358386 CURRENT 154877 OCT 30 2001 16:37:39

step 3: in this example, reset database to incarnation key 2

RESET DATABASE TO INCARNATION 2;

step 4: restore and recover the database to a point before the RESETLOGS

RESTORE DATABASE UNTIL SCN 154876;
RECOVER DATABASE UNTIL SCN 154876;

step 5: make this incarnation the current incarnation and then list incarnations:

ALTER DATABASE OPEN RESETLOGS;
LIST INCARNATION OF DATABASE trgt;

List of Database Incarnations
DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time


1 2 TRGT 1334358386 PARENT 154381 OCT 30 2001 16:02:12
1 116 TRGT 1334358386 PARENT 154877 OCT 30 2001 16:37:39
1 311 TRGT 1334358386 CURRENT 154877 AUG 13 2002 17:17:03

Resetting the Database After Incomplete Recovery: Example

This example assumes that an incomplete recovery or recovery with a backup control file was performed in NOCATALOG mode. Later, RMAN is started in CATALOG mode, but the RESYNC command fails because the incarnation has not been reset in the catalog.

% rman target / catalog rman/rman@catdb

Recovery Manager: Release 10.1.0.2.0 - Production

Copyright (c) 1995, 2003, Oracle. All rights reserved.

connected to target database: TRGT (DBID=1334531173)
connected to recovery catalog database

RMAN> RESYNC CATALOG;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of resync command on default channel at 11/01/2001 12:00:43
RMAN-20003: target database incarnation not found in recovery catalog

RMAN> RESET DATABASE;

new incarnation of database registered in recovery catalog
starting full resync of recovery catalog
full resync complete

总结:官档介绍的一些解决问题的思路,更应该让我们详细的研究!