SQL Server数据库如何避免被勒索病毒攻击

2016/02/28 by Leave a Comment

如果自己搞不定可以找诗檀软件专业SQL SERVER数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com

 

什么是勒索病毒?

 

目前现有的勒索病毒绝大部分针对Windows平台，且主要集中在Windows XP,7,server 2003 ,2008 等操作系统平台。绝大部分通过加密各种文件以达到勒索的目的；一般来说这种加密都是部分加密，这是因为加密大文件耗时长、CPU消耗大；例如给一个1GB大小的文件做全加密，需要消耗较多的CPU、内存和时间。所以即便SQL SERVER的MDF文件被加密了，只要文件本身比较大，一般用户数据不会被破坏。

 

SQL SERVER MSSQL 针对勒索病毒最主要的防护就是升级操作系统

 

因为目前主流版本的SQL SERVER仍存在于Windows平台上，所以主要是避免使用Window XP、7、Server 2003、Server 2008这些版本的操作系统。

Windows Server 2012 R2 entered mainstream support on November 25, 2013, though, but its end of mainstream is January 9, 2018, and end of extended is January 10, 2023.

Windows Server 2012 R2的扩展支持时间最晚到2023年1月，所以在选择操作系统时尽可能选择Windows Server 2016 以后的版本。

如果没法升级操作系统，那么至少：

  • 彻底禁用 smb v1，以预防Wannacry在您的网络中传播。
  • 安装Microsoft修补程式也可预防Wannacry在您的网络中传播。在国内你可以使用360辅助安装补丁，在安装完补丁后再卸载360

 

其他的一些预防措施：

 

  • 必要的备份，例如每天做逻辑和物理备份。备份完之后上传到其他服务器例如Linux服务器，同时上传到例如One Drive、百度云盘之类的云存储。
  • 在企业内部使用SQL Sever时将SQL SERVER所在网络做物理隔离，例如在机房中单独开辟一个区域存放重要数据库，包括网络隔离
  • 对于复杂的企业内部环境而言，可能其内部网络安装还不如存放在公有云上。公有云做好网络IP隔离可以做到一定程度的安全，同时可以组织多个公有云互作备份。例如一套数据库运行在阿里云上，其备份归集到腾讯云和华为云上
  • 采用正版软件，下载软件只取对应网站的官方地址
  • 考虑迁移到Linux上的SQL SERVER。因为Windows的高采用率，这会导致攻击软件主要面向Windows
  • 设置负载的密码，并定期更新。建议企业内部使用onepassword类的密码管理软件

 

 

Filed Under: MSSQL SQL SERVER

SQL SERVER Msg 5172 not a valid database file header 无法附加数据库文件The PageAudit Property is Incorrect

2016/02/28 by Leave a Comment

如果自己搞不定可以找诗檀软件专业SQL SERVER数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com

 

 

若你的SQL SERVER数据库出现Msg 5172, Level 16, State 15, Line 1报错信息，则一般说明要么是MDF数据文件头因此磁盘故障发生了损坏，要么是受到计算机病毒或勒索软件攻击导致MDF内容中部分数据被加密。

例如下面的报错信息：

 

1> alter database testn1 set emergency;
2> go
Msg 5172, Level 16, State 15, Server DESKTOP-L414PA5\SQLEXPRESS, Line 1
The header for file ‘E:\Program Files\Microsoft SQL Server\MSSQL14.SQLEXPRESS\MSSQL\DATA\testn1.mdf’ is not a valid database file header. The PageAudit property is incorrect.

 

可以使用如下的命令来检查MDF文件，当然你也可以利用16进制查看工具例如WINHEX来查看文件头。

 

Syntax:DBCC CHECKPRIMARYFILE ({'PhysicalFileName'} [,opt={0|1|2|3}])

PhysicalFileName is the full path for the primary database file.

