您现在的位置：首页
--> Oracle
在Oracle数据库中，SQL解析有几种：
硬解析，过多的硬解析在系统中产生shared pool latch和library cache liatch争用，消耗过多的shared pool，使得系统不具有可伸缩性。
软解析，过多的软解析仍然可能会导致系统问题，特别是如果有少量的SQL高并发地进行软解析，会产生library cache latch或者是share方式的mutex争用。
软软解析，其实这也也属于软解析，与普通的软解析不同的是，软软解析的SQL会在会话的cached cursor中命中。
一次解析，多次执行，这是解析次数最少的方式，也是系统最具有可扩展性的方式。
在繁忙的系统中，我们总是会期望提高某些Oracle进程的优先级，使其能够更容易的获得CPU资源，执行重要的任务。在Oracle 10g之前，这样的工作要通过操作系统上的设置来实现，在Oracle 10gR2中，一个新的隐含参数被引入到数据库中，用于配置提升Oracle后台进程的优先级。
PL/SQL是Oracle对SQL的过程化扩展，是Oracle数据库内部直接支持的语言。甚至，管理数据库的API接口都是以PL/SQL存储过程的方式提供的，耳熟能详的诸如收集统计信息，打印执行计划等等。PL/SQL除了与SQL语言无缝衔接之外，还具有所有过程化强类型语言的一切特征，如变量/过程/函数的定义，一般的控制结构，异常处理等等。
Oracle中的mutex，类似于Latch，是一种低级的串行机制，用以控制对SGA中部分共享数据结构的访问控制。 Oracle中的串行机制有不少，引入它们的目的是避免一个对象出现下述现象： 当某些进程在访问该对象时，该资源被重新分配 当某些进程在修改它时，被其他进程读取 当某些进程在修改它时，被其他进程修改 当某些进程在读取它时，被其他进程修改 不同于Latch，Mutex的使用更灵活，用途更多，例如: 哪些需要被mutex保护的共享数据结构可以有自己独立的mutex，即一个对象拥有自己独立的mutex，不像Latch往往一个需要保护大量对象。
undo事务具体是如何回滚,这里提供了大概的异常undo事务回滚的一个过程(更加准确的说，这个过程是在以下几种情况中发生的过程：1.数据库非正常关闭后启动,2.事务未提交会话终止)，数据库先扫描所有回滚段，然后发现有事务未提交回滚段,然后根据这个回滚段定位到undo block,然后定位到data block，当一个undo block回滚完成之后，利用undo的链表规则完成下一个undo block的回滚操作，依次类此，从而实现数据库的回滚操作；回滚的过程是先回滚后操作的块(先进后出原则)
悲剧的客户因为IBM p系列小机更换电源导致主机直接掉电,起来后发现数据库出现不少坏块,而且还有部分坏块中含有回滚事务,导致alert日志一直报smon回滚遇到坏块错误，该数据库版本是9.2.0.8 RAC,根据客户的备份情况,为了减少对业务的影响,决定使用blockrecover对其处理.这里通过10g数据库大概模拟出现含事务坏块的情况以及处理过程,重现了我们在处理的时候不确定的一些知识.
有时候,多么的希望ORACLE能够导出某个视图中的数据,然后通过这个视图来迁移需要的数据,现在ORACLE 12C通过expdp的views_as_tables来实现了该功能,把视图当作一个普通表从而导出数据,导入的时候直接和一个正常表一样,通过视图的导出,表的导入来实现相关需求
随着xd的越来越普及，不少的企业使用了xd，但是不少企业因为资金有限，只有一台xd，但是为了实现数据的容灾，可能会使用一台非xd的机器来通过dataguard来实现容灾,但是因为xd的ehcc新特性,官方宣传是只在xd中支持,如果dg的备库不是xd。那么会怎么样,这里通过测试得出如下一些结论：xd与非xd可以构造dg,ehcc功能在xd上无法高效使用。对于这样的环境条件下,使用ORACLE自带压缩效率更高.针对ehcc压缩效率很低。
Database Replay是11g中很酷的特性，对于workload capture的内部工作原理大家理解的不多，这里就介绍一下。
如何检验sql profile的性能 10g以后的sql tuning advisor(可以通过Enterprise Manager或DBMS_SQLTUNE包访问)会给出对于SQL的建议包括以下四种： 1. 收集最新的统计信息 2. 彻底重构该SQL语句 3. 创建推荐的索引 4. 启用SQL TUNING ADVISOR找到的SQL PROFILE 这里我们要注意的是在production环境中显然不可能让我们在没有充分测试的前提下随意为SQL接受一个PROFILE，因为这可能为本来就性能糟糕而需要调优的系统引来变化。
对ORACLE比较熟悉的人都知道v$datafile.CREATION_TIME和v$datafile_header.CREATION_TIME这两个列都是表示数据文件的创建时间,而根据我们的经验可以知道几点:
1.当v$datafile.CREATION_TIME与v$datafile_header.CREATION_TIME不一致时数据库不能正常启动；
2.v$datafile.CREATION_TIME的值来源于v$datafile_header.CREATION_TIME；
3.而v$datafile_header.CREATION_TIME的值来源于数据文件头的块中的信息；
现在就出现一个问题,数据块中的kcvfhcrt是一个16进制的数,如何实现在v$datafile和v$datafile_header中转为为了数据文件创建的日期。
记录下ORACEL RAC 修改字符集的步骤。。。。。。。
有很多朋友因为11gR2那些潜在的特性可能给升级后系统稳定运行带来麻烦而无法鼓足升级到11gR2的勇气，实际Oracle在开发新版本RDBMS软件时引入的一些特性有很好的理念的，但是往往这些理念会给已稳定的应用环境带来变数，最显著的就是10g/9i升级到11gR2时的执行计划稳定性，此外adaptive cursor sharing 自适应游标、automatic serial direct path自动判断串行直接路径读、deferred segment creation、GC read mostly DRM…….等等的一系列特性已经在大量的案例中被证明是不适合于大量国产Application的。
在Oracle业界混的兄弟们肯定听说过以下的2个传说： LISTENER.LOG日志大小不能超过2GB，超过会导致LISTENER监听器无法处理新的连接 Oracle Instance实例所在的主机运行超过198天必须重启，否则会遇到Oracle BUG 第一条传说LISTENER.LOG日志不能超过2GB，这个绝对是老DBA津津乐道要向新手介绍的经典经验之一，这条传说带来的负面思想是Oracle数据库的监听器最好不要启动过长时间， LISTENER.LOG日志的内容也要定期清理(这条还是应当推荐的)。
在Oracle Database 12c之前，翻页查询需要试用rownum的方式进行SQL嵌套查询编写，这非常复杂，在12c中，新增了Top N查询支持特性，允许试用Offset / Limit 等限定进行Top N查询，原来的ROWNUM方式可以被替代。
近3天十大热文
-
[55] 如何拿下简短的域名 -
[54] IOS安全–浅谈关于IOS加固的几种方法
-
[54] Go Reflect 性能
-
[53] Oracle MTS模式下 进程地址与会话信
-
[53] android 开发入门
-
[51] 图书馆的世界纪录
-
[49] 【社会化设计】自我（self）部分――欢迎区
-
[48] 读书笔记-壹百度:百度十年千倍的29条法则
-
[39] 程序员技术练级攻略
-
[30] 视觉调整－设计师 vs. 逻辑
赞助商广告
