Oracle主库归档丢失,备库日志有gap,在不重建备库的情况下,恢复备库

本文涉及的产品
云原生数据仓库AnalyticDB MySQL版,基础版 8ACU 100GB 1个月
日志服务 SLS,月写入数据量 50GB 1个月
简介:

本文主要描述Oracle备库日志与主库日志之间有gap,切主库这部分gap的归档日志已经删除或丢失,如何在不重建备库的情况下,恢复备库。


欢迎转载,请注明作者、出处。
作者:张正
blog:http://space.itpub.net/26355921 
QQ:176036317
如有疑问,欢迎联系。


在dataguard环境中,由于主库archivelog丢失,且尚未同步到standby,问如何在避免
重建standby的情况下来将standby恢复成功的。 下面是我的测试过程,供参考!
—-主库
SQL> SELECT database_role FROM v$database;
DATABASE_ROLE
----------------
PRIMARY
SQL> archive log list;
DATABASE log mode              Archive Mode
Automatic archival             Enabled
Archive destination            /arch
Oldest online log SEQUENCE     382
NEXT log SEQUENCE TO archive   383
CURRENT log SEQUENCE           383
SQL> SELECT COUNT(1) FROM roger.test;
 
  COUNT(1)
----------
        30
—-备库
SQL> SELECT database_role FROM v$database;
 
DATABASE_ROLE
----------------
PHYSICAL STANDBY
 
SQL> archive log list;
DATABASE log mode              Archive Mode
Automatic archival             Enabled
Archive destination            /arch2
Oldest online log SEQUENCE     382
NEXT log SEQUENCE TO archive   0
CURRENT log SEQUENCE           383
SQL> 
SQL> ALTER DATABASE recover managed standby DATABASE cancel;
DATABASE altered.
SQL> ALTER DATABASE OPEN READ ONLY;
DATABASE altered.
SQL> SELECT COUNT(1) FROM roger.test;
COUNT(1)
----------
        30
模拟主库丢失归档的情况:
—主库
SQL> SELECT * FROM v$Log;
 
    GROUP#    THREAD#  SEQUENCE#      BYTES    MEMBERS ARC STATUS           FIRST_CHANGE# FIRST_TIME
---------- ---------- ---------- ---------- ---------- --- ---------------- ------------- ------------
         1          1        383   10485760          1 NO  CURRENT                 740638 10-OCT-12
         2          1        382   20971520          1 YES INACTIVE                740633 10-OCT-12
 
SQL> archive log list;
DATABASE log mode              Archive Mode
Automatic archival             Enabled
Archive destination            /arch
Oldest online log SEQUENCE     382
NEXT log SEQUENCE TO archive   383
CURRENT log SEQUENCE           383
SQL> ALTER system SET log_archive_dest_state_2 = 'defer';
System altered.
SQL> DELETE FROM roger.test WHERE rownum < 11;
10 ROWS deleted.
SQL> commit;
Commit complete.
SQL> SELECT COUNT(*) FROM roger.test;
COUNT(*)
----------
        20
 
SQL> ALTER system switch logfile;
 
System altered.
SQL> /
System altered.
SQL> /
System altered.
SQL> !
[oracle@primarydb ~]$ cd /arch
[oracle@primarydb arch]$ ls -ltr|tail -10
-rw-r-----  1 oracle dba  3456000 Oct 10 15:18 1_374_726529113.dbf
-rw-r-----  1 oracle dba   593408 Oct 10 15:23 1_375_726529113.dbf
-rw-r-----  1 oracle dba     4608 Oct 10 15:23 1_376_726529113.dbf
-rw-r-----  1 oracle dba     1024 Oct 10 15:23 1_377_726529113.dbf
-rw-r-----  1 oracle dba    68096 Oct 10 15:25 1_378_726529113.dbf
-rw-r-----  1 oracle dba  1297408 Oct 10 15:34 1_379_726529113.dbf
-rw-r-----  1 oracle dba     2048 Oct 10 18:35 1_382_726529113.dbf
-rw-r-----  1 oracle dba   166400 Oct 10 18:44 1_383_726529113.dbf
-rw-r-----  1 oracle dba     2560 Oct 10 18:44 1_384_726529113.dbf
-rw-r-----  1 oracle dba     1024 Oct 10 18:44 1_385_726529113.dbf
[oracle@primarydb arch]$ rm 1_383_726529113.dbf  ---删除archivelog
[oracle@primarydb arch]$ rm 1_384_726529113.dbf 
[oracle@primarydb arch]$ exit
exit
SQL> ALTER system SET log_archive_dest_state_2 = 'enable';
System altered.
SQL>
—备库
SQL> ALTER DATABASE recover managed standby DATABASE disconnect FROM SESSION;
DATABASE altered.
SQL> 
此时alert log信息如下:
Tue Nov 13 14:45:26 2012
MRP0: Background Managed Standby Recovery process started (test)
Managed Standby Recovery NOT USING REAL TIME Apply
 parallel recovery started WITH 2 processes