opt=0 - checks if the file a primary database file. 
opt=1 - returns name, size, maxsize, status and path of all files associated to the database.
opt=2 - returns the database name, version and collation.
opt=3 - returns name, status and path of all files associated with the database.


CHECKPRIMARYFILE 可以被用来检查文件是否是一个主要数据库文件，并返回相关的信息，其中opt=0 用来判断这是不是一个MDF数据文件

2> DBCC CHECKPRIMARYFILE(N'E:\Program Files\Microsoft SQL Server\MSSQL14.SQLEXPRESS\MSSQL\DATA\bak3\xmltest.mdf',0);
3> go
IsMDF
-----------
          1

(1 rows affected)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
1>
2>
3> DBCC CHECKPRIMARYFILE(N'E:\Program Files\Microsoft SQL Server\MSSQL14.SQLEXPRESS\MSSQL\DATA\bak3\testn1.mdf',0);
4> go
IsMDF
-----------
          0

(1 rows affected)
DBCC execution completed. If DBCC printed error messages, contact your system administrator.  

 

 

返回1说明是MDF数据文件，而返回0说明不是MDF数据文件。

 

对于真的被勒索病毒破坏加密的数据文件头，主要有3种对应措施:

1、若破坏的文件头内容不多的话，可以通过重建文件头修复

2、如果破坏的勒索病毒使用了已知的加密密钥，则可以通过找到对应密钥来解密，可以访问id-ransomware和nomoreransom来获得一些信息。

3、如果以上2个方案都不行，可以考虑使用DBRECOVER FOR SQL SERVER工具来恢复数据。

 

Filed Under: MSSQL SQL SERVER

SQL Server的Msg 945, Level 14, State 2报错

2016/02/27 by Leave a Comment

如果自己搞不定可以找诗檀软件专业SQL SERVER数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com

 

 

Msg 945, Level 14, State 2, Server DESKTOP-L414PA5\SQLEXPRESS, Line 2
Database 'testn1' cannot be opened due to inaccessible files or insufficient memory or disk space.  See the SQL Server errorlog for details.

 

微软官方对该错误的解释是数据库文件或资源不可访问。
Product Name SQL Server
Event ID 945
Event Source MSSQLSERVER
Component SQLEngine
Symbolic Name DB_IS_SHUTDOWN
Message Text Database ‘%.*ls’ cannot be opened due to inaccessible files or insufficient memory or disk space. See the SQL Server error log for details.

 

该945报错发生在当SQL SERVER数据库标记某个数据库为IsShutDown状态。“database cannot be opened due to inaccessible files”错误信息也可以发生在SQL数据库因为缺失文件或资源、或备份发生损坏、或数据库处于置疑状态从而无法恢复的场景。

建议用户检查内存、磁盘空间和权限是否存在问题。确认MDF和NDF文件位置，且数据库引擎有权限访问这些文件。若都无问题，则执行ALTER DATABASE [数据库名] set ONLINE 操作，让数据库上线。

注意该问题也可能由于数据文件损坏导致，对于这种情况要么使用备份恢复，要么需要使用特殊工具恢复。

 

  • 修复SQL SERVER数据库的945错误
  • 若可能则增加更多的磁盘空间给数据库，或删除磁盘上不必要的文件
  • 检查数据库是否处于自动扩展状态
  • 检查操作系统账号是否有必要的权限
  • 检查MDF、NDF和LDF文件不是处于只读状态

 

若你的数据库处于置疑状态，并出现如下报错信息：

SQL Error 926 severity 14
Database '%.*ls' cannot be opened. It has been marked SUSPECT by recovery. See the SQL Server errorlog for more information.

SQL SERVER的926报错发生在当附加或卸载MDF文件时，且该MDF文件存在问题从而导致恢复工作无法正常完成，以便将数据库恢复到一致状态。不当的关闭数据库和计算机病毒攻击均可能引起该问题。

 

Filed Under: MSSQL SQL SERVER

SQL SERVER中DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS选项介绍

2016/02/27 by Leave a Comment

