XKCCDIDUMPVDATABASE进行对应

本文涉及的产品
云解析 DNS,旗舰版 1个月
全局流量管理 GTM,标准版 1个月
公共DNS(含HTTPDNS解析),每月1000万次HTTP解析
简介: XKCCDIDUMPCONTROLFILEVDATABASE基本来自于此FIXED TABLE,为了能够更好的备查今记录于此 数据库信息 TRACE文件 (size = 316, compat size = 316,...
XKCCDIDUMPCONTROLFILEVDATABASE基本来自于此FIXED TABLE,为了能够更好的备查今记录于此

数据库信息 TRACE文件
(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)
 10/04/2013 22:10:43
 DB Name "XUEXI"
 Database flags = 0x00404001 0x00001000
 Controlfile Creation Timestamp  10/04/2013 22:10:44
 Incmplt recovery scn: 0x0000.00000000
 Resetlogs scn: 0x0000.001d599f Resetlogs Timestamp  10/04/2013 22:14:48
 Prior resetlogs scn: 0x0000.001d494d Prior resetlogs Timestamp  10/04/2013 21:54:38
 Redo Version: compatible=0xa200100
 #Data files = 10, #Online files = 10
 Database checkpoint: Thread=1 scn: 0x0000.0085102b
 Threads: #Enabled=1, #Open=1, Head=1, Tail=1
 enabled  threads:  01000000..00000000
 Max log members = 3, Max data members = 1
 Arch list: Head=5, Tail=5, Force scn: 0x0000.008173ca scn: 0x0000.0085102a
 Activation ID: 2190560931
 Controlfile Checkpointed at scn:  0x0000.00851068 02/25/2015 19:45:02
 thread:0 rba:(0x0.0.0)
 enabled  threads:  00000000..00000000
 


XKCCDIINSTIDIDDICTS10/04/201322:10:43,VDATABASE定义应该是数据库的建立时间他和VDATABASECREATEDDIDBNDBName"XUEXI",vdatabase的name                                                                                    
 DICCT    控制文件建立时间对应 Controlfile Creation Timestamp  10/04/2013 22:10:44                                         
 DIFLG    对应Database flags = 0x00404001转换为10进制为4210689,这是一个重要的状态位,VDATABASEbitandSTANDBYCURRENTSTANDBYDIRLSResetlogsscn:0x0000.001d599f,10VDATABASE RESETLOGS_CHANGE#                                         
 DIRLC    对应Resetlogs Timestamp  10/04/2013 22:14:48,对应VDATABASERESETLOGSTIMEDIRLCIRESETLOGSIDDIPRSPriorresetlogsscn:0x0000.001d494d,10,VDATABASE PRIOR_RESETLOGS_CHANGE#                                       
 DIPRC    对应Prior resetlogs Timestamp  10/04/2013 21:54:38 ,对应VDATABASE PRIOR_RESETLOGS_TIME                                       
   DIPRC_I  是上一次的RESETLOGS_ID                                                                                  
   DINDF    应该是#Data files = 10                                         
   DINTF    应该是Threads: #Enabled=1   为1表示Enabled thread bitmap vector                                    
   DINOF    应该是#Online files = 10                                         
   DICPT    应该是Database checkpoint: Thread=1                                         
   DISCN    对应了Database checkpoint scn: 0x0000.0085102b,就是LOW CACHE RBA对应的SCN,正常情况下这以前的数据是干净的,他就是V
DATABASE的CHECKPOINT_CHANGE#                                                                                                                                                                             
 DIMLM    对应了Max log members = 3,这实际上是MAXLOGMEMBERS 
 DIMDM    对应了Max data members = 1 恒等于1   (A structural hook to allow for duplexing datafiles, not implemented)                                         
 DIARH    对应了Arch list: Head=5 不知道意义                                        
 DIART    对应了Tail=5  不知道意义                                                                                   
 DIFAS    对应了Force scn: 0x0000.008173ca,对应vdatabase中的ARCHIVE_CHANGE# (Database force archiving SCN. 
            Any redo log with a start SCN below this will be forced to archive out.)                                        
   DICKP_SCN  对应了Controlfile Checkpointed at scn:  0x0000.00851068,对应v