Tue Nov 13 14:45:31 2012
Waiting FOR ALL non-CURRENT ORLs TO be archived...
Media Recovery Waiting FOR thread 1 SEQUENCE 383
Tue Nov 13 14:45:32 2012
Completed: ALTER DATABASE recover managed standby DATABASE disconnect FROM SESSION
Tue Nov 13 14:45:59 2012
Redo Shipping Client Connected AS PUBLIC
-- Connected User is Valid
RFS[2]: Assigned TO RFS process 9542
RFS[2]: IDENTIFIED DATABASE TYPE AS 'physical standby'
RFS[2]: Archived Log: '/arch2/1_385_726529113.dbf'
Tue Nov 13 14:46:02 2012
Fetching gap SEQUENCE IN thread 1, gap SEQUENCE 383-384
Tue Nov 13 14:47:02 2012
FAL[client]: Failed TO request gap SEQUENCE 
 GAP - thread 1 SEQUENCE 383-384
 DBID 2024668720 branch 726529113
FAL[client]: ALL defined FAL servers have been attempted.
-------------------------------------------------------------
CHECK that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter IS defined TO a VALUE that IS sufficiently LARGE
enough TO maintain adequate log switch information TO resolve
archivelog gaps.
如何在重建standby的情况下搞好备库呢?mos上,其实也有文章进行描述的,就是利用rman进行增量scn的恢复,下面我来进行展示:
1)首先定位到scn
SQL> SELECT SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE# FROM v$archived_log WHERE SEQUENCE# > 382 ORDER BY 1;
 
 SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ------------- ------------
       383        740638       740911
       384        740911       740915
       385        740915       740917
       385        740915       740917