如果自己搞不定可以找诗檀软件专业SQL SERVER数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com

 

DBCC CHECKDB 命令用以检测数据库中所有对象的物理和逻辑完整性，其包含如下操作

 

  • 对数据库运行DBCC CHECKALLOC
  • 对数据库运行DBCC CHECKTABLE检测数据库中的每一张表和视图
  • 对数据库运行DBCC CHECKCATALOG
  • 验证每个INDEXED VIEW的内容
  • 验证使用FILESTREAM存放有varbinary(max)数据的文件系统目录和表的元数据之间的连接一致性
  • 验证数据库中的Service Broker数据

 

语法如下：

DBCC CHECKDB     
    [ ( database_name | database_id | 0    
        [ , NOINDEX     
        | , { REPAIR_ALLOW_DATA_LOSS | REPAIR_FAST | REPAIR_REBUILD } ]    
    ) ]    
    [ WITH     
        {    
            [ ALL_ERRORMSGS ]    
            [ , EXTENDED_LOGICAL_CHECKS ]     
            [ , NO_INFOMSGS ]    
            [ , TABLOCK ]    
            [ , ESTIMATEONLY ]    
            [ , { PHYSICAL_ONLY | DATA_PURITY } ]    
            [ , MAXDOP  = number_of_processors ]    
        }    
    ]    
]

 

 

REPAIR_ALLOW_DATA_LOSS 选项会让CHECKDB命令尝试修复所有检查出的错误。这些修复可能导致丢失数据：

REPAIR_ALLOW_DATA_LOSS选项是被SQL SERVER官方支持的特性，但使用该特性可能导致数据丢失或不一致。官方推荐在有备份的情况下，优先使用备份恢复数据。

微软官方总是建议用户从一个已知可用的备份中恢复数据，这是针对DBCC CHECKDB出现错误后的主流应对方法。REPAIR_ALLOW_DATA_LOSS选项仅在无任何有效备份的情况下考虑使用。对于特定的错误，可能只用使用REPAIR_ALLOW_DATA_LOSS选项修复；例如清除部分行、数据页来解决问题。对于这些被清除的数据而言，用户无法再访问它们，也不再可能恢复，用户可能也搞不清楚丢了哪些数据。因此，参考约束可能在这些清除后变得不准确，典型的情况是外键可能不再启用或维护。当使用REPAIR_ALLOW_DATA_LOSS后，用户需要自行人工去检查这些外键。

 

在做修复前，建议先对数据文件做备份。包括主要数据文件.mdf,二级数据文件.ndf和所有的日志文件.ldf，以及其他文件包括full text catalog,文件流目录，内存优化数据等。

 

在做具体修复前，建议将数据库置入EMERGENCY模式，并在该模式下对重要的表数据做抽取保存。

Filed Under: MSSQL SQL SERVER

如何修复SQL SERVER置疑数据库

2016/02/27 by Leave a Comment

如果自己搞不定可以找诗檀软件专业SQL SERVER数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com

 

若用户没有任何有效的备份，则唯一可行的恢复措施是将数据库置入紧急模式EMERGENCY MODE。这样让用户可以访问数据库，但是需要注意的是所需要做的恢复并没有被完成，所以数据库中可以被读取的内容可能是行级别不一致的，也可能是结构不一致的。下面使用EMERGENCY MODE修复数据库。即先后将数据库置入EMERGENCY和SINGLE_USER模式。

 

ALTER DATABASE [数据库名] SET EMERGENCY;

GO

ALTER DATABASE [数据库名]   SET SINGLE_USER;

GO