database中controlfile_change#                                       
 DICKP_TIM  对应了02/25/2015 19:45:02 ,对应了VDATABASE中CONTROLFILE_TIME                                      
   DICSQ      对应了CONTROLFILE HEADER的DUMP OF CONTROL FILES, Seq # 9156 = 0x23c4,对应V
DATABASE中的controlfile_sequence#
            (The control file sequence number at the time ofthe last control fileupdate of the file 
             header. This is used to check for an old control file. If the number in a data file is 
             higher than the current control file, then the control file must bea backup or have a 
             different resetlogs stamp)                                      
 DIDBI       对应了CONTROLFILE HEADER的Db ID=2183744397=0x82294b8d,就是数据库的ID对应VDATABASEDBIDDIVTSVDATABASE中的VERSION TIME                                                                                 
 DIDOR       通过换算得到VDATABASEopenmodedecode(di.didor,0,MOUNTED,decode(di.didor,1,READWRITE,READONLY))DIRAEVDATABASE中的REMOTE_ARCHIVE decode(di.dirae,0,'DISABLED',1,'SEND',2,'RECEIVE',3,'ENABLED','UNKNOWN')                                                                              
 DIARS       对应VDATABASE中的ARCHIVELOG_CHANGE# (Highest NEXT_CHANGE#(from the VARCHIVED_LOGview) for an archive log)                                    
 DISOS       通过换算得到VDATABASEswitchoverstatusdecode(di.disos,0,IMPOSSIBLE,1,NOTALLOWED,2,SWITCHOVERLATENT,3,SWITCHOVERPENDING,4,TOPRIMARY,5,TOSTANDBY,6,RECOVERYNEEDED,7,SESSIONSACTIVE,8,PREPARINGSWITCHOVER,9,PREPARINGDICTIONARY,10,TOLOGICALSTANDBY,UNKNOWN),DIDGDVDATABASE中的dataguard_blocker decode(di.didgd, 0, 'DISABLED', 'ENABLED')                                                                                                                              
 DIFL2       通过换算得到VDATABASESUPPLEMENTALLOGDATAALLdecode(bitand(difl2,2),2,YES,NO)DIPLIDVDATABASE的LAST_OPEN_INCARNATION# Record number of the incarnation in VDATABASEINCARNATIONthatwaslastopenedsuccessfullyDIPLNVDATABASE的PLATFORM_ID,这是平台ID,通过vtransportableplatformDICURSCNVDATABASE的CURRENT_SCN,没什么说的当前SCN                                      
 DIDBUN      对应了VDATABASEUNIQUENAMEDATAGUARDDIFSTSVDATABASE中的FS_FAILOVER_STATUS
 