2)根据scn,进行rman增量备份
[oracle@primarydb ~]$ cd $ORACLE_HOME/bin
[oracle@primarydb bin]$ ./rman target /
Recovery Manager: Release 10.2.0.4.0 - Production on Wed Oct 10 18:51:57 2012
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
connected to target database: TEST (DBID=2024668720)
RMAN> backup device type disk incremental from scn 740638 database format '/tmp/test_db_incre.bbk';
Starting backup at 10-OCT-12
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=147 devtype=DISK
channel ORA_DISK_1: starting full datafile backupset
channel ORA_DISK_1: specifying datafile(s) in backupset
input datafile fno=00004 name=/oracle/product/oradata/test/test01.dbf
input datafile fno=00007 name=/oracle/product/oradata/test/sysaux01.dbf
input datafile fno=00009 name=/oracle/product/oradata/test/test03.dbf
input datafile fno=00006 name=/oracle/product/oradata/test/undo02.dbf
input datafile fno=00001 name=/oracle/product/oradata/test/system01.dbf
input datafile fno=00005 name=/oracle/product/oradata/test/perfstat.dbf
input datafile fno=00003 name=/oracle/product/oradata/test/rman.dbf
input datafile fno=00002 name=/oracle/product/oradata/test/undo01.dbf
input datafile fno=00008 name=/oracle/product/oradata/test/test02.dbf
input datafile fno=00010 name=/oracle/product/oradata/test/test04.dbf
input datafile fno=00011 name=/oracle/product/oradata/test/test05.dbf
channel ORA_DISK_1: starting piece 1 at 10-OCT-12
channel ORA_DISK_1: finished piece 1 at 10-OCT-12
piece handle=/tmp/test_db_incre.bbk tag=TAG20121010T185204 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:03:26
Finished backup at 10-OCT-12
RMAN>
3) 拷贝增量备份到standby
[oracle@primarydb bin]$ cd /tmp
[oracle@primarydb tmp]$ scp test_db_incre.bbk 192.168.3.176:/tmp/backup
The authenticity of host '192.168.3.176 (192.168.3.176)' can't be established.
RSA key fingerprint is a4:54:6b:bf:12:34:42:73:f5:ba:5f:38:c7:28:9c:b5.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.3.176' (RSA) to the list of known hosts.
oracle@192.168.3.176's password: 
test_db_incre.bbk                             100%  736KB 736.0KB/s   00:00    
[oracle@primarydb tmp]$
4) standby进行recover
[oracle@standbydb bin]$ sqlplus "/as sysdba"
SQL*Plus: Release 10.2.0.4.0 - Production ON Tue Nov 13 15:03:46 2012
Copyright (c) 1982, 2007, Oracle.  ALL Rights Reserved.
Connected TO:
Oracle DATABASE 10g Enterprise Edition Release 10.2.0.4.0 - Production
WITH the Partitioning, OLAP, DATA Mining AND REAL Application Testing options
SQL> ALTER DATABASE recover managed standby DATABASE cancel;
DATABASE altered.
SQL> exit
Disconnected FROM Oracle DATABASE 10g Enterprise Edition Release 10.2.0.4.0 - Production
WITH the Partitioning, OLAP, DATA Mining AND REAL Application Testing options
[oracle@standbydb ~]$ cd $ORACLE_HOME/bin
[oracle@standbydb bin]$ ./rman target /
Recovery Manager: Release 10.2.0.4.0 - Production ON Tue Nov 13 14:58:25 2012
Copyright (c) 1982, 2007, Oracle.  ALL rights reserved.
connected TO target DATABASE: TEST (DBID=2024668720, NOT OPEN)
RMAN> catalog backuppiece '/tmp/backup/test_db_incre.bbk';
USING target DATABASE control file instead OF recovery catalog
cataloged backuppiece
backup piece handle=/tmp/backup/test_db_incre.bbk recid=49 stamp=799253957
RMAN>  recover DATABASE noredo;
Starting recover at 13-NOV-12
USING target DATABASE control file instead OF recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=97 devtype=DISK
channel ORA_DISK_1: starting incremental datafile backupset restore
channel ORA_DISK_1: specifying datafile(s) TO restore FROM backup SET
destination FOR restore OF datafile 00001: /oracle/product/oradata/test/system01.dbf
destination FOR restore OF datafile 00002: /oracle/product/oradata/test/undo01.dbf
destination FOR restore OF datafile 00003: /oracle/product/oradata/test/rman.dbf
destination FOR restore OF datafile 00004: /oracle/product/oradata/test/test01.dbf
destination FOR restore OF datafile 00005: /oracle/product/oradata/test/perfstat.dbf
destination FOR restore OF datafile 00006: /oracle/product/oradata/test/undo02.dbf
destination FOR restore OF datafile 00007: /oracle/product/oradata/test/sysaux01.dbf
destination FOR restore OF datafile 00008: /oracle/product/oradata/test/test02.dbf
destination FOR restore OF datafile 00009: /oracle/product/oradata/test/test03.dbf
destination FOR restore OF datafile 00010: /oracle/product/oradata/test/test04.dbf
destination FOR restore OF datafile 00011: /oracle/product/oradata/test/test05.dbf
channel ORA_DISK_1: reading FROM backup piece /tmp/backup/test_db_incre.bbk
channel ORA_DISK_1: restored backup piece 1
piece handle=/tmp/backup/test_db_incre.bbk tag=TAG20121010T185204
channel ORA_DISK_1: restore complete, elapsed TIME: 00:00:01
Finished recover at 13-NOV-12
RMAN> 
如下信息是recover时,alert log的记录信息:
Tue Nov 13 15:04:05 2012
Completed: ALTER DATABASE recover managed standby DATABASE cancel
Tue Nov 13 15:04:55 2012
Incremental restore complete OF datafile 2 /oracle/product/oradata/test/undo01.dbf
  checkpoint IS 741134
