技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> Oracle
    以前对Transportable Tablespaces(TTS)一直理解不深,今天无意中看到TTS可以实现数据库升级,今天测试了实现使用TTS 迁移9.2.0.4的一个表空间到11.2.0.3,平台均为Linux 32位
    是不是我们的数据库,加上一套成熟可靠的备份软件(比如NBU、DP、TSM等),以及购置了可靠的大容量的带库就足够了?或者下面一个案例能够给我们一些启示。案例来自于一个老客户,一套重要系统的Oracle RAC数据库,由于硬件问题,一个包含关键业务数据的文件被离线(在归档模式下,写文件出错会导致文件被置为离线状态,而不是库宕掉)。在尝试recover datafile的时候,提示缺少一个归档日志。归档日志已经被备到带库上,本地磁盘上已经没有了这个归档日志文件。这套库是用TSM备份的,使用rman还原归档日志,称找不到这个归档日志。
    rman backup 对于truncate和drop等相关操作的extent到底是怎么处理的,这里通过rman backup 结合odu证明出来,在较新版本的rman中,rman backup 并未完全的备份这些被认为不需要的extent. 创建模拟环境 rman备份no truncate table 数据文件 truncate table 操作 rman备份truncate table 数据文件 odu挖rman备份前数据文件 使用rman 备份后数据文件 odu挖rman还原后数据文件 通过odu挖rman备份前和备份后的数据文件,得知rman backup备份的过程,对绝大多数truncate的表的原始数据未正常备份(为什么是绝大多数,我无法给出解释),这里也可以看出rman backup并非是真正意义上的完全物理上复制(和rman copy还是有区别,copy不能完全被取代)
    一朋友的数据库在做数据库恢复的时候,数据库不能启动到mount状态,检查发现 alert日志错误如下 查询mos发现解释 在非集群环境中,当该数据库已经在一个节点启动,然后另外一个节点再尝试启动数据库可能出现该错误. 检查环境发现是使用roseha的双机环境,当关闭当前节点的数据库时候,另外一个节点认为oracle down掉了,然后自动在该节点去尝试启动数据库,而当前操作节点去尝试mount数据库的时候发生该错误,因为该数据库的另外一个节点已经mount了.出现这样的情况,和朋友的存储资源的配置也有不合理之处,在接管资源之前,应该先分析和处理存储的挂载情况,而不是不卸载这边,另外一遍直接挂载(也就是存储两边都挂载) 解决办法 这个问题的本质就是因为ha的两边都启动了数据库导致,关闭一边的roseha或者关闭主机就可以了
    有不少人对于rman的backup功能,到底备份数据文件的什么级别,一直有着不明确的说法,我这里以10.2.0.4版本的rman backup 测试,进行一个简单的说明.这里提供的是一种思路.如果你在实际工作中,遇到一些rman到底会不会备份相关数据块的时候,可以通过类此的试验来证明你的版本的rman的功能. 模拟环境 备份空数据文件 从这里可以看出来rman备份的时候,数据文件中未格式化的块并没有备份(数据文件10m,备份集只有106k左右,比文件实际使用的65536b稍微大点) 备份create表数据文件 这里可以得出结论,rman的备份集大小可以从一定程度上近似等于数据文件使用空间大小
    本片文章介绍下追踪SQL的另一种方法,使用DBMS_SUPPORT包来追踪SQL。 DBMS_SUPPORT是Oracle为内部人员提供的一个软件包。供内部支持人员使用以更有效地跟踪SQL。馆方文档上没有这个包的说明文件,默认情况下,系统不安装这个包。
    对于oracle的update操作,在数据块中具体是如何出来,是直接更新原来值,还是通过插入新值修改指针的方法实现.下面通过证明: 模拟表插入数据 数据存储对应16进制值 得出第一条记录对应值为:02c10203584646;第二条记录对应值为:02c10303434846 dump 数据块得到记录 bbed查看相关记录 这里可以得到结论如下: 1.数据是从块的底部开始往上存储 2.在每一条记录的头部分别有flag/lock/cols对应这里的2c0102 3.这里的偏移量和dump出来的数据可以看出来两条记录是连续在一起(偏移量分别为:8168和8178) 更新一条记录 我们可以但看到值有XFF改变为XIFENFEI,存储长度变大
    ORACLE接触的久了,我的大脑也开始遵循LRU原则,不常用的知识很快就会被刷新掉,为了和ORACLE一样保证数据一致性,只好将这些东西保存到硬盘上。 前段时间数据已经加载到数据库,最近一直做的是整理这些数据,SUBSTR和REPLACE函数用的比较多, 这里简单记录下。 有一张存放图片的表,包含以下字段,IDENTIFIER是档号,JPG_PATH是图片的路径和名字,其他字段这里没有用到,不做描述。
    一个朋友的数据库在经过自己的千辛万苦终于open成功,但是几分钟就down掉,使得他想导出数据重建库的目标不能实现.让我帮忙处理 alert日志报ORA-00600[kafspa:columnBuffer1] 这里出现ORA-00600[kafspa:columnBuffer1],一个未知的错误,但是根据相关的提示,可以大概猜出来是什么原因导致数据库异常 出现这个错误,使得我们想到一个smon的功能,清理临时段.该数据库down掉很可能和smon清理临时段的过程发生失败有关系 这个错误提示是因为smon内部最多允许发生100次错误,记录错误发生了8次,当然这次数据库down掉是smon还没有达到100次就直接abort掉 分析trace文件 果然是smon在查询type#=3的时候发现异常,出现ORA-00600[25027]错误.通过对seg$相关视图分析,可以知道type#=3表示临时.....
    客户有张大表,在设计的时候是分区表,按全宗号分了77个分区,最近发现对这张表查询速度明显比之前慢了许多,经过分析发现这张表的分区不见啦,变成了普通表,问了看法人员才知道,原来他对这张表做了好多次ALTER TABLE XX RENAME和CREATE TABLE XX AS SELECT *操作,由于CREATE TABLE AS(CTAS)操作只会建立同样的表结构而不会建立分区,导致这张表由分区表变成了普通的堆表,那么就要将这张表再改回分区表,普通表改为分区表的方法很多,但是对于7*24的系统来说,就只能用ORACLE 10g版本推出的新功能-在线重定义了,下面的案例是在虚拟机上做的测试。
    平时只知道不要把非系统用户的表存放到系统表空间,至于为什么,并没有去研究,直到看到kamus(张乐奕)和老熊(熊军)发起的邮件才知道,原来系统对SYSTEM表空间的自动维护会占用CPU资源,如果将普通用户的表存放到系统表空间,效率会下降。
    今天kaums给客户做培训11g新特性,发现还真的有不少挺好的新东西,但是以前没有怎么去关注的他们,在后续的几篇中,陆续整理处理. DDL_LOCK_TIMEOUT specifies a time limit for how long DDL statements will wait in a DML lock queue. The default value of zero indicates a status of NOWAIT. The maximum value of 1,000,000 seconds will result in the DDL statement …
    客户有个需求,一张150多个字段的表,客户要求只将部分字段给扫描公司的人看,这个需求用视图就可以很容易实现,客户又要求,这些字段,扫描公司只可以修改其中的个别字段,我之前还真没遇到这样在列级别做权限控制的需求,做了个实验,感觉很有意思,记录下测试过程。
    在oracle RAC中,每个实例均存在一个数据缓存池,每个block的改变都将实例间进行资源协调以获取最大化性能,从而保证数据的完整性。在RAC集群中,每个被缓存的数据copy,也叫做缓存资源,均存在一个叫做master节点的实例。在10.1.0.2中,一旦一个cache resource被master一个实例节点,对缓存资源的重新remaster或者说master节点的自动改变仅仅会发生在RAC实例节点的正常启停或者集群管理资源间的非正常问题发生。也就是说,如果NODE B是一个缓存资源的master节点,这个资源将被一直master到NODE B直到发生RAC节点的重新配置操作。
    之前也写了一些关于ORACLE11g新特性的文章,现在ORACLE 11g已成为主流的ORACLE数据库版本,了解和学习ORACLE 11g的新特性至关重要,本人也是ORACLE 11g新特性的初学者,在此分享下我的学习过程和心得。 本文主要记录的是ORACLE 11g的一个新特性,允许DDL锁等待DML锁,这也是在6月30日,张乐奕(kamus)老师在ACOUG活动中分享的一个主题。
    在上周六的ACOUG活动中,张乐奕(kamus)老师分享了一个关于ORACLE 11g新特性的主题,本人觉得在10g这个过渡版本已成过去(官网已不提供10g版本的介质下载),12c马上发布,11g已经成熟而有些人还没有开始使用11g的年头,了解11g的新特性还是很有必要的,本文主要和大家一起学习下ORACLE 11g新特性—虚拟列(Virtual Columns)。
    在11g之前所有的Oracle数据库后台或者前台进程如果需要获得当前时间信息,就需要调用操作系统的gettimeofday()函数或者说是相类似的函数。而VKTM进程就是专门用来获得时间信息然后将信息存放在SGA中供其它进程使用,这样其它进程当需要时间信息的时候,只要到SGA的某个内存位置去获得就好,而不用频繁调用gettimeofday()函数。毫无疑问,这样效率会更高。
    OPTIMIZER_INDEX_CACHING和OPTIMIZER_INDEX_COST_ADJ参数说明
    在编译《Oracle Core——Essential Internals for DBAs and Developers》这本书的第6章时,这章有提到进程在查找空闲缓冲区时,会从REPL_AUX链(即辅助LRU链)开始扫描,在扫描的过程中发现有dirty buffer,则会将该buffer从REPL_AUX链取下再链到WRITE_MAIN链上。这里提到的REPL_AUX链,主要用于链接那些能够马上复用的buffer(缓冲区),比如一致性读块,很少访问的块,大表全表扫描的块。而进程在查找可用的空闲或可复用的缓冲区时,会从REPL_AUX链开始查找,如果REPL_AUX链上如果有可用的缓冲区,那么进程就能很快获取到缓冲区以便用于存储从磁盘读入的块。那在REPL_AUX链上会不会有脏块呢?如果没有,那么进程在扫描REPL_AUX时会更快更简单。而答案是”在REPL_AUX链上是会存在脏块“的。
    今天有朋友在群里面讨论oracle数据库最大可以存储的数据大小,下面根据官方文档提供的相关限制,大概估算出来oracle数据库最多可以存储的数据量
[ 共210篇文章 ][ 第3页/共11页 ][ 1 ][ 2 ][ 3 ][ 4 ][ 5 ][ 6 ][ 7 ][ 8 ][ 9 ][ 10 ][ >| ]
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1