由此发现很多字段实际都对应了VDATABASESCNselectDISCN,DIFAS,DIARS,DICKPSCN,DICURSCNfromxkccdi;
等价于
select CHECKPOINT_CHANGE#,ARCHIVE_CHANGE#,ARCHIVELOG_CHANGE#,controlfile_change#,CURRENT_SCN from vdatabase;selecttonumber(DISCN),tonumber(DIFAS),tonumber(DIARS),tonumber(DICKPSCN),tonumber(DICURSCN)fromxkccdi
union all
select CHECKPOINT_CHANGE#,ARCHIVE_CHANGE#,ARCHIVELOG_CHANGE#,controlfile_change#,CURRENT_SCN from v$database; 
语句进行比较
目录
打赏
0
0
0
0
91
分享
相关文章
智能文件解析:体验阿里云多模态信息提取解决方案
在当今数据驱动的时代,信息的获取和处理效率直接影响着企业决策的速度和质量。然而,面对日益多样化的文件格式(文本、图像、音频、视频),传统的处理方法显然已经无法满足需求。
111 4
智能文件解析:体验阿里云多模态信息提取解决方案
多模态数据信息提取解决方案评测报告!
阿里云推出的《多模态数据信息提取》解决方案,利用AI技术从文本、图像、音频和视频中提取关键信息,支持多种应用场景,大幅提升数据处理效率。评测涵盖部署体验、文档清晰度、模板简化、示例验证及需求适配性等方面。方案表现出色,部署简单直观,功能强大,适合多种业务场景。建议增加交互提示、多语言支持及优化OCR和音频转写功能...
122 3
多模态数据信息提取解决方案评测报告!
深入解析BeautifulSoup:从sohu.com视频页面提取关键信息的实战技巧
深入解析BeautifulSoup:从sohu.com视频页面提取关键信息的实战技巧
从数据提取到管理:合合信息的智能文档处理全方位解析【合合信息智能文档处理百宝箱】
合合信息的智能文档处理“百宝箱”涵盖文档解析、向量化模型、测评工具等,解决了复杂文档解析、大模型问答幻觉、文档解析效果评估、知识库搭建、多语言文档翻译等问题。通过可视化解析工具 TextIn ParseX、向量化模型 acge-embedding 和文档解析测评工具 markdown_tester,百宝箱提升了文档处理的效率和精确度,适用于多种文档格式和语言环境,助力企业实现高效的信息管理和业务支持。
4216 5
从数据提取到管理:合合信息的智能文档处理全方位解析【合合信息智能文档处理百宝箱】
信息论、机器学习的核心概念:熵、KL散度、JS散度和Renyi散度的深度解析及应用
在信息论、机器学习和统计学领域中,KL散度(Kullback-Leibler散度)是量化概率分布差异的关键概念。本文深入探讨了KL散度及其相关概念,包括Jensen-Shannon散度和Renyi散度。KL散度用于衡量两个概率分布之间的差异,而Jensen-Shannon散度则提供了一种对称的度量方式。Renyi散度通过可调参数α,提供了更灵活的散度度量。这些概念不仅在理论研究中至关重要,在实际应用中也广泛用于数据压缩、变分自编码器、强化学习等领域。通过分析电子商务中的数据漂移实例,展示了这些散度指标在捕捉数据分布变化方面的独特优势,为企业提供了数据驱动的决策支持。
415 2
信息论、机器学习的核心概念:熵、KL散度、JS散度和Renyi散度的深度解析及应用
拿下奇怪的前端报错(一):报错信息是一个看不懂的数字数组Buffer(475) [Uint8Array],让AI大模型帮忙解析
本文介绍了前端开发中遇到的奇怪报错问题,特别是当错误信息不明确时的处理方法。作者分享了自己通过还原代码、试错等方式解决问题的经验,并以一个Vue3+TypeScript项目的构建失败为例,详细解析了如何从错误信息中定位问题,最终通过解读错误信息中的ASCII码找到了具体的错误文件。文章强调了基础知识的重要性,并鼓励读者遇到类似问题时不要慌张,耐心分析。
104 5
【初阶数据结构】掌握二叉树遍历技巧与信息求解:深入解析四种遍历方法及树的结构与统计分析
【初阶数据结构】掌握二叉树遍历技巧与信息求解:深入解析四种遍历方法及树的结构与统计分析
yolov5的train.py的参数信息解析
这篇文章解析了YOLOv5的`train.py`脚本中的参数信息,详细介绍了每个参数的功能和默认值,包括权重路径、模型配置、数据源、超参数、训练轮数、批量大小、图像尺寸、训练选项、设备选择、优化器设置等,以便用户可以根据需要自定义训练过程。
100 0
搭建dns服务常见报错--查看/etc/named.conf没有错误日志信息却显示出错(/etc/named.conf:49: missing ‘;‘ before ‘include‘)及dns介绍
搭建dns服务常见报错--查看/etc/named.conf没有错误日志信息却显示出错(/etc/named.conf:49: missing ‘;‘ before ‘include‘)及dns介绍
298 0
DNS信息收集详解
DNS信息收集详解
242 1

热门文章

最新文章

推荐镜像

更多
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等