精华内容
下载资源
问答
  • 利用批处理检查服务器宕机,批处理检查服务器端口 2010年07月06日  最近有一个小的要求需要用到批处理,我也不懂批处理,没办法只好现学现。  由于我们单位的服务器有时会由于...所以就想让我们弄个自动重启...
    利用批处理检查服务器宕机,批处理检查服务器端口 
    2010年07月06日
      最近有一个小的要求需要用到批处理,我也不懂批处理,没办法只好现学现用。
      由于我们单位的服务器有时会由于某种不明原因宕掉,目前宕了一次,虽然不是什么大问题,因为是集群宕掉一台不影响正常访问,但是上面对我们的考核就要大打拆扣了,因为管理服务器的人不想深夜或是某个时间点给你重启服务器,所以就想让我们弄个自动重启功能。如果宕了你重启就OK了,不用麻烦他们。弄就弄吧,只好试试看了。
      因为我们的web服务器是2003的,应用服务器是weblogic,weblogic有关掉服务和起动服务的批处理。所以我们只要调用一下他先关了,再启动就万事大吉了。没什么太大难事,毕竟不懂批处理脚本编程,自然就上网查资料罗。网上好像没有找到现成的,晕,有关教程也千编一律,大抄特抄的。首先要确定是检测服务器是否宕掉,原理自然就是telnet IP+端口了,那我就新建一个bat文件,注意文件名,我第一次用的是telnet.bat;NND一运行都是些什么乱七八糟的东西,我还以为是哪里弄错,最后改了一个名字竟然就OK了,狂晕!! 看看代码吧!很简单的哦echo off telnet 127.0.0.1 8080 if errorlevel 0 goto t1 goto end :t1 echo 打开端口成功 exit :end echo 打开端口失败 pause 简单吧,这个名我就叫ddd.bat;telnet 以后,判断回显码,是0说明成功。跳到t1处,如果失败就会继续往下执行goto end;
      这就是判断,重启服务的话就在end里加start stope服务批处理;再加start服务批处理就可以了.这里只是检查,我们另外还得写一个循环不断去调用这个bat文件就可以了,很隔一段时间就调用一下。 @echo off :start echo wscript.sleep wscript.arguments(0)*1000*60>delay.vbs delay.vbs 5 start ddd.bat goto start del delay.vbs echo ok!
    展开全文
  • 目前宕了一次,虽然不是什么大问题,因为是集群宕掉一台不影响正常访问,但是上面对我们的考核就要大打拆扣了,因为管理服务器的人不想深夜或是某个时间点给你重启服务器,所以就想让我们弄个自动重启功能。...

    最近有一个小的要求需要用到批处理,我也不懂批处理,没办法只好现学现用。

    由于我们单位的服务器有时会由于某种不明原因宕掉,目前宕了一次,虽然不是什么大问题,因为是集群宕掉一台不影响正常访问,但是上面对我们的考核就要大打拆扣了,因为管理服务器的人不想深夜或是某个时间点给你重启服务器,所以就想让我们弄个自动重启功能。如果宕了你重启就OK了,不用麻烦他们。弄就弄吧,只好试试看了。

    因为我们的web服务器是2003的,应用服务器是weblogic,weblogic有关掉服务和起动服务的批处理。所以我们只要调用一下他先关了,再启动就万事大吉了。没什么太大难事,毕竟不懂批处理脚本编程,自然就上网查资料罗。网上好像没有找到现成的,晕,有关教程也千编一律,大抄特抄的。首先要确定是检测服务器是否宕掉,原理自然就是telnet IP+端口了,那我就新建一个bat文件,注意文件名,我第一次用的是telnet.bat;NND一运行都是些什么乱七八糟的东西,我还以为是哪里弄错,最后改了一个名字竟然就OK了,狂晕!!

    看看代码吧!很简单的哦

    简单吧,这个名我就叫ddd.bat;telnet 以后,判断回显码,是0说明成功。跳到t1处,如果失败就会继续往下执行goto end;

    这就是判断,重启服务的话就在end里加start stope服务批处理;再加start服务批处理就可以了.这里只是检查,我们另外还得写一个循环不断去调用这个bat文件就可以了,很隔一段时间就调用一下。

    这是一个延时程序每隔5分钟去掉一下ddd.bat检查一下服务器是否挂掉。检查完又goto到start这是一个死循环。他会一直运行下去,这样我们就可以实现自动重启了。

     

    展开全文
  • 1.3.6 内置的健康检查功能/9 1.3.7 节省带宽/9 1.3.8 稳定性高/9 1.3.9 支持热部署/9 1.4 Nginx与Apache、Lighttpd的综合对比/9 第2章 Nginx服务器的安装与配置/11 2.1 安装Nginx服务器所需要的系统资源/11 2.2 ...
  • 实例恢复的深入解析

    千次阅读 2016-06-06 10:26:31
    当你数据库服务器异常断电,重启数据库就会发生实例恢复。实例恢复是由数据库自动完成的,无须DBA的干涉。当然这里有个前提条件:数据文件、在线日志文件、控制文件不得有损坏。  我们实验来分析一下实例恢复...

    什么时候会产生实例恢复呢?当你数据库服务器异常断电,重启数据库就会发生实例恢复。实例恢复是由数据库自动完成的,无须DBA的干涉。当然这里有个前提条件:数据文件、在线日志文件、控制文件不得有损坏。

         我们用实验来分析一下实例恢复的整个过程吧!

    1、在关闭数据库前,我们先看一下几个检查点的SCN

    SQL> select checkpoint_change# from v$database;

         CHECKPOINT_CHANGE#

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

               1455180

    --控制文件中保存的数据库检查点SCN号实际上在所有数据文件头部中最小的检查点SCN

    SQL> select file#,checkpoint_change# from v$datafile;

            FILE# CHECKPOINT_CHANGE#

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

             1            1455180

             2            1455180

             3            1455180

             4            1455180

             5            1455180

             6            1455180

    --控制文件中保存的数据文件检查点SCN:当一个检查点动作完成之后,Oracle就把每个数据文件的scn单独存放在控制文件中

    SQL> select file#,checkpoint_change# from v$datafile_header;

           FILE# CHECKPOINT_CHANGE#

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

             1            1455180

             2            1455180

             3            1455180

             4            1455180

             5            1455180

             6            1455180

    --每个数据文件的文件头中的检查点SCN

    这三个检查点的SCN一致,接下来模拟异常断电,重启机器

    2、此命令可以模拟异常断电

    SQL> shutdown abort;

    ORACLE instance shut down.

    3、监控告警日志

    [oracle@guoyj trace]$ tail -f alert_bxocp.log

    Starting background process VKRM

    Tue Dec 11 22:54:41 2012

    VKRM started with pid=24, OS id=12500

    Tue Dec 11 22:58:11 2012

    Shutting down instance (abort)

    License high water mark = 3

    USER (ospid: 12479): terminating the instance

    Instance terminated by USER, pid = 12479

    Tue Dec 11 22:58:12 2012

    Instance shutdown complete

    4、数据库启动到MOUNT

    SQL> shutdown abort;

    ORACLE instance shut down.

    SQL> startup mount;

    ORACLE instance started.

    Total System Global Area  839282688 bytes

    Fixed Size                  2233000 bytes

    Variable Size             524291416 bytes

    Database Buffers          310378496 bytes

    Redo Buffers                2379776 bytes

    Database mounted.

    5、再确定一下这个时间的检查点SCN

    SQL> select checkpoint_change# from v$database;

        CHECKPOINT_CHANGE#

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

             1455180

    SQL> SQL>  select file#,checkpoint_change# from v$datafile;

         FILE# CHECKPOINT_CHANGE#

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

             1            1455180

             2            1455180

             3            1455180

             4            1455180

             5            1455180

             6            1455180

    6 rows selected.

    SQL> select file#,checkpoint_change# from v$datafile_header;

         FILE# CHECKPOINT_CHANGE#

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

             1            1455180

             2            1455180

             3            1455180

             4            1455180

             5            1455180

             6            1455180

    发现与异常断电前的检查点的SCN一致,这里一致无须介质恢复。

    先不着急open数据库,我们做一些dump

    6dump的控制文件

    alter session set events 'immediate trace name CONTROLF level 12';

    取部分内容:

    ***************************************************************************

    DATABASE ENTRY

    ***************************************************************************

    (size = 316, compat size = 316, section max = 1, section in-use = 1,

      last-recid= 0, old-recno = 0, last-recno = 0)

    (extent = 1, blkno = 1, numrecs = 1)

    12/07/2012 10:36:14

    DB Name "BXOCP"

    Database flags = 0x00404000 0x00001000

    Controlfile Creation Timestamp  12/07/2012 10:36:15

    Incmplt recovery scn: 0x0000.00000000

    Resetlogs scn: 0x0000.000f30dc Resetlogs Timestamp  12/07/2012 10:36:16

    Prior resetlogs scn: 0x0000.00000001 Prior resetlogs Timestamp  09/17/2011 09:46:04

    Redo Version: compatible=0xb200000

    #Data files = 6, #Online files = 6

    Database checkpoint: Thread=1 scn: 0x0000.0016344c --数据库检查点SCN16344c转成10进制为1455180


      Threads: #Enabled=1, #Open=1, Head=1, Tail=1

    ***************************************************************************

    CHECKPOINT PROGRESS RECORDS

    ***************************************************************************

    (size = 8180, compat size = 8180, section max = 11, section in-use = 0,

      last-recid= 0, old-recno = 0, last-recno = 0)

    (extent = 1, blkno = 2, numrecs = 11)

    THREAD #1 - status:0x2 flags:0x0 dirty:55

    low cache rba:(0x13.3.0) on disk rba:(0x13.a6.0)

    -- low cache rba:(0x13.3.0)实例恢复的起点:19号日志,第3个块,第0个字节

    --on disk rba:(0x13.a6.0):实例恢复的终点:19号日志,第166个块,第0个字节


    on disk scn: 0x0000.0016359c 12/11/2012 22:57:42

    resetlogs scn: 0x0000.000f30dc 12/07/2012 10:36:16

    heartbeat: 801789080 mount id: 848836772

    THREAD #2 - status:0x0 flags:0x0 dirty:0

    low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)

    on disk scn: 0x0000.00000000 01/01/1988 00:00:00

    resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00

    heartbeat: 0 mount id: 0

    ***************************************************************************

    DATA FILE RECORDS

    ***************************************************************************

    (size = 520, compat size = 520, section max = 100, section in-use = 6,

      last-recid= 43, old-recno = 0, last-recno = 0)

    (extent = 1, blkno = 11, numrecs = 100)

    DATA FILE #1:

      name #7: /oradata/bxocp/system01.dbf

    creation size=0 block size=8192 status=0xe head=7 tail=7 dup=1

    tablespace 0, index=1 krfil=1 prev_file=0

    unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00

    Checkpoint cnt:121 scn: 0x0000.0016344c 12/11/2012 22:54:36

    --控制文件中保存的数据文件检查点SCN16344c转成10进制为1455180

    Stop scn: 0xffff.ffffffff 12/11/2012 22:53:05

    --结束的SCN填无穷大,说明是异常关机的,重启数据库必须做实例恢复


       Creation Checkpointed at scn:  0x0000.00000007 09/17/2011 09:46:08

    thread:0 rba:(0x0.0.0)

    7dump数据文件头

    alter session set events 'immediate trace name file_hdrs level 10';

    显示数据文件头的部分内容:

    V10 STYLE FILE HEADER:

            Compatibility Vsn = 186646528=0xb200000

            Db ID=848459038=0x3292751e, Db Name='BXOCP'

            Activation ID=0=0x0

            Control Seq=2099=0x833, File size=79360=0x13600

            File Number=2, Blksiz=8192, File Type=3 DATA

    Tablespace #1 - SYSAUX  rel_fn:2

    Creation   at   scn: 0x0000.0000088c 09/17/2011 09:46:16

    Backup taken at scn: 0x0000.00000000 01/01/1988 00:00:00 thread:0

    reset logs count:0x2fc45da0 scn: 0x0000.000f30dc

    prev reset logs count:0x2d6c775c scn: 0x0000.00000001

    recovered at 12/11/2012 22:54:36

    status:0x4 root dba:0x00000000 chkpt cnt: 121 ctl cnt:120

    begin-hot-backup file size: 0

    Checkpointed at scn:  0x0000.0016344c 12/11/2012 22:54:36

    --数据文件的文件头中的检查点SCN16344c转成10进制为1455180

    thread:1 rba:(0x13.2.10)

    --重做日志的地址0x13.2.10> 19号日志,第2号块,第16个字节开始恢复


    注意:

    从控制文件中得到重做日志恢复起始地址:

    low cache rba:(0x13.3.0)19号日志,第3个块,第0个字节开始恢复

    从数据文件头部得到重做日志恢复起始地址:

    thread:1 rba:(0x13.2.10) 9号日志,第2号块,第16个字节开始恢复

    8、最后我们打开数据库,然后监控告警日志alert_bxocp.log日志,看是怎么恢复的

    [oracle@guoyj trace]$ tail -f alert_bxocp.log

    alter database open

    Beginning crash recovery of 1 threads

    Started redo scan

    Completed redo scan

    read 81 KB redo, 55 data blocks need recovery

    Started redo application at

    Thread 1: logseq 19, block 3   --实例恢复开始的重做日志:19号日志第3个块


    Recovery of Online Redo Log: Thread 1 Group 1 Seq 19 Reading mem 0

      Mem# 0: /oradata/bxocp/redo01.log

    Completed redo application of 0.06MB

    Completed crash recovery at

    Thread 1: logseq 19, block 166, scn 1475516  --实例恢复结束点的重做日志:19号日志第166个块


      55 data blocks read, 55 data blocks written, 81 redo k-bytes read

    Tue Dec 11 23:46:42 2012

    Thread 1 advanced to log sequence 20 (thread open)

    Thread 1 opened at log sequence 20

      Current log# 2 seq# 20 mem# 0: /oradata/bxocp/redo02.log

    Successful open of redo thread 1

    MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set

    [12867] Successfully onlined Undo Tablespace 2.

    Undo initialization finished serial:0 start:20725234 end:20725294 diff:60 (0 seconds)

    Verifying file header compatibility for 11g tablespace encryption..

    Verifying 11g file header compatibility for tablespace encryption completed

    Tue Dec 11 23:46:42 2012

    SMON: enabling cache recovery

    SMON: enabling tx recovery

    Database Characterset is ZHS16GBK

    No Resource Manager plan active

    replication_dependency_tracking turned off (no async multimaster replication found)

    Starting background process QMNC

    Tue Dec 11 23:46:43 2012

    QMNC started with pid=21, OS id=13839

    Completed: alter database open

    Tue Dec 11 23:46:44 2012

    Starting background process CJQ0

    Tue Dec 11 23:46:44 2012

    CJQ0 started with pid=22, OS id=13851

    Setting Resource Manager plan SCHEDULER[0x318A]:DEFAULT_MAINTENANCE_PLAN via scheduler window

    Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter

    Tue Dec 11 23:46:47 2012

    Starting background process VKRM

    Tue Dec 11 23:46:47 2012

    VKRM started with pid=23, OS id=13857

    9、可以看出,实例恢复的起始的重做日志是以控制文件中的low cache rba:(0x13.3.0)19号日志,第3个块,第0个字节开始恢复,而不是从文件头的thread:1 rba:(0x13.2.10)

    --重做日志的地址0x13.2.10> 19号日志,第2号块,第16个字节开始恢复

    10、最后总结一下实例恢复

    (1)数据文件、在线日志文件、控制文件不得有损坏

    (2)数据库自动恢复,无需DBA干涉

    (3)恢复只需在线日志文件,无需归档日志

    (4)数据库在open的时候开始实例恢复

    实际上我做的这个实例恢实验的还没有写完整, 还有最后一步回滚!这个就留给你们思考!

    实例恢复三步:前滚--->打开库---->后滚(也叫回滚)


    其实:On Disk RBA不是Instance Recovery的终点!!

    展开全文
  • 当你数据库服务器异常断电,重启数据库就会发生实例恢复。实例恢复是由数据库自动完成的,无须DBA的干涉。当然这里有个前提条件:数据文件、 在线日志文件、控制文件不得有损坏。 我们实验来分析一下实例恢复的...

    什么时候会产生实例恢复呢?当你数据库服务器异常断电,重启数据库就会发生实例恢复。实例恢复是由数据库自动完成的,无须DBA的干涉。当然这里有个前提条件:数据文件、

    在线日志文件、控制文件不得有损坏。

         我们用实验来分析一下实例恢复的整个过程吧!

    1、在关闭数据库前,我们先看一下几个检查点的SCN
    --System checkpoint SCN  (存在于控制文件)

    SQL> select checkpoint_change# from v$database;

    CHECKPOINT_CHANGE#
    ------------------
         856021

    --控制文件中保存的数据库检查点SCN号实际上在所有数据文件头部中最小的检查点SCN


    SQL> select file#,checkpoint_change# from v$datafile;

         FILE# CHECKPOINT_CHANGE#
    ---------- ------------------
      1        856021
      2        856021
      3        856021
      4        856021
      5        856021


    --控制文件中保存的数据文件检查点SCN:当一个检查点动作完成之后,Oracle就把每个数据文件的scn单独存放在控制文件中

    SQL>  select file#,checkpoint_change# from v$datafile_header;

         FILE# CHECKPOINT_CHANGE#
    ---------- ------------------
      1        856021
      2        856021
      3        856021
      4        856021
      5        856021

    --每个数据文件的文件头中的检查点SCN

    select name,last_change# from v$datafile

    STOP SCN(存在于控制文件)
    最后一类SCN,End SCN他也是记录在控制文件当中,每一个所记录的数据文件头都有一个对应的End SCN,这个End SCN一定是存在于控制文件当中。这个SCN存在的绝对意义主要是用

    来去验证数据库启动过程中是否需要做instance recovery。我们可以通过

    那么其实在数据库正常运行的情况下,对于read/write的online 数据文件这个SCN号为#FFFFFF(NULL).


    2、此命令可以模拟异常断电

    SQL> shutdown abort;

    ORACLE instance shut down.


    这三个检查点的SCN一致,接下来模拟异常断电,重启机器

    3、监控告警日志
    Tue Oct 31 17:51:47 2000
    Shutting down instance (abort)
    License high water mark = 2
    Instance terminated by USER, pid = 2350


    4、数据库启动到MOUNT状

    SQL> select checkpoint_change# from v$database;

    CHECKPOINT_CHANGE#
    ------------------
         856021
    SQL> select file#,checkpoint_change# from v$datafile;

         FILE# CHECKPOINT_CHANGE#
    ---------- ------------------
      1        856021
      2        856021
      3        856021
      4        856021
      5        856021

    SQL>  select file#,checkpoint_change# from v$datafile_header;

         FILE# CHECKPOINT_CHANGE#
    ---------- ------------------
      1        856021
      2        856021
      3        856021
      4        856021
      5        856021

    SQL> col name format a30
    SQL> select name,last_change# from v$datafile;

    NAME      LAST_CHANGE#
    ---------------------------------------- ------------
    /oradata/june/june/system01.dbf
    /oradata/june/june/sysaux01.dbf
    /oradata/june/june/undotbs01.dbf
    /oradata/june/june/users01.dbf
    /oradata/june/june/example01.dbf


    发现与异常断电前的检查点的SCN一致,这里一致无须介质恢复。

    先不着急open数据库,我们做一些dump

    alter session set events 'immediate trace name CONTROLF level 12';


    ***************************************************************************
    ***************************************************************************
    DATABASE ENTRY
    ***************************************************************************
     (size = 316, compat size = 316, section max = 1, section in-use = 1,
      last-recid= 0, old-recno = 0, last-recno = 0)
     (extent = 1, blkno = 1, numrecs = 1)
     11/07/2000 12:05:40
     DB Name "JUNE"
     Database flags = 0x00404000 0x00001000
     Controlfile Creation Timestamp  11/07/2000 12:05:41
     Incmplt recovery scn: 0x0000.00000000
     Resetlogs scn: 0x0000.000b8338 Resetlogs Timestamp  11/07/2000 12:05:44
     Prior resetlogs scn: 0x0000.00000001 Prior resetlogs Timestamp  08/13/2009 23:00:48
     Redo Version: compatible=0xb200000
     #Data files = 5, #Online files = 5
     Database checkpoint: Thread=1 scn: 0x0000.000d0fd5   ----转换为10进制是856021
     Threads: #Enabled=1, #Open=1, Head=1, Tail=1
     enabled  threads:  01000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000
     Max log members = 3, Max data members = 1
     Arch list: Head=0, Tail=0, Force scn: 0x0000.000cc0ccscn: 0x0000.000b8338
     Activation ID: 307689684
     Controlfile Checkpointed at scn:  0x0000.000d34a8 11/07/2000 20:29:02
     thread:0 rba:(0x0.0.0)
     enabled  threads:  00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
      00000000 00000000 00000000 00000000 00000000 00000000
     
     234 DATA FILE RECORDS
    235 ***************************************************************************
    236  (size = 520, compat size = 520, section max = 100, section in-use = 5,
    237   last-recid= 64, old-recno = 0, last-recno = 0)
    238  (extent = 1, blkno = 11, numrecs = 100)
    239 DATA FILE #1:
    240   name #7: /oradata/june/june/system01.dbf
    241 creation size=0 block size=8192 status=0xe head=7 tail=7 dup=1
    242  tablespace 0, index=1 krfil=1 prev_file=0
    243  unrecoverable scn: 0x0000.00000000 01/01/1988 00:00:00
    244  Checkpoint cnt:91 scn: 0x0000.000d0fd5 11/07/2000 15:19:36
    245  Stop scn: 0xffff.ffffffff 11/07/2000 15:17:39
     
     

     Stop scn: 0xffff.ffffffff 11/07/2000 15:17:39

    --结束的SCN填无穷大,说明是异常关机的,重启数据库必须做实例恢复

    从dump 控制文件查看
    ***************************************************************************
    ***************************************************************************
    CHECKPOINT PROGRESS RECORDS
    ***************************************************************************
     (size = 8180, compat size = 8180, section max = 11, section in-use = 0,
      last-recid= 0, old-recno = 0, last-recno = 0)
     (extent = 1, blkno = 2, numrecs = 11)
    THREAD #1 - status:0x2 flags:0x0 dirty:37
    low cache rba:(0xa.12a30.0) on disk rba:(0xa.12ab4.0)
    on disk scn: 0x0000.000d3522 11/07/2000 20:31:01
    resetlogs scn: 0x0000.000b8338 11/07/2000 12:05:44
    heartbeat: 413022655 mount id: 307684709
    THREAD #2 - status:0x0 flags:0x0 dirty:0
    low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
    on disk scn: 0x0000.00000000 01/01/1988 00:00:00
    resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00
    heartbeat: 0 mount id: 0
    THREAD #3 - status:0x0 flags:0x0 dirty:0
    low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
    on disk scn: 0x0000.00000000 01/01/1988 00:00:00
    resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00
    heartbeat: 0 mount id: 0
    THREAD #4 - status:0x0 flags:0x0 dirty:0
    low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
    on disk scn: 0x0000.00000000 01/01/1988 00:00:00
    resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00
    heartbeat: 0 mount id: 0
    THREAD #5 - status:0x0 flags:0x0 dirty:0
    low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
    on disk scn: 0x0000.00000000 01/01/1988 00:00:00
    resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00
    heartbeat: 0 mount id: 0
    THREAD #6 - status:0x0 flags:0x0 dirty:0
    low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
    on disk scn: 0x0000.00000000 01/01/1988 00:00:00
    resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00
    heartbeat: 0 mount id: 0
    THREAD #7 - status:0x0 flags:0x0 dirty:0
    low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
    on disk scn: 0x0000.00000000 01/01/1988 00:00:00
    resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00
    heartbeat: 0 mount id: 0
    THREAD #8 - status:0x0 flags:0x0 dirty:0
    low cache rba:(0x0.0.0) on disk rba:(0x0.0.0)
    on disk scn: 0x0000.00000000 01/01/1988 00:00:00
    resetlogs scn: 0x0000.00000000 01/01/1988 00:00:00
    heartbeat: 0 mount id: 0


    low cache rba:(0xa.12a30.0) on disk rba:(0xa.12ab4.0)
    on disk scn: 0x0000.000d3522 11/07/2000 20:31:01

    -- low cache rba:(0xa.12a30.0)实例恢复的起点:10号日志,第76336个块,第0个字节

    --on disk rba:(0xa.12ab4.0):实例恢复的终点:10号日志,第76468个块,第0个字节

    -- Database checkpoint: Thread=1 scn: 0x0000.000d0fd5   ----转换为10进制是856021 scn恢复起点

    --on disk scn: 0x0000.000d3522 11/07/2000 20:31:01   ---865570 scn恢复终点

    low cache rba:就是CKPT记录的DBWR写出的进度

    on disk rba:就是LGWR的写进度

     

     

    Beginning crash recovery of 1 threads
    Started redo scan
    Completed redo scan
     read 66 KB redo, 37 data blocks need recovery
    Started redo application at
     Thread 1: logseq 10, block 76336
    Recovery of Online Redo Log: Thread 1 Group 1 Seq 10 Reading mem 0
      Mem# 0: /oradata/june/june/redo01.log
    Completed redo application of 0.06MB
    Completed crash recovery at
     Thread 1: logseq 10, block 76468, scn 885570
     37 data blocks read, 37 data blocks written, 66 redo k-bytes read

    实例恢复的起点和终点;

    checkpoint position 到 end of redo log
    10、最后总结一下实例恢复

    (1)数据文件、在线日志文件、控制文件不得有损坏

    (2)数据库自动恢复,无需DBA干涉

    (3)恢复只需在线日志文件,无需归档日志

    (4)数据库在open的时候开始实例恢复

    实际上我做的这个实例恢实验的还没有写完整, 还有最后一步回滚!这个就留给你们思考!

    实例恢复三步:前滚--->打开库---->后滚(也叫回滚)
     

     

    转载于:https://www.cnblogs.com/zhaoyangjian724/p/3797982.html

    展开全文
  • (有些连接自动连接电信服务器,来操控你的H806B的) 9、管理==〉远程管理方式,将“TR069远程管理”改称“中间件管理” (TR069,其全称为“CPE广域网管理协议”。它规定了家庭网关进行远程管理配置时的通用框架...
  • 中兴H608B 破解软件包

    千次下载 热门讨论 2011-04-22 08:10:08
    (有些连接自动连接电信服务器,来操控你的H806B的) 8、管理==〉远程管理方式,将“TR069远程管理”改称“中间件管理” (TR069,其全称为“CPE广域网管理协议”。它规定了家庭网关进行远程管理配置时的通用框架...
  • 说到为什么要升级是因为,从另一台机器上备份了一个数据库,到我的机器上还原的时候提示“System.Data.SqlClient.Sqlerror:该数据库是在运行版本10.50.2500的服务器上备份的,该版本与此服务器(运行版本10.00.1600...
  • 6.1.1 分配区尺寸:自动分配与统一尺寸 169 6.1.2 自动与手动段空间管理 170 6.2 创建表空间 172 6.2.1 数据文件和表空间 172 6.2.2 区分配和解除分配 173 6.2.3 存储参数 174 6.2.4 数据库对象的存储...
  • 1699 网吧维护\资料\xp实用技巧\设置自动关机重启时间.txt 5039 网吧维护\资料\xp实用技巧\辅助操作和特殊功能命令.txt 848 网吧维护\资料\xp实用技巧\运行菜单中的“快捷方式”.txt 5306 网吧维护\资料\xp实用技巧\...
  • 事务处理原理 第2版

    热门讨论 2012-12-30 10:49:38
    6.1.4 自动锁定 6.2 实现 6.2.1 锁管理器 6.2.2 锁的设置和释放 6.2.3 粒度 6.2.4 多粒度锁定 6.3 死锁 6.3.1 死锁预防 6.3.2 死锁检测 6.3.3 选择牺牲品 6.3.4 分布式死锁检测 6.4 性能 6.4.1 锁转换 6.4.2 锁抖动 ...
  • Java目录监视器源程序 9个目标文件 内容索引:JAVA源码,综合应用,目录监视 JAVA开发的一个小型的目录监视系统,系统会每5秒自动扫描一次需要监视的目录,可以用来监视目录中文件大小及文件增减数目的变化。...
  • JAVA上百实例源码以及开源项目

    千次下载 热门讨论 2016-01-03 17:37:40
     JAVA开发的一个小型的目录监视系统,系统会每5秒自动扫描一次需要监视的目录,可以用来监视目录中文件大小及文件增减数目的变化。 Java日期选择控件完整源代码 14个目标文件 内容索引:JAVA源码,系统相关,日历,...
  • 多媒体教室

    2013-06-14 08:10:31
    注: TCP/IP 设置完成后请 PING 命令验证网络是否连通,如网络不通请尝试检查相应网络设备、重新安装 TCP/IP 协议等手段来解决问题。  2.3产品安装  教师机的安装 1. 插入安装光盘后会自动运行安装程序,进入...
  • 2.3.3. 用自动安装器安装MySQL 2.3.4. 使用MySQL安装向导 2.3.5. 使用配置向导 2.3.6. 通过非安装Zip文件安装MySQL 2.3.7. 提取安装档案文件 2.3.8. 创建选项文件 2.3.9. 选择MySQL服务器类型 2.3.10. 首次启动...
  • MYSQL中文手册

    2013-03-11 21:21:34
    5.2.1. MySQL实例管理器启动MySQL服务器 5.2.2. 连接到MySQL实例管理器并创建用户账户 5.2.3. MySQL实例管理器命令行选项 5.2.4. MySQL实例管理器配置文件 5.2.5. MySQL实例管理器识别的命令 5.3. mysqld:...
  • java开源包1

    千次下载 热门讨论 2013-06-28 09:14:34
    往好了用什么都能干,就是不能让一个网站下线。 FTP客户端Java类库 ftp4j ftp4j是一个FTP客户端Java类库,实现了FTP客户端应具有的大部分功能文件(包括上传和下 载),浏览远程FTP服务器上的目录和文件,创建、...
  • java开源包12

    热门讨论 2013-06-28 10:14:45
    往好了用什么都能干,就是不能让一个网站下线。 FTP客户端Java类库 ftp4j ftp4j是一个FTP客户端Java类库,实现了FTP客户端应具有的大部分功能文件(包括上传和下 载),浏览远程FTP服务器上的目录和文件,创建、...
  • Java资源包01

    2016-08-31 09:16:25
    往好了用什么都能干,就是不能让一个网站下线。 FTP客户端Java类库 ftp4j ftp4j是一个FTP客户端Java类库,实现了FTP客户端应具有的大部分功能文件(包括上传和下 载),浏览远程FTP服务器上的目录和文件,创建、...
  • java开源包101

    2016-07-13 10:11:08
    往好了用什么都能干,就是不能让一个网站下线。 FTP客户端Java类库 ftp4j ftp4j是一个FTP客户端Java类库,实现了FTP客户端应具有的大部分功能文件(包括上传和下 载),浏览远程FTP服务器上的目录和文件,创建、...
  • java开源包11

    热门讨论 2013-06-28 10:10:38
    往好了用什么都能干,就是不能让一个网站下线。 FTP客户端Java类库 ftp4j ftp4j是一个FTP客户端Java类库,实现了FTP客户端应具有的大部分功能文件(包括上传和下 载),浏览远程FTP服务器上的目录和文件,创建、...
  • java开源包6

    热门讨论 2013-06-28 09:48:32
    往好了用什么都能干,就是不能让一个网站下线。 FTP客户端Java类库 ftp4j ftp4j是一个FTP客户端Java类库,实现了FTP客户端应具有的大部分功能文件(包括上传和下 载),浏览远程FTP服务器上的目录和文件,创建、...
  • java开源包10

    热门讨论 2013-06-28 10:06:40
    往好了用什么都能干,就是不能让一个网站下线。 FTP客户端Java类库 ftp4j ftp4j是一个FTP客户端Java类库,实现了FTP客户端应具有的大部分功能文件(包括上传和下 载),浏览远程FTP服务器上的目录和文件,创建、...

空空如也

空空如也

1 2 3
收藏数 58
精华内容 23
关键字:

服务器自动重启用什么检查