您现在的位置：首页
--> 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活动中分享的一个主题。
在11g之前所有的Oracle数据库后台或者前台进程如果需要获得当前时间信息，就需要调用操作系统的gettimeofday()函数或者说是相类似的函数。而VKTM进程就是专门用来获得时间信息然后将信息存放在SGA中供其它进程使用，这样其它进程当需要时间信息的时候，只要到SGA的某个内存位置去获得就好，而不用频繁调用gettimeofday()函数。毫无疑问，这样效率会更高。
在编译《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数据库最多可以存储的数据量
近3天十大热文
-
[604] 招聘技巧一二 -
[17] 我的git笔记
-
[16] 在ssh服务里使用chroot
-
[16] 密度聚类算法之OPTICS
-
[14] 数据分析中常用的数据模型
-
[14] Android用户界面设计：表格布局
-
[14] 豆瓣是啥？
-
[13] 配合jquery实现异步加载页面元素
-
[13] jQuery性能优化指南
-
[12] linux内核研究笔记(一）内存管理 – p
赞助商广告
