技术头条 - 一个快速在微博传播文章的方式     搜索本站
您现在的位置首页 --> Alibaba DBA Team
    HBase的优点:分布式,易扩展,高性价比,运维成本低都是它的优点。HBase可以支持海量数据,单张表的数据量不上T,都不好意思出来打招呼。甚至可以拿很烂的SATA盘来作为存储,由于依赖底层的HDFS。新装的机器甚至可以不用做硬RAID。
    hash join是oracle里面一个非常强悍的功能,当做hash join时,oracle会选择一个表作为驱动表,先根据过滤条件排除不必要的数据,然后将结果集做成hash表,放入进程的hash area,接着扫描第二张表,将行的键值做hash运算,到内存的hash表里面去探测,如果探测成功,就返回数据,否则这行就丢弃掉这个是最基本的解释,实际情况中,考虑到单个进程PGA的大小,oracle不会让进程任意的消耗OS内存,hash area是有一定限制的,所以在oracl...
    CPU时间采集从10G开始,oracle引入了时间模型,我们可以从oracle的角度来看CPU的使用程度先说说几个概念 db time:oracle数据库消耗的时间,这个范围比较大,包括了CPU使用,等待IO子系统返回,网络处理等 db cpu:指oracle单纯消耗CPU,做CPU运算的时间,关于IO,网络的等待都不在这个范围内,用它来统计真实CPU的消耗比较准确 CPU TIME:这个是我取的名字,表示CPU能给你提供的最大时间,比如你有4个cpu/core,那么1小时内,CPU T...
    在Linux世界里,分为Page cache,Buffer cache两个层面。其中page cache包含了buffer cache,内存只和page cache交互。

    标准的LINUX总 是假定处理器有三级页表,分别为页目录表(PGD),中间页目录表(PMD)和页表(PTE)。如果程序在进行物理地址转换的时候,中是通过页目录表来索 引中间页目录表,再通过中间页目录表来索引页表,从而查找到某页与内存BLOCK块的对应关系。

     bitmap我们可能平时使用的不多,但是觉得它在特殊的应用场景,还 是有优势的。bitmap join index更是一种多表JOIN的新方式,很有意思。
    今天在Uwe Hesse的Blog上看到这篇文章,感觉很不错,简要地描述Oracle MAA架构的所有相关产品,虽然之前就有接触所有这些解决方案,但解释的如此清楚明了的还是第一次看到,特将其翻译如下. 原文: Oracle Database HA Architecture Oracle高可用架构作者: Uwe Hesse, 译者: Jametong Oracle高可用架构是我所讲课程里的一个热门话题.本文尝试对此话题做一个总体的说明,内容涵盖”普通的”单实例数据库,DataGuard,RAC以及扩展R...
    网络上有多篇介绍Oracle索引实现机制的文章,都提及需要经常重建索引.在这些文章中的某处,总是会出现这样一段简短的描述,索引会如何变的不平衡,以及可能导致的后果.很不幸,它们好像忽视了这样一个事实,Oracle使用的B-tree机制是一种”平衡B-tree”索引,也就是说,索引无法变得不平衡.
    标题的这个问题可能是在Metalink论坛与Usenet新闻组出现的最频繁的问题了.这篇文章使用一个测试用例(可以在你自己的系统来重现的)来演示基于成本的优化器的基本工作原理.在看完这篇文章之后,当再次遇到这个令人讨厌的问题时,你应该就可以自信的解答了.
    译者注: 本文翻译自Jonathan Lewis的文章Faking Stored Outlines in Oracle 9, 可以从此处下载原文的word版本: Stored Outlines in Oracle 9. 本文与前一篇Oracle 8i/9i中的执行计划稳定性是Jonathan Lewis先生写的关于stored outline具体使用以及其中可能涉及到的风险系列文章,也是我所见到的关于stored outline介绍的最详细的文档了. 关于stored outline还有以下相关资料可以对照阅读下: Oracle Outlines - aka Plan Stability B...
    业务场景:表xngul 大小大于 100G。上面有(id)是number型自增字段,且是pk。现在有需求要对这个表进行全表扫描,如果直接 select * from xngul, 则至少要半个小时,而且一次性返回数据过多,应用程序无法处理。所以想了办法化整为零,将这个表分段,分段读取。有以下三种方式。 *******I.两个步骤,一个取分段的头尾,一个按头尾取分段内数据。*********
    以Intel Nehalem CPU的强劲性能和SSD盘的高iops为使用高性能pc服务器加SSD硬盘取代传统小型机加存储的方案成为可能。现在2颗4核的Intel Nelhalem cpu的性能已经达到或超过了一般的小型机的性能。单块SLC SSD硬盘的iops就可以达到10000以上,所以使用多块SSD硬盘的iops将超过或达到高端存储的IOPS的性能。 然而在pc服务器中缺乏与小型机系统上相应的成熟高可用方案,让大家对如何实现使用Intel Nehalem+SSD盘取带小...
    最近DB升级到了11G,多了好多新的进程。这几天看了下,每个进程的作用。
    关于应用DBA的价值 和对团队的贡献,前几天在一个小范围作了个讨论,以下是我做的一个整理(70%引自大师): 产品DBA和应用DBA不过是阿里巴巴DBA在成长路线上的两种方式。因为我们以前都是纵向的在技能方面深入,所以最近两年比较强调横向的东西。横向的协调、沟通、推动,远比一个人去学习技能困难的多,而这种能力实际上是可以放到更多的环境中去施展的。技能却只能在这一个领域。主机、os、存储,相信以大家的悟性,1-2年经...
    以前11G的主库对表做了truncate ,在备库查询这张表,有时候会遇到ORA-08103: object no longer exists ,需要激活standby或者打补丁才能解决现在11.1.0.7上,也出现了一系列的关于ddl定义的BUG,因为物理standby的redo apply是基于数据块级别的,他不像我们走正常的SQL调用,所以,主库做了DDL,会引起shared pool里面数据字典新的的一系列更新,而在备库上,redo只负责把datafile block刷新了,但shared pool里的内容,却没有...
    同事在10G DOCS上看到,AIX下如果绕过VG,直接使用裸盘做ASM,当设备的PVID变化时,会引起磁盘组数据丢失今天晚上做了测试首先清除掉了hdiskpowerx上的pvid,发现再启动ASM的时候,mount dg出错了,
    今天,查看一个数据库时,发现这个数据库没有使用到powerpath提供的多路径盘上。这个数据库使用EMC的存储,操作系统是Linux,使用了asm lib包。
    今天下午部门里的几个达人针对ASM发生了激烈的争论,其实观点上大同小异,只是表达上理解的有点偏差 ASM实例其实就是一个LVM,负责对OS一级磁盘的管理,这里把磁盘说成lun更准确点,因为磁盘容易让人理解为最底层的存储上的铁疙瘩,而ASM只会认识LUN,至于这个LUN下面由多少个小盘组成,怎么做stripe是不关心的,在这点上几位大牛的观点是一致的,但还是吵了半天 ASM完成的是一个翻译工作,他本身并不负责到LUN上获取数据来返回...
    最近做FS3,一直对nfs的随机IOPS性能不高所困扰,所以细细分析了nfs的运行机制: NFS做数据传输是通过RPC调用来完成了。RPC调用的特点为,发起调用的进程会等待服务器端完成调用,在服务器端完成调用之前,发起调用的进程是会一直被阻塞的。同时对于NFS来说,一个nfs client端到一个nfs Server端只会建立一个连接。nfs服务请求的处理过程是,只有上一个请求处理完成后,才能处理下一个请求。所以处理过程是串行的,而不是并发的...
    这几天测试了一下oracle11g Direct NFS 的功能,发现ORACLE Direct NFS是通过建立多个到NFS Server的TCP连接来提高IO的并发能力的。前面,我们提过,NFS的IO能力不高的原因是,NFS client端到NFS Server的操作是串行的,正常的NFS client到NFS Server端只建立一个连接,而且只有等前一个请求处理完成后,后一个请求才能处理,这样在随机读IO上就上不去。而Oracle Directd NFS与NFS Server建立多个TCP连接,处理就可以并发进行了,...
    11G standby提供了real time query的功能,通过这个功能,我们可以结合lgwr+async来做到实时standby查询,给我们做读写分离提供了遐想空间,最近和老郑测试了下这个功能的实时性,希望对大家有所帮助测试环境: redhat linux as 4.7(64bit) 11.1.0.7.0 lgwr + async 20480 + real time query 主库:10组512M的联机日志备库:11组512M的standby logfile 测试方法:循环插入记录,为了增大日志量,起了6个进程,插入test1-test6 ...
[ 共20篇文章 ][ 第1页/共1页 ][ 1 ]
赞助商广告
© 2009 - 2024 by blogread.cn 微博:@IT技术博客大学习

京ICP备15002552号-1