今天重新阅读Latch的文档，按照我自己的理解，对于vlatch视图中的以下几个字段再作一些解释。 以下参数都是对于Willing-to-wait模式的latch而言的，no-wait模式的latch获得情况统计值则在IMMEDIATE_GETS和IMMEDIATE_MISSES字段中。所有vlatch视图中统计值都是在获得了latch之后才更新的。 GETS：当尝试获取一个latch并最终获得的时候，该值加1，在一次请求中无论是经过多少次自旋多少次Sleep，该值只会加1. MISSES：如果没能不经过自旋（spin）就获得latch，该值加1，在一次请求中无论是经过多少次自旋多少次Sleep，该值只会加1. SPIN_GETS：如果经过自旋才获得latch，该值加1，在一次请求中无论是经过多少次自旋，该值只会加1；如果经过了下述的SLEEPS方式才获得的latch，那么该值不变。 SLEEPS：这是MISS之后进程除了自旋之外，可能采取的另外一种方式-睡眠，将等待信号量唤醒或者Timeout唤醒。可能是由于多次自旋以后，仍然无法获得latch，进程就停止占用CPU，进入Sleep状态；也可能是首次尝试获取latch失败以后就直接进入睡眠期（比如单个CPU的机器中）。Sleep以后获得latch，该值加1，如果一次Sleep以后被唤醒，但是却仍然无法获得latch，那么会再次自旋，还无法获得，再次Sleep（睡眠时间会逐渐变长），多次Sleep会累加该值。 SQL> select count(*) from v$latch where MISSES=0; COUNT(*) ———- 484 如上所示，这些latch都是一次请求就直接成功了，连一次Miss都没有。只要MISSES=0，那么SPIN_GETS和SLEEPS也一定等于0。 SQL> select NAME,GETS,MISSES,SPIN_GETS,SLEEPS from v$latch where MISSES>0 and SLEEPS=0; NAME GETS MISSES SPIN_GETS SLEEPS —————————————- ———- ———- ———- ———- process allocation 31557 8 8 0 session switching 32313 3 3 0 process group creation 24916 1 1 0…
Author: Kamus
DBA, If don’t know what you are doing, please don’t do
今天收到一个发过来请求帮助的case，Oracle数据库无法启动，请求帮助恢复。仔细阅读了发过来的告警日志，这是一个典型的“事情越弄越糟”的案例。 以下就来根据告警日志，一条一条地回顾这位DBA是如何将数据库弄到完全启动不了的。 故障最开始是从1月11日的凌晨3:30开始出现，数据库在归档的时候，意外发现某个控制文件的头块全部被清零了，这可能是存储本身的问题，并非人为。 Fri Jan 11 03:30:24 2013 Errors in file /oracle/admin/dpdata/bdump/dpdata_arc1_3031.trc: ORA-00227: corrupt block detected in control file: (block 1, # blocks 1) ORA-00202: control file: ‘/oracle/oradata/dpdata/control03.ctl’ Master background archival failure: 227 Fri Jan 11 03:31:24 2013 Hex dump of (file 0, block 1) in trace file /oracle/admin/dpdata/bdump/dpdata_arc1_3031.trc Corrupt block relative dba: 0x00000001 (file…
Compare SAP HANA with Oracle Exadata
【前言】 本文的最终观点：如果不是拿全公司的产品线来混合搭配，如果仅就一款产品而言，无论其它厂商如何宣传，目前整个IT业界还没有任何一款一体机产品能跟Oracle Exadata同场较量，TeraData不能，IBM PureSystem不能，SAP HANA也同样不能。而SAP HANA可能更应该拿自己去跟Exalytics作比较，而不是Exadata。 本文对于SAP HANA的认知来自于“SAP HANA Essentials eBook”以及Experience SAP HANA站点，完全属于纸上谈兵，如果有更熟悉SAP HANA技术的技术人员认为本文有失偏颇，欢迎指正。 【正文】 需要承认SAP HANA的出现，在理念上与Oracle Exadata几乎是完全一致的，SAP也意识到大量的数据要从缓慢的磁盘子系统中读取到计算资源中，这部分读取操作成为了最大的性能瓶颈，解决方法就是在计算时减少不必要的IO。对此，SAP HANA的解决方案是跳过磁盘层，通过压缩，将大量数据完全放到内存中，当然于此相配套的还有一些对于数据持久化的技术解决方案，但是无论如何，HANA作到的只是内存间计算而已，能够做到这一点，几乎完全得益于硬件的发展，如果不是当前内存容量剧增而成本却持续下降的话，几乎无法想象HANA能够成为普遍的企业级解决方案。 而与HANA相比，很明显Oracle Exadata在磁盘层读取技术上进行了大量创新，Smart Scan以及Storage Index等技术，都是更有意思的创造，从这一点而言，Oracle的创新更大，作为内存数据库＋内存分析解决方案的Exalytics提供了跟Exadata的完美连接，如果需要分析的数据过于庞大而无法完全放置在Exalytics的内存中，那么仍然可以通过Exadata中的压缩，并行，智能扫描等创新技术来加速存储在磁盘中的数据的计算。这是一套更完善的解决方案，也更适合企业IT架构更平滑的过渡。 我们可以简单地认为SAP HANA是一个内存数据库解决方案（这可以与Oracle TimesTen相比较），或者称为内存计算解决方案（这可以与整合了Oracle BI，Oracle TimesTen以及Essbase的Exalytics相比较），这与Exadata的定位以及地位完全不一样。 说的更直白一些，凭着内存足够大，将数据都放到内存中，来获得计算速度的提升，这算什么创新的本事？内存大了，哪家数据库厂家花点儿心思在持久化保存上，都能这么干，这样并无核心竞争力。 以下列出一些分散的并不成体系的关于SAP HANA和Oracle Exadata的观点，同样，欢迎点评及讨论。 1. SAP HANA中列式表和行式表的转换也许是一个亮点。我想Oracle在Exadata中应该借鉴。 2. HANA迄今为止只支持报表应用，因此维护大并发需要的事务锁机制这个最大的技术难点目前看SAP还没有任何解决方案，那么这样的产品并不能与Exadata相提并论。事实是这样的：一直到2012年之前，SAP HANA的解决方案都称为SAP BW Accelerator，这需要一个独立的HANA数据库来完成BI报表，直到SAP BW 7.3 SP5 on SAP HANA的出现，HANA可以当作主数据库使用，不但是查询，而且企业数据改变也直接访问HANA，但这也仍然只是面对数据仓库以及BI领域的应用，这时候被称为SAP NetWeaver BW Powered by SAP HANA（说实话，这名字真够长的）。迄今为止HANA还未能宣布支持真正OLTP应用的案例。 3. HANA的数据持久化机制从文档上看，并无任何特殊之处，几乎与Oracle完全一样，通过将提交的事务写入log，来保证断电重启以后，可以重演log，这就是Oracle的redolog写机制。 4….