DBCC CHECKDB(N’数据库名’,REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS,ALL_ERRORMSGS;

 

Msg 5172, Level 16, State 15, Line 1

The header for file ‘C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\DemoSuspect_log.LDF’ is not a valid database file header. The PageAudit property is incorrect.

File activation failure. The physical file name “C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\DemoSuspect_log.LDF” may be incorrect.

The log cannot be rebuilt because there were open transactions/users when the database was shutdown, no checkpoint occurred to the database, or the database was read-only. This error could occur if the transaction log file was manually deleted or lost due to a hardware or environment failure.

The Service Broker in database “DemoSuspect” will be disabled because the Service Broker GUID in the database (B72D1765-80C6-4C2F-8C12-5B78DAA2DA83) does not match the one in sys.databases (001AE95A-AE22-468F-93A4-C813F4A9112D).

Warning: The log for database ‘DemoSuspect’ has been rebuilt. Transactional consistency has been lost. The RESTORE chain was broken, and the server no longer has context on the previous log files, so you will need to know what they were. You should run DBCC CHECKDB to validate physical consistency. The database has been put in dbo-only mode. When you are ready to make the database available for use, you will need to reset database options and delete any extra log files.

 

可能出现如上报错。该操作会尝试首先做常规的ATTACH_REBUILD_LOG操作。当此操作失败，DBCC CHECKDB接手并尝试从被损坏的日志中尽可能做恢复操作，然后强制重建日志。后续会运行一个全库修复，检测全库中的损坏存在。

注意在上面的例子中因为SERVICE Broker GUID是有问题的。所以需要耍个花招新建一个同名的空数据库，该操作会在MASTER.SYS.DATABASES中创建对应的记录。

 

可以使用如下语句来重设GUID:

ALTER DATABASE XXX SET NEW_BROKER WITH ROLLBACK IMMEDIATE

 

Filed Under: MSSQL SQL SERVER

SQL Server中的sp_resetstatus

2016/02/26 by Leave a Comment

如果自己搞不定可以找诗檀软件专业SQL SERVER数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com

 

sp_resetstatus 这个系统存储过程用以重置数据库的置疑（suspect ）状态。语法是：

sp_resetstatus [ @dbname = ] ‘database’

 

sp_resetstatus用来将数据库的置疑状态位重置，其更新sys.databases中的系统字典记录。官方推荐在错误日志中的信息被充分考虑的情况下才去做这个操作。同时建议在执行sp_resetstatus后重启SQL SERVER服务实例。

一个数据库进入置疑状态的原因可能有很多；例如数据库原本能够访问的操作系统资源突然变得不可用，或者数据库MDF文件出现讹误等。

以下是一个例子: EXEC sp_resetstatus ‘AdventureWorks2012’;

在SYBASE的文档中记录了该存储过程的代码，有理由相信SQL SERVER中其代码的主体作用应当是相似的：

 

CREATE PROC sp_resetstatus @dbname varchar(30) AS
DECLARE @msg varchar(80)
IF @@trancount > 0
    BEGIN
      PRINT "Can't run sp_resetstatus from within a transaction."
      RETURN (1)
    END
IF suser_id() != 1
    BEGIN
     SELECT @msg =  "You must be the System Administrator (SA)"
     SELECT @msg = @msg + " to execute this procedure."
     PRINT @msg
     RETURN (1)
    END
IF (SELECT COUNT(*) FROM master..sysdatabases
     WHERE name = @dbname) != 1
    BEGIN
     SELECT @msg = "Database '" + @dbname + "' does not exist!"
     PRINT @msg
     RETURN (1)
    END
IF (SELECT COUNT(*) FROM master..sysdatabases
     WHERE name = @dbname AND status & 256 = 256) != 1
   BEGIN
      PRINT "sp_resetstatus may only be run on suspect databases."
      RETURN (1)
    END
BEGIN TRAN
   UPDATE master..sysdatabases SET status = status - 320
     WHERE name = @dbname
   IF @@error != 0 OR @@rowcount != 1
     ROLLBACK TRAN
   ELSE 
       BEGIN
         COMMIT TRAN
         SELECT @msg = "Database '" + @dbname + "' status reset!"
         PRINT @msg
         PRINT " " 
         PRINT "WARNING: You must reboot Adaptive Server prior to  "
         PRINT "          accessing this database!"
         PRINT " "
       END

 

 

Filed Under: MSSQL SQL SERVER

Oracle Grid Infrastructure HAIP原理

2016/02/24 by Leave a Comment

11.2.0.2 开始Grid infrastructure引入新功能HAIP，对应资源ora.cluster_interconnect.haip用于私有网络通信。详细信息请您查看：Grid Infrastructure Redundant Interconnect and ora.cluster_interconnect.haip ( Doc ID 1210883.1 )

GRID集群安装时，发送ARP probe/announce用于检测是否存在重复的HAIP地址，如果存在重复的HAIP地址，那么新的GRID集群分配新的HAIP地址，避免HAIP地址冲突。

根据ORACLE最近实践， 建议每个集群GRID的私有网络(interconnect network)使用单独交换机或者单独的vlan，在这样的环境下，是不会出现HAIP冲突的情况。

另外，如果出现您描述的现象，将测试环境grid集群迁移到生产环境下，即在一个单独交换机或者单独的vlan下存在多套集群的情况下，我们建议在迁移前检查网络IP地址是否有冲突，包括HAIP地址。

如果不同的集群GRID中有重复的HAIP地址，我们建议将其中一套RAC 重新配置(deconfig/reconfig GRID)，这样可以使grid集群生成新的HAIP地址，或者不同的集群grid位于不同的vlan，避免冲突。

Filed Under: Oracle

【MySQL学生手册】表维护中的客户端工具程序

2016/02/24 by Leave a Comment

本文地址：https://www.askmac.cn/archives/mysql-maintenance-tools.html

 

10.3 表维护中的客户端工具程序

之前讨论的表维护SQL语句可以在mysql客户端工具执行，也可以通过其它应用发送给服务端来执行。通过使用这些语句，你可以写一些自己的管理应用程序来进行表的检查和修理操作。

 

一些MySQL客户端程序作为前端可发出表维护命令：

  • MySQL Workbench提供了执行语句的编辑窗口可用于进行表检查，修理和优化操作。当你执行这些操作时，语句会被发至服务端。
  • mysqlcheck可用于检查，维修，分析和优化表。此命令行工具按所提供的命令项来决定发送哪些相适合的SQL语句到MySQL服务端以进行所需操作。

对于MyISAM表，使用myisamchk工具也能进行表维护。然而，它不同于MySQL Workbench和mysqlcheck需要将SQL语句发送到服务端，myisamchk可直接读取并修改表文件。也因为此，请保证在使用myisamchk的同时服务端不会去访问这些表。

 

10.3.1 mysqlcheck客户端程序

mysqlcheck可对表进行的操作有检查，修理，分析和优化。对于MyISAM表，此程序工具可执行所有这些操作，而对于InnoDB表，则只能执行一部分操作。它提供了一种命令行接口方式来执行各种SQL语句（如CHECK TABLE和REPAIR TABLE）以告知服务端进行何种表维护。

 

mysqlcheck在某些情况下比起直接执行SQL语句，可以使得操作变得更容易。例如，如果你指定一个数据库，它包含了需要执行语句来处理的所有表。使用mysqlcheck你就不需要在进行操作时显式地指定每个表，而且，mysqlcheck是一个命令行程序，它可以在工作中被用于周期性计划维护作业。

[Read more…]

Filed Under: MYSQL

【数据恢复】ORA-00600 [4194], [21], [25] Oracle数据库恢复案例

2016/02/24 by Leave a Comment

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 ： 13764045638   QQ号:47079569    邮箱：service@parnassusdata.com

 

某军工动力技术公司Oracle数据库出现启动故障，诗檀软件工程师 王工在分析后在2个小时内完成了数据库恢复：

1 环境

数据库版本：10.2.0.1
操作系统：windows2003 64位
数据库实例名：ORCL

 

1.2 技术分析

 

数据库于2017年某星期一，发生断电，导致数据库启动时报错ORA-00600: internal error code, arguments: [4194], [21], [25], [], [], [], [], []。 详情如下：

 

Thu XXXX 14:25:58 2017
ORACLE V10.2.0.1.0 - Production vsnsta=0
vsnsql=14 vsnxtr=3
Windows NT Version V5.2 Service Pack 2
CPU                 : 4 - type 586, 1 Physical Cores
Process Affinity    : 0x00000000
Memory (Avail/Total): Ph:3475M/4095M, Ph+PgF:5490M/5977M, VA:1927M/2047M
Thu XXXX 14:25:58 2017
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Picked latch-free SCN scheme 2
Using LOG_ARCHIVE_DEST_10 parameter default value as USE_DB_RECOVERY_FILE_DEST
Autotune of undo retention is turned on.
IMODE=BR
ILAT =18
LICENSE_MAX_USERS = 0
SYS auditing is disabled
ksdpec: called for event 13740 prior to event group initialization
Starting up ORACLE RDBMS Version: 10.2.0.1.0.
System parameters with non-default values:
processes                = 150
event                    = 10231 trace name context forever,level 10
__shared_pool_size       = 96468992
__large_pool_size        = 4194304
__java_pool_size         = 4194304
__streams_pool_size      = 0
spfile                   = E:\ORACLE\PRODUCT\10.2.0\DB_1\DATABASE\SPFILEORCL.ORA
sga_target               = 612368384
control_files            = E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL01.CTL, E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL02.CTL, E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\CONTROL03.CTL
db_block_size            = 8192
__db_cache_size          = 499122176
compatible               = 10.2.0.1.0
db_file_multiblock_read_count= 16
db_recovery_file_dest    = E:\oracle\product\10.2.0/flash_recovery_area
db_recovery_file_dest_size= 2147483648
undo_management          = AUTO
undo_tablespace          = UNDOTBS1
remote_login_passwordfile= EXCLUSIVE
db_domain                =
dispatchers              = (PROTOCOL=TCP) (SERVICE=orclXDB)
job_queue_processes      = 10
audit_file_dest          = E:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\ADUMP
background_dump_dest     = E:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\BDUMP
user_dump_dest           = E:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\UDUMP
core_dump_dest           = E:\ORACLE\PRODUCT\10.2.0\ADMIN\ORCL\CDUMP
db_name                  = orcl
open_cursors             = 300
pga_aggregate_target     = 203423744
MMAN started with pid=4, OS id=2692
PMON started with pid=2, OS id=2684
PSP0 started with pid=3, OS id=2688
DBW0 started with pid=5, OS id=2696
LGWR started with pid=6, OS id=2700
CKPT started with pid=7, OS id=2704
SMON started with pid=8, OS id=2708
RECO started with pid=9, OS id=2712
CJQ0 started with pid=10, OS id=2716
MMON started with pid=11, OS id=2720
Thu XXXX 14:26:03 2017
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
MMNL started with pid=12, OS id=2724
Thu XXXX 14:26:03 2017
starting up 1 shared server(s) ...
Thu XXXX 14:26:04 2017
alter database mount exclusive
Thu XXXX 14:26:09 2017
Setting recovery target incarnation to 3
Thu XXXX 14:26:09 2017
Successful mount of redo thread 1, with mount id 1464551420
Thu XXXX 14:26:09 2017
Database mounted in Exclusive Mode
Completed: alter database mount exclusive
Thu XXXX 14:26:09 2017
alter database open
Thu XXXX 14:26:09 2017
Beginning crash recovery of 1 threads
parallel recovery started with 3 processes
Thu XXXX 14:26:10 2017
Started redo scan
Thu XXXX 14:26:10 2017
Completed redo scan
1008 redo blocks read, 103 data blocks need recovery
Thu XXXX 14:26:10 2017
Started redo application at
Thread 1: logseq 17, block 76
Thu XXXX 14:26:10 2017
Recovery of Online Redo Log: Thread 1 Group 2 Seq 17 Reading mem 0
Mem# 0 errs 0: E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO02.LOG
Thu XXXX 14:26:10 2017
Completed redo application
Thu XXXX 14:26:10 2017
Completed crash recovery at
Thread 1: logseq 17, block 1084, scn 305721697
103 data blocks read, 103 data blocks written, 1008 redo blocks read
Thu XXXX 14:26:11 2017
Thread 1 advanced to log sequence 18
Thread 1 opened at log sequence 18
Current log# 3 seq# 18 mem# 0: E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03.LOG
Successful open of redo thread 1
Thu XXXX 14:26:11 2017
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
Thu XXXX 14:26:11 2017
SMON: enabling cache recovery
Thu XXXX 14:26:15 2017
Successfully onlined Undo Tablespace 1.
Thu XXXX 14:26:15 2017
SMON: enabling tx recovery
Thu XXXX 14:26:15 2017
Database Characterset is ZHS16GBK
replication_dependency_tracking turned off (no async multimaster replication found)
Starting background process QMNC
QMNC started with pid=19, OS id=2860
Thu XXXX 14:26:25 2017
Errors in file e:\oracle\product\10.2.0\admin\orcl\udump\orcl_ora_2744.trc:
ORA-00600: 内部错误代码, 参数: [4194], [21], [25], [], [], [], [], []

Thu XXXX 14:26:27 2017
db_recovery_file_dest_size of 2048 MB is 0.66% used. This is a
user-specified limit on the amount of space that will be used by this
database for recovery-related files, and does not reflect the amount of
space available in the underlying filesystem or ASM diskgroup.
Thu XXXX 14:26:29 2017
ORA-607 signalled during: alter database open...
Doing block recovery for file 2 block 483
Block recovery from logseq 18, block 75 to scn 305721829
Thu XXXX 14:26:29 2017
Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_smon_2708.trc:
ORA-00600: internal error code, arguments: [4194], [33], [40], [], [], [], [], []

Thu XXXX 14:26:29 2017
Recovery of Online Redo Log: Thread 1 Group 3 Seq 18 Reading mem 0
Mem# 0 errs 0: E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03.LOG
Block recovery stopped at EOT rba 18.78.16
Block recovery completed at rba 18.78.16, scn 0.305721829
Doing block recovery for file 2 block 25
Block recovery from logseq 18, block 75 to scn 305721825
Thu XXXX 14:26:29 2017
Recovery of Online Redo Log: Thread 1 Group 3 Seq 18 Reading mem 0
Mem# 0 errs 0: E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03.LOG
Block recovery completed at rba 18.76.16, scn 0.305721828
Thu XXXX 14:26:30 2017
Doing block recovery for file 2 block 12
Block recovery from logseq 18, block 76 to scn 305721831
Thu XXXX 14:26:30 2017
Recovery of Online Redo Log: Thread 1 Group 3 Seq 18 Reading mem 0
Mem# 0 errs 0: E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03.LOG
Block recovery stopped at EOT rba 18.78.16
Block recovery completed at rba 18.78.16, scn 0.305721829
Doing block recovery for file 2 block 9
Block recovery from logseq 18, block 76 to scn 305721828
Thu XXXX 14:26:30 2017
Recovery of Online Redo Log: Thread 1 Group 3 Seq 18 Reading mem 0
Mem# 0 errs 0: E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03.LOG
Block recovery completed at rba 18.78.16, scn 0.305721829
Thu XXXX 14:26:31 2017
Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_smon_2708.trc:
ORA-01595: error freeing extent (2) of rollback segment (1))
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [4194], [33], [40], [], [], [], [], []