Incremental restore complete OF datafile 8 /oracle/product/oradata/test/test02.dbf
  checkpoint IS 741134
Incremental restore complete OF datafile 10 /oracle/product/oradata/test/test04.dbf
  checkpoint IS 741134
Incremental restore complete OF datafile 11 /oracle/product/oradata/test/test05.dbf
  checkpoint IS 741134
Incremental restore complete OF datafile 3 /oracle/product/oradata/test/rman.dbf
  checkpoint IS 741134
Incremental restore complete OF datafile 5 /oracle/product/oradata/test/perfstat.dbf
  checkpoint IS 741134
Incremental restore complete OF datafile 1 /oracle/product/oradata/test/system01.dbf
  checkpoint IS 741134
Incremental restore complete OF datafile 6 /oracle/product/oradata/test/undo02.dbf
  checkpoint IS 741134
Incremental restore complete OF datafile 4 /oracle/product/oradata/test/test01.dbf
  checkpoint IS 741134
Incremental restore complete OF datafile 7 /oracle/product/oradata/test/sysaux01.dbf
  checkpoint IS 741134
Incremental restore complete OF datafile 9 /oracle/product/oradata/test/test03.dbf
  checkpoint IS 741134
5) 开启standby同步,检查是否ok。
SQL> ALTER DATABASE recover managed standby DATABASE disconnect FROM SESSION;
DATABASE altered.
SQL> SELECT database_role,open_mode FROM v$database;
DATABASE_ROLE    OPEN_MODE
---------------- ----------
PHYSICAL STANDBY MOUNTED
--主库切换日志
SQL> SELECT database_role,open_mode FROM v$database;
DATABASE_ROLE    OPEN_MODE
---------------- ----------
PRIMARY          READ WRITE
SQL> 
SQL> ALTER system switch logfile;
System altered.
SQL> SELECT MAX(al.SEQUENCE#) "Last Seq Recieved",
  2         MAX(lh.SEQUENCE#) "Last Seq Applied"
  3  FROM v$archived_log al, v$log_history lh;  
LAST Seq Recieved LAST Seq Applied
----------------- ----------------
              386              386
SQL> 
--备库
SQL> SELECT MAX(al.SEQUENCE#) "Last Seq Recieved",
  2         MAX(lh.SEQUENCE#) "Last Seq Applied"
  3  FROM v$archived_log al, v$log_history lh;  
 
LAST Seq Recieved LAST Seq Applied
----------------- ----------------
              386              382
 
SQL> 
SQL> SELECT * FROM v$archive_gap;   
 
   THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
         1           383            384
备库archivelog:
[oracle@standbydb arch2]$ ls -ltr |tail -5
-rw-r-----  1 oracle dba     2048 Nov 13 14:33 1_381_726529113.dbf
-rw-r-----  1 oracle dba     2048 Nov 13 14:34 1_382_726529113.dbf
-rw-r-----  1 oracle dba     1024 Nov 13 14:45 1_385_726529113.dbf
-rw-r-----  1 oracle dba  1262080 Nov 13 15:06 1_386_726529113.dbf
备库alert log此时的信息:
Tue Nov 13 15:06:17 2012
ALTER DATABASE recover managed standby DATABASE disconnect FROM SESSION
Tue Nov 13 15:06:17 2012
Attempt TO START background Managed Standby Recovery process (test)
MRP0 started WITH pid=19, OS id=13497
Tue Nov 13 15:06:17 2012
MRP0: Background Managed Standby Recovery process started (test)
Managed Standby Recovery NOT USING REAL TIME Apply
 parallel recovery started WITH 2 processes
Tue Nov 13 15:06:22 2012
Waiting FOR ALL non-CURRENT ORLs TO be archived...
Media Recovery Waiting FOR thread 1 SEQUENCE 383
Fetching gap SEQUENCE IN thread 1, gap SEQUENCE 383-384
Tue Nov 13 15:06:23 2012
Completed: ALTER DATABASE recover managed standby DATABASE disconnect FROM SESSION
Tue Nov 13 15:06:54 2012
Redo Shipping Client Connected AS PUBLIC
-- Connected User is Valid
RFS[3]: Assigned TO RFS process 13596
RFS[3]: IDENTIFIED DATABASE TYPE AS 'physical standby'
PRIMARY DATABASE IS IN MAXIMUM PERFORMANCE mode
PRIMARY DATABASE IS IN MAXIMUM PERFORMANCE mode
RFS[3]: Successfully opened standby log 4: '/oracle/product/oradata/test/redo04.log'
Tue Nov 13 15:06:54 2012
RFS[2]: Successfully opened standby log 3: '/oracle/product/oradata/test/redo03.log'
Tue Nov 13 15:07:23 2012
FAL[client]: Failed TO request gap SEQUENCE 
 GAP - thread 1 SEQUENCE 383-384
 DBID 2024668720 branch 726529113
FAL[client]: ALL defined FAL servers have been attempted.
-------------------------------------------------------------
CHECK that the CONTROL_FILE_RECORD_KEEP_TIME initialization
parameter IS defined TO a VALUE that IS sufficiently LARGE
enough TO maintain adequate log switch information TO resolve
archivelog gaps.
我们可以看到,虽然备库,仍然在提示383,384是gap ,但是实际上已经是同步的了。
6)最后来验证下数据
SQL> ALTER DATABASE recover managed standby DATABASE cancel;
DATABASE altered.
SQL> SELECT file#,checkpoint_change# FROM v$datafile ORDER BY 1;
 
     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1             740638
         2             740638
         3             740638
         4             740638
         5             740638
         6             740638
         7             740638
         8             740638
         9             740638
        10             740638
        11             740638
11 ROWS selected.
SQL> SELECT file#,checkpoint_change# FROM v$datafile_header ORDER BY 1;
 
     FILE# CHECKPOINT_CHANGE#
---------- ------------------
         1             741134
         2             741134
         3             741134
         4             741134
         5             741134
         6             741134
         7             741134
         8             741134
         9             741134
        10             741134
        11             741134
11 ROWS selected.
SQL> ALTER DATABASE OPEN READ ONLY;
ALTER DATABASE OPEN READ ONLY
*
ERROR at line 1:
ORA-16004: backup DATABASE requires recovery
ORA-01152: file 1 was NOT restored FROM a sufficiently OLD backup
ORA-01110: DATA file 1: '/oracle/product/oradata/test/system01.dbf'
重建备库的standby controlfile:
SQL> ALTER DATABASE CREATE standby controlfile AS '/tmp/standby.ctl';        
DATABASE altered.
SQL> exit
Disconnected FROM Oracle DATABASE 10g Enterprise Edition Release 10.2.0.4.0 - Production
WITH the Partitioning, OLAP, DATA Mining AND REAL Application Testing options
[oracle@primarydb tmp]$ scp standby.ctl 192.168.3.176:/tmp/backup
oracle@192.168.3.176's password: 
standby.ctl                                                 100% 3928KB   3.8MB/s   00:00    
[oracle@primarydb tmp]$ 
[oracle@standbydb bin]$ ./rman target /
Recovery Manager: Release 10.2.0.4.0 - Production on Tue Nov 13 15:19:09 2012
Copyright (c) 1982, 2007, Oracle.  All rights reserved.
connected to target database (not started)
RMAN> startup nomount   
Oracle instance started
Total System Global Area     264241152 bytes
Fixed Size                     1266944 bytes
Variable Size                209718016 bytes
Database Buffers              50331648 bytes
Redo Buffers                   2924544 bytes
RMAN> restore controlfile from '/tmp/backup/standby.ctl';
Starting restore at 13-NOV-12
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=101 devtype=DISK
channel ORA_DISK_1: copied control file copy
output filename=/oracle/product/oradata/test/control01.ctl
Finished restore at 13-NOV-12
RMAN> startup mount
database is already started
database mounted
released channel: ORA_DISK_1
RMAN> exit
Recovery Manager complete.
[oracle@standbydb bin]$ sqlplus "/as sysdba"
SQL*Plus: Release 10.2.0.4.0 - Production on Tue Nov 13 15:20:02 2012
Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> alter database recover managed standby database disconnect from session;
Database altered.
SQL> alter database recover managed standby database cancel;
Database altered.
SQL> 
SQL> 
SQL> alter database open read only;
Database altered.
SQL> select count(1) from roger.test;
COUNT(1)
----------
        20
SQL>
最后,我们可以看到,在主库archivelog丢失无法同步到备库时,可以利用增量scn的方式,来避免重建standby。
本文转自ITPUB博客84223932的博客,原文链接:Oracle主库归档丢失,备库日志有gap,在不重建备库的情况下,恢复备库,如需转载请自行联系原博主。
相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
2月前
|
前端开发 C语言 开发者
领导被我的花式console.log吸引了!直接写入公司公共库!
【8月更文挑战第23天】领导被我的花式console.log吸引了!直接写入公司公共库!
39 2
领导被我的花式console.log吸引了!直接写入公司公共库!
|
6天前
|
Oracle 关系型数据库 MySQL
shell获取多个oracle库mysql库所有的表
请注意,此脚本假设你有足够的权限访问所有提到的数据库。在实际部署前,请确保对脚本中的数据库凭据、主机名和端口进行适当的修改和验证。此外,处理数据库操作时,务必谨慎操作,避免因错误的脚本执行造成数据损坏或服务中断。
29 0
|
15天前
|
存储 运维 监控
超级好用的C++实用库之日志类
超级好用的C++实用库之日志类
25 0
|
2月前
|
JSON 中间件 Go
go语言后端开发学习(四) —— 在go项目中使用Zap日志库
本文详细介绍了如何在Go项目中集成并配置Zap日志库。首先通过`go get -u go.uber.org/zap`命令安装Zap,接着展示了`Logger`与`Sugared Logger`两种日志记录器的基本用法。随后深入探讨了Zap的高级配置,包括如何将日志输出至文件、调整时间格式、记录调用者信息以及日志分割等。最后,文章演示了如何在gin框架中集成Zap,通过自定义中间件实现了日志记录和异常恢复功能。通过这些步骤,读者可以掌握Zap在实际项目中的应用与定制方法
go语言后端开发学习(四) —— 在go项目中使用Zap日志库
|
2月前
|
Linux API
在Linux中,程序产生了库日志虽然删除了,但磁盘空间未更新是什么原因?
在Linux中,程序产生了库日志虽然删除了,但磁盘空间未更新是什么原因?
|
2月前
|
存储 JSON 前端开发
一文搞懂 Go 1.21 的日志标准库 - slog
一文搞懂 Go 1.21 的日志标准库 - slog
65 2
|
2月前
|
JSON Go API
一文搞懂 Golang 高性能日志库 - Zap
一文搞懂 Golang 高性能日志库 - Zap
71 2
|
2月前
|
SQL Oracle 关系型数据库
"揭秘!一键解锁Oracle日志清理魔法,让海量归档日志无处遁形,守护数据库健康,告别磁盘空间告急噩梦!"
【8月更文挑战第9天】随着Oracle数据库在企业应用中的普及,归档日志管理对保持数据库健康至关重要。归档日志记录所有更改,对数据恢复极为重要,但也可能迅速占用大量磁盘空间影响性能。利用Oracle提供的RMAN工具,可通过编写Shell脚本来自动清理归档日志。脚本包括设置环境变量、连接数据库、检查和删除指定时间前的日志,并记录执行情况。通过Cron作业定时运行脚本,可有效管理日志文件,确保数据库稳定运行。
79 7
|
2月前
|
存储 安全 Python
[python]使用标准库logging实现多进程安全的日志模块
[python]使用标准库logging实现多进程安全的日志模块
|
2月前
|
SQL 监控 Oracle
Oracle数据误删不用怕,跟我来学日志挖掘
Oracle数据误删不用怕,跟我来学日志挖掘
25 0

推荐镜像

更多