精华内容
下载资源
问答
  • 访问WINCC归档数据库

    万次阅读 2013-03-22 12:06:24
    一般 需要wincc Connectivity Pack 才能访问归档数据库 ---------------     使用VB或VBS访问WINCC6.0历史数据库 从WINCC6.0开始,就开始采用SQL3000SP3做为WINCC的后台数据了.而这个SQL2000SP3是由SIEMENS为WINCC...

     

    一般 需要wincc Connectivity Pack 才能访问归档数据库

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

     

     

    使用VB或VBS访问WINCC6.0历史数据库

    从WINCC6.0开始,就开始采用SQL3000SP3做为WINCC的后台数据了.而这个SQL2000SP3是由SIEMENS为WINCC做了二次开发的,采用了一些独有的技术,一些是我们知道的,一些是我们所不知道的.所以当我们打开SQL管理器和用高级语言访问时,和常规的SQL访问的方法是有一些出入的.即使我们能够很轻易的访问ACCESS,普通的SQL2000的数据库,不见的你就能顺利的访问到WINCC的历史数据.

      官方的资料显示:
      1:WINCC的数据有设计时数据库和运行时数据库,分别放在相关的目录,对于数据使用者而言,我们知道就可以了.设计时数据库我们了解没有什么意义.但运行时数据库至少我们要知道它的名.他的名一般是"CC_工程名_年_月_日_时_分_秒R"的名,这个对于我们使用者而言,是很重要的的,无论你准备以DSN或OLEDB的方式访问数据库,你都需要它.如果你实在不知道它的名,你可以将WINCC激活,然后在'ODBC管理器"或"SQL企业管理器下的"DATABASE"可以看到它,它就蹲在那里.....
      2:运行时库的表的问题.
    其实,这个是很多的用户很关心的问题,包括我自己在内.常规的使用过高级语言访问SQL的技术人员都知道,很多的SQL语句,如SELECT ,INSERT INTO等等,都需要指明在某一库的表中对它进行操作.因此,这个表的问题可能就是你访问SQL的拦路虎.
      先告诉大家:WINCC6.0的SQL库操作是不需要表名的,因为他有自己定义的SQL语句.细节一会儿在描述.
    其实,WINCC在运行时,根据WINCC的设置,数据归档是以一定时间做为基准,形成数据片段.
    大体上有三个用户需要了解的表.
    在数据片段下,有三个表是我们所关心的
    1:ARCHIVE(用户归档记录)
    2:TAGPRESSED(TAGUNPRESSED)(压缩/非压缩变量归档记录)
    3:MSARCLONG(报警记录)
    事实上,我们在操作数据时,还是并不能直接使用常规的SQL来操作这些表,甚至不允许修改它,MSARCLONG情况好一些,允许插入/修改等.


    TAGPRESSED的数据和WINCC内设置的变量管理下的归档是对应的,
    MSARCLONG的数据和WINCC内设置的报警记录下的设置是对应的.
    ARCHIVE的数据和WINCC内的用户归档数据是对应的.

    一般的,当我们使用WINCC制作在线表格和在线趋势使用的都是变量管理器下的归档.
    因此,我们打开TAGPRESSED的表,可以看到的一些都是变量记录的内容,通常也是在这里归档了用户的生产数据.因此,我们访问WINCC历史数据库,实际上是访问这里的变量记录

    3:访问历史数据库的方法/连接字符/SQL语句
      访问数据库的方法:
    A:WINCCOLEDB访问压缩归档,也可以访问非压缩归档
    B:MS ADO/OLEDB只能访问非压缩归档
    对于这种说法,我只严正了WINCCOLEDB的方法,后者没有测试.

      连接字符:
    WINCCOLEDB的连接字符为(本地):
    provider=winccoledbprovider.1,catalog=./wincc,data source=
    数据库名,user id=DBA,password=SQL
    对于远程连接,因为没有条件测试,所以就不说了,希望有哪位朋友日后通过了测试,到这里告诉一下
    现在开始讲访问用户归档,过程值归档和消息归档的方法和语法:
    1:查询过程值归档和消息归档的连接字符串
    SET CON=Createobject("adodb.connection")
    con.open
    Provider=winccoledbprovider.1;catalog=cc_工程名_年_月_日_时_分_秒R,data source=./wincc,user id=DBA,password=SQL
    说明:按照WINCC规定的连接字符串,创建到数据库的连接,并且打开这个连接.其中,我们经常需要修改的是Catalog的值,这个值根据不同的工程和创建的时间不同,我们可以在ODBC管理器下或SQL的库中看到.

    查询过程值归档和用户归档的SQL语句
    TAG:R,'变量名1','起始时间','终止时间' where条件
    说明:WHERE子句只对用户归档有效,对过程值归档无效.
    变量名:这个变量名要和WINCC下的变量管理器的过程值归档名要一致.其格式为:归档名/变量名.
    起始时间和终止时间可以用相对时间和绝对时间,一般绝对时间比较容易理解,就是从开始时间到终止时间就好了.例如,查询从2006/3/12 12:20:20秒到2006/3/13/ 12:20:20秒的数据,则应该写成'2006-3-12 12:20:20' '2006-3-13 12:20:20'就好了.
    当然拉,也可以用相对时间格式,就是比目前时间的相对值,有个前移后移的问题,很简单的.

    这里特别需要注意的是:记录到SQL数据库的时间都是格林威治时间,和中国的东8区有8个小时的时间差,也就是说记录的时间比本机PC时区晚8小时,这一点我们在测试是尤其重要.
    因为你是时间不正确,可能数据就没有显示,而导致你怀疑连接/命令/记录的有效性
    访问SQL数据库的方法过程描述.
    这和访问普通的数据库的方法大致上是相同,唯一的就是由于WINCC的数据是经过了压缩的.
    1:定义连接字符串,就是前面所讲到的.
    2:创建ADODB的CONNECTION对象,在VB中直接用CREATEOBJECT(ADODB.CONNECTION)函数,在ASP的VB脚本中,需要使用内置SERVER对象创建CONNECTIONG对象.
    3:打开到数据库的连接,使用CONNECTION的OPEN函数
    4:创建COMMAND对象,并定义COMMAND对象采用用CMDTEXT方法,表明将要使用命令文本的方式来获取数据记录.
    5:创建RECORDSET对象,并用COMMAND对象的返回记录集填充这个记录集.

    6:RECORDSET对象的数据就可以被你任意的使用了

    展开全文
  • 数据库在运行的过处程中,必须要做好备份,如果... 对于归档数据库,有很多的种的备份方法,但对于非归档的数据库来说,只能作关闭数据库的冷备。 对于Windows系统,数据库运行时是不能复制文件的,所以:SQL> shutdo

    数据库在运行的过处程中,必须要做好备份,如果没有做好备份,那么,如果数据库出现故障,就只有等死一条路了。因为将会丢失部分或全部数据,另外对OLTP系统来说,数据是实时在变化,丢数据的可能性就越高。

          对于归档数据库,有很多的种的备份方法,但对于非归档的数据库来说,只能作关闭数据库的冷备。 

        对于Windows系统,数据库运行时是不能复制文件的,所以:

    SQL> shutdown immediate
    数据库已经关闭。
    已经卸载数据库。
    ORACLE 例程已经关闭。

    数据库关闭后,开始复制文件。复制完成后,再启动数据库:


    SQL> startup
    ORACLE 例程已经启动。

    Total System Global Area   85006980 bytes
    Fixed Size                   453252 bytes
    Variable Size              58720256 bytes
    Database Buffers           25165824 bytes
    Redo Buffers                 667648 bytes
    数据库装载完毕。
    数据库已经打开。

    对于非归档的数据库备份,需要备份的文件如下:

    (1)控制文件:这是必须要备份的。如果这个文件损坏了,数据库就再也启不来了。

    SQL> select name from v$controlfile;

    NAME
    --------------------------------------------------------------
    D:/ORACLE/ORADATA/ORA92/CONTROL01.CTL
    D:/ORACLE/ORADATA/ORA92/CONTROL02.CTL
    D:/ORACLE/ORADATA/ORA92/CONTROL03.CTL

    (2)数据文件:保存用户数据文件,必须备份:

    SQL> select name from v$datafile;

    NAME
    ----------------------------------------------------
    D:/ORACLE/ORADATA/ORA92/SYSTEM01.DBF
    D:/ORACLE/ORADATA/ORA92/UNDOTBS01.DBF
    D:/ORACLE/ORADATA/ORA92/INDX01.DBF
    D:/ORACLE/ORADATA/ORA92/TOOLS01.DBF
    D:/ORACLE/ORADATA/ORA92/USERS01.DBF
    D:/ORACLE/ORADATA/ORA92/SP01.DBF

    (3)日志文件,非归档要求必须备:

    SQL> select member from v$logfile;

    MEMBER
    ------------------------------------------------
    D:/ORACLE/ORADATA/ORA92/REDO01.LOG
    D:/ORACLE/ORADATA/ORA92/REDO02.LOG
    D:/ORACLE/ORADATA/ORA92/REDO03.LOG

    另外,参数文件可以不备份,但是一般的,该文件存放我们已经配好的参数,最好也备,

    D:/oracle/ora92/database/SPFILEORA92.ORA

    口令文件可以不备,如果丢失,可以直接用Oracle提供的工具创建:

    Orapwd.exe 来创建口令文件。

     

    如果数据库需要恢复,直接将上面的文件复制到指定文件,再重启数据库即可。

    展开全文
  • _disable_logging对于归档数据库的影响

    千次阅读 2006-04-18 15:23:00
    _disable_logging对于归档数据库的影响在归档数据库下,如果设置了 _disable_logging=true,那么数据库就会将所有的online redo logfile标记为corrput,从而在归档数据库下不能够正常的归档了,因此,每次需要当...

    _disable_logging对于归档数据库的影响

    在归档数据库下,如果设置了 _disable_loggingtrue,那么数据库就会将所有的online redo logfile标记为corrput,从而在归档数据库下不能够正常的归档了,因此,每次需要当数据库中所有的日志组归档状态都为“NO”,且STATUS列的值出现n-1个“INACTIVE”和一个“CURRENT”时,即,除了当前日志外,其余所有的日志都是不活动且没有归档的时候,对数据库的所有操作(只要产生的日志超过current日志的可用大小的时候,也就是需要发生日志切换的时候)就会hang

    上述结论可以很容易的得到证实,首先我们检查数据库的状态,看它是否已经处在归档模式了,如果仍然处于非归档模式的话,请先将数据库改为归档方式(具体的方法不是这里讨论的重点,就不赘述了):

     

    sys@TSMISC02> archive log list

    Database log mode              Archive Mode

    Automatic archival             Enabled

    Archive destination            /oracle/oradata/TSMISC02/archive

    Oldest online log sequence     1595

    Next log sequence to archive   1597

    Current log sequence           1597

    sys@TSMISC02>  

     

    再检查一下当前的日志文件信息:

    sys@TSMISC02> select * from v$log;

        GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM

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

             1          1       1597    2097152          1 NO  CURRENT                6913201 11-APR-06

             2          1       1595    2097152          1 YES INACTIVE               6889512 11-APR-06

             3          1       1596    2097152          1 YES INACTIVE               6901361 11-APR-06

    Elapsed: 00:00:00.01

    sys@TSMISC02>

    sys@TSMISC02> col member for a50            

    sys@TSMISC02> select * from v$logfile;      

        GROUP# STATUS  TYPE    MEMBER

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

             1         ONLINE  /oracle/oradata/TSMISC02/redo01.log

             2         ONLINE  /oracle/oradata/TSMISC02/redo02.log

             3         ONLINE  /oracle/oradata/TSMISC02/redo03.log

     

    Elapsed: 00:00:00.00

    sys@TSMISC02>

        我们看到当前的日志文件是日志组1online redo log group 1),日志组2和日志组3都已经成功归档,并且状态是“INACTIVE”,也就是说,这两个组已经可以被循环使用了

    现在设置"_disable_logging"=true

    sys@TSMISC02> alter system set "_disable_logging"=true scope=both;

    System altered.

    Elapsed: 00:00:00.00

    sys@TSMISC02>

       

    然后,再创建一些大表等等,然后观察日志的情况:

    sys@TSMISC02> select * from v$log;

        GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM

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

             1          1       1597    2097152          1 NO  ACTIVE                 6913201 11-APR-06

             2          1       1598    2097152          1 NO  CURRENT                6919313 11-APR-06

             3          1       1596    2097152          1 YES INACTIVE               6901361 11-APR-06

    Elapsed: 00:00:00.00

    sys@TSMISC02> select * from v$logfile;

        GROUP# STATUS  TYPE    MEMBER

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

             1         ONLINE  /oracle/oradata/TSMISC02/redo01.log

             2         ONLINE  /oracle/oradata/TSMISC02/redo02.log

             3         ONLINE  /oracle/oradata/TSMISC02/redo03.log

    Elapsed: 00:00:00.00

    sys@TSMISC02>

        我们观察到,系统已经发生了日志切换,当前系统正在使用的日志组已经是group 2了,而刚才的那个group 1是没有完成归档的状态,即,没有归档且状态为active

        这时候,实际上数据库已经出现问题了,但是由于还有其他可用的日志组可以继续使用,因此在前台sqlplus的使用界面上并没有报错,但是如果你检查alert.log,就会发现系统已经开始不断的报类似下面的错误信息了:

    Tue Apr 11 13:50:07 2006

    ALTER SYSTEM SET _disable_logging=TRUE SCOPE=BOTH;

    Tue Apr 11 14:09:35 2006

    ARC0: Evaluating archive   log 1 thread 1 sequence 1597

    ARC0: Beginning to archive log 1 thread 1 sequence 1597

    Creating archive destination LOG_ARCHIVE_DEST_1: '/oracle/oradata/TSMISC02/archive/1_1597.dbf'

    Tue Apr 11 14:09:35 2006

    Thread 1 advanced to log sequence 1598

      Current log# 2 seq# 1598 mem# 0: /oracle/oradata/TSMISC02/redo02.log

    Tue Apr 11 14:09:35 2006

    ARC0: Log corruption near block 3740 change 0 time ?

    ARC0: All Archive destinations made inactive due to error 354

    Tue Apr 11 14:09:35 2006

    Errors in file /oracle/admin/TSMISC02/bdump/tsmisc02_arc0_9459.trc:

    ORA-00354: corrupt redo log block header

    ORA-00353: log corruption near block 3740 change 0 time 04/11/2006 13:49:56

    ORA-00312: online log 1 thread 1: '/oracle/oradata/TSMISC02/redo01.log'

    ARC0: Archiving not possible: error count exceeded

    ARC0: Failed to archive log 1 thread 1 sequence 1597

    ARCH: Archival stopped, error occurred. Will continue retrying

    。。。。。。。

    并且系统会不断的尝试将redo01.log日志文件归档,但是由于这个文件总是不能被成功归档,所以数据库就不断的循环和重复上面的错误信息。

    此时,如果你是用dbv来检查一下redo01.log日志文件的话,你会发现类似下面的信息:

    DBVERIFY - Verification complete

    Total Pages Examined         : 4096

    Total Pages Processed (Data) : 0

    Total Pages Failing   (Data) : 0

    Total Pages Processed (Index): 0

    Total Pages Failing   (Index): 0

    Total Pages Processed (Other): 4

    Total Pages Processed (Seg)  : 0

    Total Pages Failing   (Seg)  : 0

    Total Pages Empty            : 0

    Total Pages Marked Corrupt   : 4096

    Total Pages Influx           : 2

    Highest block SCN            : 1 (0.1)

        这里我们发现,整个日志文件中所有的块都被标记为损坏状态了!

    由此我们可以看到_disable_logging=true对于归档数据库的一个破坏作用之一就是将整个数据库的redo log file都标记为损坏。

     

    那么现在我们应该怎么办呢?首先我们需要使用alert system命令将_disable_logging参数设置为false,然后,依次对所有没有归档的日志做清理未归档日志的工作:

    alter database clear unarchived logfile '/oracle/oradata/TSMISC02/redo01.log'; 

    alter database clear unarchived logfile '/oracle/oradata/TSMISC02/redo02.log'; 

    ......

    注意:

    初始化日志文件的语法:

    ALTER DATABASE [database]

    CLEAR [UNARCHIVED] LOGFILE

    {GROUP integer|('filename'[, 'filename']...)}

    [,{GROUP integer|('filename'[, 'filename']...)}]...

    无论联机重做日志文件是否归档,都可以清除它。

    但是,在其没有归档时,必须包含关键字UNARCHIVED

     

    由于篇幅关系,这里进对部分操作说明一下:

    sys@TSMISC02> alter system set "_disable_logging"=false scope=both;

    System altered.

    Elapsed: 00:00:00.01

    sys@TSMISC02>

    sys@TSMISC02> alter database clear unarchived logfile '/oracle/oradata/TSMISC02/redo02.log'; 

    Database altered.

    Elapsed: 00:00:00.18

    sys@TSMISC02> alter database clear unarchived logfile '/oracle/oradata/TSMISC02/redo03.log'; 

    Database altered.

    Elapsed: 00:00:00.17

    sys@TSMISC02>

    sys@TSMISC02> select * from v$log;

        GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIM

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

             1          1       1600    2097152          1 NO  CURRENT                6950639 12-APR-06

             2          1          0    2097152          1 YES UNUSED                 6919313 11-APR-06

             3          1          0    2097152          1 YES UNUSED                 6922631 11-APR-06

    Elapsed: 00:00:00.00

    sys@TSMISC02>

        其实,需要清理哪些日志,你可以根据alert.log的报错来做,比如这里,当你清理了日志组1,alert中就开始报关于group 2不能归档的信息;当你清理了日志组2,alert中就开始报关于group 3不能归档的信息。。。,以此类推,所有的日志组都被初始化后,数据库就恢复正常了。当然这时后你需要做一个数据库的全备,因为之前的数据库备份已经无效了。

    注意:如果对当前的日志(状态未“CURRENT”的日志组做clear unarchived logfile的操作会有类似下面的报错

    sys@TSMISC02>alter database clear unarchived logfile '/oracle/oradata/TSMISC02/redo01.log'; 

    alter database clear unarchived logfile '/oracle/oradata/TSMISC02/redo01.log'

    *

    ERROR at line 1:

    ORA-01624: log 1 needed for crash recovery of thread 1

    ORA-00312: online log 1 thread 1: '/oracle/oradata/TSMISC02/redo01.log'

    Elapsed: 00:00:00.05

    sys@TSMISC02>

    你只需要使用alter system switch logfile,然后再做clear unarchived logfile的操作就可以了。

        综上,我们已经验证了本章界最初的结论。

    展开全文
  • bbed工具(三个包,用于linux服务器)+bbed安装使用方法,详细的案例恢复:oracle非归档数据库offline的数据文件恢复。做完后可掌握bbed及故障恢复。值得推荐。
  • 简介 DB2 Universal Database™ ...在本文中,我将带您做进一步的探讨,并说明 DB2 UDB 可以如何使用用户出口程序来归档和检索数据库日志文件。另外,我还将提供循序渐进的示例来说明如何修改、编译和测试 db2uex

    简介

    DB2 Universal Database™ 使用日志文件作为确保数据一致性和可恢复性的主要方法。在前一篇文章DB2 通用数据库中事务性日志记录概述中,我介绍了事务性日志记录的概念并说明了如何管理日志。在本文中,我将带您做进一步的探讨,并说明 DB2 UDB 可以如何使用用户出口程序来归档和检索数据库日志文件。另外,我还将提供循序渐进的示例来说明如何修改、编译和测试 db2uext2.cdisk 样本用户出口程序,该程序随已安装的 DB2 UDB 服务器产品附带。您将在本文末尾找到关于用 DB2 UDB 进行用户出口编程的其它参考资料 链接

    本文讨论了 Windows 2000 和 AIX 5L 上的 DB2 V8.1 企业服务器版修订包 1(单分区版)服务器。虽然也有其它样本用户出口程序(例如至磁带的用户出口或 Tivoli 存储管理器(Tivoli Storage Manager)),但我没在本文讨论它们。

    用户出口在 DB2 UDB 中如何工作?

    在 DB2 UDB 中使用用户出口程序是为了提供一种归档和检索数据库日志文件的方法以便进行日志冗余处理以及将日志存储在非易失性的介质上。我们要知道的重要一点是:根据您的特定需求,可以在用户出口中实现包括归档和检索日志在内的其它操作。

    如果需要使用归档日志文件来恢复数据库,则在 DB2 UDB 中实行用户出口策略不会恢复 100% 的事务。用户出口程序只是一种通过将现有日志文件复制到安全位置来提供更多保护的方法。它是数据完整性策略的一部分,但却是重要部分。

    编译了用户出口程序之后,db2uext2 可执行文件将被放在数据库管理器可以发现它的目录中。在 UNIX® 上,该目录是 <instance home>/sqllib/adm ,在 Windows® 上,该目录是 <drive letter>\Program Files\IBM\SQLLIB\BIN 。

    除非数据库管理器知道可以使用用户出口程序,否则它不会调用 db2uext2。数据库管理器知道可以调用 db2uext2 的唯一方法是将数据库配置参数 userexit 设置成 on。一旦设置了该参数并且重复利用了 DB2 实例,数据库管理器就会每五分钟调用一次用户出口程序以检查某些日志文件,这些日志文件可以被归档到特定于程序的归档目录。

    如果需要进行数据库恢复,则数据库管理器将在前滚操作期间调用 db2uext2,以将归档的日志文件复制回活动日志目录中。日志文件就会被重新应用到已恢复的数据库。

    让我们看一看数据库管理器调用用户出口程序的调用格式。请注意,也可以在用户出口样本程序的注释部分找到该信息:

    db2uext2 -OS<os> -RL<release> -RQ<request> -DB<dbname> -NN<nodenumber> -LP<logpath> -LN<logname> [-AP<adsmpasswd>]

    其中: 
        os = 操作系统 
        release = DB2 发行版 
        request = “ARCHIVE”或“RETRIEVE” 
        dbname = 数据库名称 
        nodenumber = 节点号 
        logpath = 日志文件路径 
        logname = 日志文件名 
        logsize = 日志文件大小(可选) 
        startingpage = 以 4K 页大小为单位的起始偏移(可选) 
        adsmpasswd = ADSM 密码(可选)

    注:只有在 logpath 是裸设备时才使用 logsize 和 startingpage。

    用以下命名约定来归档和从磁盘检索日志文件: 
        归档:归档路径+数据库名+节点号+日志文件名 
        检索:检索路径+数据库名+节点号+日志文件名

    例如:如果归档路径是“c:\mylogs”, 
        检索路径是“c:\mylogs”, 
        数据库名是“SAMPLE”, 
        节点号是 NODE0000, 
        文件名是 S0000001.LOG, 
        日志文件将是:

    归档到 - c:\mylogs\SAMPLE\NODE0000\S0000001.LOG 
    检索自 - c:\mylogs\SAMPLE\NODE0000\S0000001.LOG

    下面展示了用户出口中逻辑是如何流动的: 
    1) 安装信号处理程序。 
    2) 验证传递的参数数目。 
    3) 验证请求的操作。 
    4) 启动审计跟踪(如果请求的话)。 
    5) 根据所请求的操作采取以下路径之一: 
        a) 如果请求的操作是归档文件,则将该日志文件从日志路径复制到归档路径。 
            i) 如果没找到日志文件,则到第 6 步。 
        b) 如果请求的操作是检索文件,则将该日志文件从检索路径复制到日志路径。 
            i) 如果没找到日志文件,则到第 6 步。 
    6) 将错误记入日志(如果请求和需要的话)。 
    7) 终止审计跟踪(如果请求的话)。 
    8) 退出并给出适当的返回码。

    可以手工调用用户出口程序以归档日志文件,但最好使用 ARCHIVE LOG 命令以便在指定以上参数时不会因为您的原因而出错。可以在本文的末尾找到 ARCHIVE LOG 命令的 链接

    日志文件术语

    DB2 中用户出口程序的基本功能是将日志文件复制到活动日志目录或从中复制。需要在这里指出一些术语以澄清活动日志目录的位置以及数据库日志文件的状态。

    活动日志目录:

    该目录位于您的数据库目录中。在 Windows 上,如果在 C:\ 创建了名为 SAMPLE 的单一数据库,并且实例名称是 db2inst1,则将存在以下目录结构:

    C:\DB2INST1\NODE0000\SQL000001\SQLOGDIR

    SQL00001 是 SAMPLE 数据库的数据库目录,SQLOGDIR 是活动日志目录。

    下面的图 1 显示了 Windows 操作系统上的活动日志目录:

    图 1. 活动日志目录
    活动日志目录

    日志文件状态

    在活动日志目录中,日志文件可以是 活动日志,也可以是 联机归档日志。活动日志是 DB2 为进行当前事务处理和崩溃恢复而需要的那些日志。联机归档日志是 DB2 UDB 进行常规处理时不再需要的日志,但进行数据库恢复时可能还会需要它。当实现用户出口程序时,这些联机归档日志应该最终作为归档日志目录中的副本出现。

    既然 DB2 UDB 中用户出口程序的目的是将数据库日志复制到归档目录中,您最终将在活动日志目录(缺省是 SQLOGDIR)中得到重复的日志文件。您可能考虑除去这些重复的联机归档日志以释放文件系统空间。在从数据库目录中除去这些日志之前,要十分细心地验证是否已经将它们成功地复制到归档目录中。还必须确保数据库管理器进行崩溃恢复时不再需要它们。要确定活动日志目录中哪些日志文件不为正常处理所需,可用以下命令检查数据库配置:

    db2 "get db cfg for sample"

    该命令的数据库配置输出将包括第一个活动日志文件,例如:

    First active log file = S000009.LOG

    上面输出中所示的日志文件 S000009.LOG 是数据库的当前活动日志。任何小于该编号的日志文件都被认为是联机归档日志。

    下面是一个示例:

    在下面的方案中,活动日志目录中有日志文件 S000000.LOG - S000009.LOG ,归档日志目录中有 S000000.LOG - S000008.LOG 。因为 S000009.LOG 是第一个活动日志文件,所以,可以从活动日志目录中删除 S000001.LOG - S000008.LOG 以释放磁盘空间。必须将S000009.LOG 文件留在活动日志目录中,因为当前事务仍然在使用它。

    也可以检查数据库历史文件,以查看活动日志目录中不再需要哪些日志文件。以下命令将列出数据库备份信息:

        db2 "list history backup all for database sample"

    下面是该命令的输出示例:

                  List History File for sample
    Number of matching file entries = 4
    Op Obj Timestamp+Sequence Type Dev Earliest Log Current Log  
    -- --- ------------------ ---- --- ------------ ------------ 
     B  D  20030416162026001   F    D  S0000010.LOG S0000014.LOG
    ------------------------------------------------------------
    Contains 2 tablespace(s):
    00001 SYSCATSPACE
    00002 USERSPACE1
    ------------------------------------------------------------

    在上面的输出中,最早的日志将表明:需要 S0000010.LOG 及其之后的任何日志。可以安全地删除 S00000010.LOG 之前的任何日志。再次提醒,在从活动日志目录中删除日志文件之前,验证在活动日志目录中存在这些日志文件的副本是非常重要的。

    尽管可以从活动日志目录手工删除日志文件,但是除去联机归档日志文件的更安全方法是通过 prune logfile 命令。可以使用该命令来删除活动日志目录中的日志文件。在下面的示例中,以下命令将删除日志文件 S000000.LOG - S000008.LOG :

    db2 "prune logfile prior to S000009.LOG"

    注:根据您的恢复策略,在有些情况下前面的前滚操作可能会在数据库上执行。归档目录中旧的日志文件可能会被具有相同名称的新日志文件覆盖,从而会阻止您使用旧日志文件对数据库进行时间点恢复。用户出口程序的程序员需要考虑这种情况,这一点非常重要。

    设置用户出口

    在本文中,我们将使用 DB2 所提供的 db2uext2.cdisk 样本 c 程序,它位于您的 c 目录中。在 Unix 上,该目录位于 <instance home>/sqllib/samples 。在 Windows 上,该目录位于 Program Files/IBM/<instance name>/samples 中。

    在 Windows 上设置用户出口程序

    修改并编译用户出口程序

    1. 创建名为 C:\mylogs 的目录。

    2. 将 C:\Program files\IBM\SQLLIB\samples\c\db2uext2.cdisk 复制到工作目录中。

    3. 对于本示例,应该验证用户出口程序的以下部分以反映路径 c:\\mylogs\\ 。

    #define ARCHIVE_PATH  "c:\\mylogs\\"
    #define RETRIEVE_PATH "c:\\mylogs\\"
    #define AUDIT_ACTIVE 1 /* enable audit trail logging */
    #define ERROR_ACTIVE 1 /* enable error trail logging */
    #define AUDIT_ERROR_PATH "c:\\mylogs\\" 
    		/* path must end with a slash */ 
    #define AUDIT_ERROR_ATTR "a" /* append to text file */
    #define BUFFER_SIZE  32 
    		/* # of 4K pages for output buffer */

    4. 确保在系统上安装了受支持的 C 编译器(例如 Microsoft Visual Studio)并且环境中具有该编译器的路径。

    5. 在命令行上,将 db2uext2.cdisk 重新命名为 db2uext2.c ,然后构建它:

        cl db2uext2.c

    一旦编译了程序,将创建 db2uext2.exe 和 db2uext2.obj 文件。

    6. 将 db2uext2.exe 可执行文件放在 /SQLLIB/BIN 目录中,这样数据库管理器可以找到并执行它,以便归档和检索日志。

    创建并准备用户出口的数据库

    7. 在 DB2 命令窗口中用 db2sampl 命令创建 SAMPLE 数据库。这将允许您对下面的示例使用样本表。

    db2sampl

    8. 更新数据库配置文件以便对数据库打开用户出口。请注意:因为 bin 目录由所有 DB2 实例共享,所以只能将用户出口程序分配给一个数据库。

    db2 "update db cfg for sample using userexit on"
    db2stop force
    db2start

    请注意: logretain数据库配置参数不一定必须是 on 才允许对日志文件进行前滚恢复,因为 userexit参数也可以做到这点。

    9. 为了测试的目的,可以通过降低 logfilsiz 数据库配置参数的值来更多地归档日志文件。

        db2 "update db cfg for sample using logfilsiz 200"

    值 200 是每个日志文件可以有的 4k 页的数目。在我们的示例中,每个日志文件的大小将被初始化为 800k(200×4k)。

    10. 既然将 userexit数据库配置参数设置成 YES,则必须进行完整的数据库备份之后才能连接到数据库。记下备份命令所产生的时间戳记,因为这在数据库恢复期间将被用到。

        db2 "backup db sample to c:\backups"

    现在,您的用户出口程序已被启用并可以使用了。您的用户出口程序每 5 分钟将被调用一次,以检查活动日志目录中是否有需要归档的日志文件。请注意:用 logfilsiz数据库配置参数指定的日志文件越大,填充该日志文件所需的时间就越长,从而使该日志文件越容易受到磁盘故障和磁盘毁坏等问题的影响。根据您的事务负载,您应该只指定一个合适的日志文件大小以便可以在适当的时间间隔内填充好该文件,这样用户出口程序可以将该日志文件归档到安全的目录中。

    在更理想的情况下,最好的做法是将日志文件归档到另一个系统的不同磁盘中。这减少了主磁盘的 I/O 流量并且在磁盘或系统崩溃时提供第二层次的保护。

    在 AIX 上设置用户出口程序

    修改并编译用户出口程序

    1. 创建以下目录结构:

    /mylogs/SAMPLE/NODE0000

    然后授予该目录结构中的每个目录递归的许可权:

    chmod -R 777 /mylogs

    2. 将 db2uext2.cdisk 复制到工作目录并授予文件许可权:

    cp /home/db2v8_32/sqllib/samples/c/db2uext2.cdisk /home/db2v8_32/db2uext2.c

    chmod 777 /home/db2v8_32/db2uext2.c

    3. 对于该示例,应该更新用户出口程序的以下部分以反映路径 /mylogs/ 。

    #define ARCHIVE_PATH  "/mylogs/"  
        /* path must end with a slash */
    #define RETRIEVE_PATH "/mylogs/"  
        /* path must end with a slash */
    #define AUDIT_ACTIVE      1   
        /* enable audit trail logging  */
    #define ERROR_ACTIVE      1   
        /* enable error trail logging  */
    #define AUDIT_ERROR_PATH "/mylogs/"  
        /* path must end with a slash */
    #define AUDIT_ERROR_ATTR "a"   
       /* append to text file  */
    #define BUFFER_SIZE     32   
       /* # of 4K pages for output buffer */

    4. 确保在系统上安装了 C 编译器,并且您的环境中具有该编译器的库和路径。

    5. 在命令行中构建 db2uext2.c 程序:

    cc -o db2uext2 db2uext2.c

    一旦编译了程序,将创建 db2uext2 可执行文件。

    6. 将 db2uext2 可执行文件移至 sqllib/adm 目录。

    mv db2uext2 /home/db2v8_32/sqllib/adm/

    创建并准备用户出口的数据库

    7. 用 db2sampl 命令创建 SAMPLE 数据库。这将允许您对下面的示例使用样本表。

    db2sampl

    8. 更新数据库配置文件以便对数据库打开用户出口。

    db2 "update db cfg for sample using 
      userexit on"
    db2stop force
    db2start

    请注意: logretain数据库配置参数不一定必须是 on 才允许对日志文件进行前滚恢复,因为 userexit参数也可以做到这点。

    9. 为了测试的目的,可以通过降低 logfilsiz数据库配置参数的值来更多地归档日志文件。

    db2 "update db cfg for sample using logfilsiz 200"

    值 200 是由 logprimary和 logsecond参数指定的每个日志文件可以有的 4k 页数量。

    10. 既然将 userexit数据库配置参数设置成 YES,则必须进行完整的数据库备份之后才能连接到数据库。记下备份命令所产生的时间戳记,因为这在数据库恢复期间将被用到。

    db2 "backup db sample to /home/db2v8_32/backups"

    现在,您的用户出口程序已被启用并可以使用了。您的用户出口程序每 5 分钟将被调用一次,以检查活动日志目录中是否有需要归档的日志文件。请注意:用 logfilsiz数据库配置参数指定的日志文件越大,填充该日志文件所需的时间就越长,从而使该日志文件越容易受到磁盘故障和磁盘毁坏等问题的影响。根据您的事务负载,您应该只指定一个合适的日志文件大小以便可以在适当的时间间隔内填充好该文件,这样用户出口程序可以将该日志文件归档到安全的目录中。

    在更理想的情况下,最好的做法是将日志文件归档到另一个系统的不同磁盘中。这减少了主磁盘的 I/O 流量并且在磁盘或系统崩溃时提供第二层次的保护。

    测试该用户出口

    在下面的方案中,Windows 用来为与用户出口程序相关的特定文件位置提供可视的表示。改变路径之后,我们还在 AIX 上测试了这些步骤。

    注:对于 Windows 用户,在用用户出口程序进行第一次归档时,将在 mylogs 目录中创建归档目录结构 \SAMPLE\NODE0000 。在 AIX 上手工创建的归档日志路径类似于下面的路径: /sample/NODE0000 (请参阅 在 AIX 上设置用户出口程序)。

    促进日志文件的归档

    方案 1:

    db2 connect to sample
    db2 "insert into staff (select * from staff)"
    db2 connect reset

    (必须释放所有的数据库连接,以便数据库释放资源并关闭日志文件)

    检查 c:\mylogs\SAMPLE\NODE0000 目录。

    上面的方案将截断当前活动的日志文件并将它复制到 c:\mylogs 目录。被截断的日志文件的大小将小于 800k,以防止浪费空间。

    下面的图 2 演示了被移至归档目录的被截断的日志文件。

    图 2. 被截断的日志文件
    被截断的日志文件

    方案 2:

    还可以通过用数据填充日志文件来进行测试。数据库管理器将检查全部日志文件,并将它们复制到归档目录中。

    db2 "connect to sample"
    db2 "insert into staff 
        (select * from staff)"

    (执行该插入语句 10 次以填充日志文件)

    请记住您将数据库配置参数 logfilsiz更新成了 200 个 4k 页(800k),以便迅速填充日志文件。

    现在可以检查 c:\mylogs 目录。

    下面的图 3 显示了已归档日志的位置。

    图 3. 已归档日志的位置
    已归档日志的位置

    如果您的用户出口程序工作正常,您应该在 c:\mylogs 中看到 ARCHIVE.LOG,并且一个或多个日志文件应该被复制到c:\mylogs\SAMPLE\NODE0000\ 。

    下面的图 4 显示了 ARCHIVE.LOG 文件的位置:

    图 4. ARCHIVE.LOG 文件的位置
    ARCHIVE.LOG 文件的位置

    在数据库恢复期间检索已归档日志文件

    现在我们将执行数据库恢复。恢复过程将调用用户出口程序以从 c:\mylogs 目录将日志文件取回活动日志目录,在那里,日志文件可以在前滚恢复期间被应用到数据库。

    db2 connect reset
    db2 "restore database sample from c:\backups 
    taken at 20030416114420"
    SQL2539W  Warning!  Restoring to an existing 
    database that is the same as the backup image 
    database. The database files will be deleted. 
    Do you want to continue? (y/n)

    恢复命令中的值 20030416114420 是取自前一次数据库备份的时间戳记。既然我们是在现有样本数据库的基础上进行恢复,您会接收到以上警告消息。选择 Y,然后按 Enter 键。

    db2 "rollforward db sample to end of logs 
    and stop"
             Rollforward Status
    Input database alias        = sample
    Number of nodes have returned status = 1
    Node number                 = 0
    Rollforward status          = not pending
    Next log file to be read    =
    Log files processed         = S0000000.LOG - 
    							  S0000004.LOG
    Last committed transaction = 2003-04-16-17.33.49.000000
    DB20000I The ROLLFORWARD command completed successfully.

    下面的图 5 显示了创建 RETRIEVE.LOG 的位置。

    图 5. ARCHIVE.LOG 文件的位置
    ARCHIVE. LOG 文件的位置

    对于传递回活动日志目录的每一个日志文件,都会有一条消息写入 c:\mylogs\RETRIEVE.LOG 文件中。

    *************************************************
    Time Started:     Wed Apr 16 12:47:31 2003
    Parameter Count: 8
    Parameters Passed: 
    Database name:  SAMPLE
    Logfile name:   S0000004.LOG
    Logfile path:  C:\SAMPLE\NODE0000\SQL00002\SQLOGDIR\
    Node number:    NODE0000
    Operating system: NT
    Release:        SQL08010
    Request:        RETRIEVE
    System Action:  RETRIEVE to 
    				C:\SAMPLE\NODE0000\SQL00002\SQLOGDIR\
                    file S0000004.LOG from c:\mylogs\SAMPLE
    Media Type:     disk
    User Exit RC:   0
    Time Completed: Wed Apr 16 12:47:31 2003

    结束语

    我已经简单介绍了如何在 DB2 UDB 中使用用户出口程序。需要重点说明的是:可以编写和修改 DB2 UDB 的用户出口程序以适合您的需要。其它编程注意事项包括:删除归档日志目录中的重复日志文件(它们可能是在某些情况下被创建的),考虑到时间点恢复之后存在同名的不同日志文件,从归档目录中除去不再需要的日志文件以及错误处理。这些是您在修改或创建自己的用户出口程序时需要考虑的事项。可以在下面的链接中找到有关用户出口编程方面的更多信息。

    转自:http://www.ibm.com/developerworks/cn/data/library/techarticles/0307kline/0307kline.html

    展开全文
  • 然而WINCC与其它的工控软件包有不同的地方:它的数据是保存在标准的及功能强大的Sybase SQL Anywhere数据库中,所以,我们可以像访问一般的数据库一样,通过ODBC直接访问WINCC的历史数据库。一、 通过Sybase Central...
  • 使用VB或VBS访问WINCC6.0历史数据库从WINCC6.0开始,就开始采用SQL3000SP3做为WINCC的后台数据了.而这个SQL2000SP3是由SIEMENS为WINCC做了二次开发的,采用了一些独有的技术,一些是我们知道的,一些是我们所不知道的....
  • 由于数据库是非归档模式 所以我要设置数据库变更为归档模式 语句如下: SQL> alter system set log_archive_dest_1='location=+DG1' scope=spfile; 系统已更改。 SQL> alter system set log_archive_...
  • –连接恢复管理器 C:\Documents and Settings\mengzhaoliang>rman target/ –归档日志列表 RMAN> list archivelog all;...查看oracle数据库是否为归档模式: 1.select name,log_mode from v$database; NAME L
  • RAMN恢复数据库的过程 1 修复数据库 ...1)是在数据文件的介质恢复,也就是为修复后的数据文件应用联机或者归档重做日志,从而将修复的数据库文件更新到当前时刻或指定时刻的状态 2)执行恢复数据
  • 数据库归档模式

    2012-06-08 17:24:08
    数据库运行有2种模式,归档模式和非归档模式 归档模式下: 用户做的所有操作都会记录在redo online log里面, 一般都是3 redo log, 默认情况下一个redo log file是50m,当满了后,
  • 什么是数据库归档

    2020-12-14 22:35:09
     数据库归档技术是一种保持在线数据库规模大体不变却有能够为用户应用提供稳定的数据库性能的方法。其工作原理是,将数据库中不经常使用的数据迁移至近线设备,将长期不使用的数据迁移至文件形式归档。这样,随着...
  • 数据库归档管理.pdf

    2021-10-11 01:10:10
    数据库归档管理.pdf
  • 1)修改数据库为 MOUNT 状态。 SQL>ALTER DATABASE MOUNT; 2)配置本地归档。 eg : ALTER DATABASE ADD ARCHIVELOG ‘DEST = /home/dmdba/dmdbms/data/lixora/DAMENG/arch, TYPE = local,FILE_SIZE = 1024, SPACE_...
  • 数据库归档日志

    千次阅读 2019-10-22 17:13:33
    其对数据库备份和恢复有下列用处: 数据库后备以及在线和归档日志文件,在操作系统和磁盘故障中可保证全部提交的事物可被恢复。 在数据库打开和正常系统使用下,如果归档日志是永久保存,在线后备可以进行和使用。 ...
  • oracle 数据库归档日志

    千次阅读 2018-09-11 09:23:04
    数据库归档日志 在系统创建归档路径mkdir /u01/arch  修改数据库归档日志的路径参数alter system set log_archive_dest_1='location=/u01/arch' scope=spfile; show parameter arch可查看归档日志文件  修改...
  • 1.归档模式 Oracle数据库有联机重做日志,这个日志是记录对数据库所做的修改,比如插入,删除,更新数据等,对这些操作都会记录在联机重做日志里。一般数据库至少要有2个联机重做...如果数据库处于非归档模式,联机日志
  • 数据库归档策略

    千次阅读 2018-10-18 21:54:47
    为备战双11,需要将数据库中的相关表(历史订单)进行归档,以便腾出更多的空间迎接订单的暴增。作者经过尝试,得出自认为最优的解决方案。下面给出数据库归档策略及示例代码。 现有条件: 1.现有两个数据库:db-A ...
  • Berkeley DB数据库和日志文件归档

    千次阅读 2014-04-08 09:46:18
    归档数据库和日志文件目的是提供面对数据库的灾难性故障的可恢复性,最大限度地减少发生物理硬件故障导致数据丢失。 首先,你可能需要定期创建数据库快照(也就是备份),以使数据有可能从灾难性故障中恢复。快照是...
  • OARCLE数据库OARCLE数据库归档模式的切换归档模式的切换OARCLE数据库归档OARCLE数据库归档模式的切换模式的切换
  • Oracle数据库归档

    2011-11-06 14:19:40
    ORACLE数据库有两种运行方式:一是归档方式(ARCHIVELOG),归档方式的目的是当数据库发生故障时最大限度恢复所有已提交的事物;二是不归档方式(NOARCHIVELOG),恢复数据库到最近的回收点。我们根据数据库的高可用性...
  • 数据库归档模式详解

    2014-04-01 18:20:33
    数据库归档模式详解 很详细的介绍,又需要的可以看看
  • Oracle分为非归档模式(NOARCHIVELOG) 和归档模式(ARCHIVELOG)。非归档模式不产生归档日志,虽然...  首先查看数据库现有模式可使用以下语句  select name,log_mode from v$database;  也可以用下面的语句  arch
  • 数据库归档模式开启

    2018-04-08 18:57:35
    一般情况下为了数据库可恢复,需要把数据库修改为归档模式,接下来讲解一下修改过程;1、使用管理员登录2、查看当前的归档模式、归档状态、归档进程select log_mode from v$database; select * from v$archive_...
  • oracle 数据库开启归档日志模式方法的语句脚本,希望可以对大家在日常的学习工作中有所帮助,开归档的方法有很多种,本次使用的是比较通用方法。
  • 设计数据库自动备份功能;数据库由非归档模式调整为归档模式命令。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 102,962
精华内容 41,184
关键字:

归档数据库