Thu XXXX 14:31:33 2017
Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_smon_2708.trc:
ORA-00600: internal error code, arguments: [4194], [34], [27], [], [], [], [], []

Thu XXXX 14:31:33 2017
Doing block recovery for file 2 block 2130
Block recovery from logseq 18, block 280 to scn 305721962
Thu XXXX 14:31:33 2017
Recovery of Online Redo Log: Thread 1 Group 3 Seq 18 Reading mem 0
Mem# 0 errs 0: E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03.LOG
Block recovery stopped at EOT rba 18.285.16
Block recovery completed at rba 18.285.16, scn 0.305721962
Doing block recovery for file 2 block 73
Block recovery from logseq 18, block 280 to scn 305721960
Thu XXXX 14:31:34 2017
Recovery of Online Redo Log: Thread 1 Group 3 Seq 18 Reading mem 0
Mem# 0 errs 0: E:\ORACLE\PRODUCT\10.2.0\ORADATA\ORCL\REDO03.LOG
Block recovery completed at rba 18.284.16, scn 0.305721961
Thu XXXX 14:31:34 2017
Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_smon_2708.trc:
ORA-00604: error occurred at recursive SQL level 1
ORA-00607: Internal error occurred while making a change to a data block
ORA-00600: internal error code, arguments: [4194], [34], [27], [], [], [], [], []

Thu XXXX 14:33:20 2017
Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_mmon_2720.trc:
ORA-00600: internal error code, arguments: [4194], [21], [25], [], [], [], [], []

Thu XXXX 14:33:21 2017
Flush retried for xcb 0x3338fd24, pmd 0x32844c24
Doing block recovery for file 2 block 483
No block recovery was needed
Thu XXXX 14:33:21 2017
Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_mmon_2720.trc:
ORA-00600: internal error code, arguments: [4194], [21], [25], [], [], [], [], []
ORA-00600: internal error code, arguments: [4194], [21], [25], [], [], [], [], []

Thu XXXX 14:34:24 2017
Flush retried for xcb 0x3338fd24, pmd 0x32844c24
Doing block recovery for file 2 block 483
No block recovery was needed
Thu XXXX 14:34:25 2017
Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_pmon_2684.trc:
ORA-00600: internal error code, arguments: [4194], [21], [25], [], [], [], [], []

Thu XXXX 14:34:25 2017
Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_pmon_2684.trc:
ORA-00600: internal error code, arguments: [4194], [21], [25], [], [], [], [], []

PMON: terminating instance due to error 472
Thu XXXX 14:34:25 2017
Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_q001_3268.trc:
ORA-00472: PMON  process terminated with error

Thu XXXX 14:34:26 2017
Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_reco_2712.trc:
ORA-00472: PMON  process terminated with error

Thu XXXX 14:34:26 2017
Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_smon_2708.trc:
ORA-00472: PMON  process terminated with error

Thu XXXX 14:34:26 2017
Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_ckpt_2704.trc:
ORA-00472: PMON  process terminated with error

Thu XXXX 14:34:26 2017
Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_lgwr_2700.trc:
ORA-00472: PMON  process terminated with error

Thu XXXX 14:34:26 2017
Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_dbw0_2696.trc:
ORA-00472: PMON  process terminated with error

Thu XXXX 14:34:27 2017
Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_mman_2692.trc:
ORA-00472: PMON  process terminated with error

Thu XXXX 14:34:27 2017
Errors in file e:\oracle\product\10.2.0\admin\orcl\bdump\orcl_psp0_2688.trc:
ORA-00472: PMON  process terminated with error

Instance terminated by PMON, pid = 2684

 

 

 

错误分析：
ORA-00600[4194]错误的根本原因是 redo记录与回滚段(rollback/undo)记录之间的不一致。当ORACLE在验证undo记录时相对应的变化需要应用到undo数据块的最大undo记录上，此时若检验出错则会报ORA-00600[4194]

Filed Under: Oracle

PRM-DUL Works on Oracle 12c

2016/02/23 by Leave a Comment

PRM-DUL Works on Oracle 12c

prm works on oracle 12c

Filed Under: Oracle

沪ICP备14014813号-2

沪公网安备 31010802001379号