2010-02-02 Tue
因公司业务发展需要,招聘中级Oracle DBA
人数:1人
地点:杭州
要求:
1、两年以上ORACLE DBA/技术支持相关工作经验,可以独立承担安装部署以及基本的ORACLE操作,熟悉UNIX/RAC/PARTITION/DATA GUARD优先
2、有OCP证书优先、有电信行业Oracle数据库维护经验优化
3、熟悉UNIX 操作系统、掌握SHELL经验
4、有良好的人际关系和沟通能力
5、请在简历注明待遇要求,如果附件发送简历请在附件名称注明个人姓名
待遇:
1:薪资面谈
2:每月提供交通和通信补贴
3:在职期间,通过OCM考试,报销全部费用
有意者,请简历给我 guoyue@gmail.com
小提示:
如果你想接触7×24的超大型OLTP系统,如果你想挑战下自己,如果你想慢慢的从技术走向技术管理岗位,又或者你对自己现有的环境不满意,想尝试更大压力的系统,我想,这个机会,你值得一试!
招聘的团队leader是资深oracle专家,OCM,相信对自己的水平提升具有很大的帮助。
前几天,在ITPUB上看到一则网友的经验分享,纪录了一次Patch应用过程的曲折。
在这样曲折的过程中,我们可以注意到,对于一个关键的操作,无论采取怎样认真、细致、繁琐的测试、验证与规划都是值得的。
我们在很多工作中,要求都非常严格,一般都要进行工作步骤列表,制定可执行的回退方案等,有时候大家也觉得繁琐,但是繁琐的结果是可控,在穷举了可能的异常之后,我们才能胸有成竹的进行变更。
转引一下网友的经验之路:
由于种种原因,需要给数据库打patch,并且把db_cache_size和shared_pool_size改小。
先在备库打patch,期间,有一个lib文件提示无法覆盖;去metalink搜,发现note 739963.1,在aix下,升级和打patch过程中,即使所有服务都停止了,也会出现无法覆盖lib文件。
需要用root,执行/usr/sbin/slibclean,然后在重新运行patch apply。
这个步骤不算有太大的问题,不过一般slibclean文件应该是熟悉的,在安装手册里是有明确记录的步骤。
修改参数,原来的db_cache_size=6G,shared_pool_size=4G,需要修改为4G和3G。
然后切换HA,再在主机继续打patch。
谁知道,在切换到备机后,修改过参数的数据库无法启动,直接报错:ora-00064 object is too large to allocate on this o/s.
看来问题是出在修改过的参数上。没办法,创建pfile,将参数修改过来吧......
这个步骤除了参数文件修改引起了一些不应该出现的麻烦,我们认为在备机应用完补丁之后,可以尝试一下在备机启动实例,确认没有问题再切换主机。在备机100%确认验证无误之前,主机的数据库应当不动,至少保证数据库在一台主机可以正常运行。
在发生问题的过程中,为了减少对业务影响,启动应急数据库和另外两台数据库。
应急数据库启动没问题,帐务数据库启动没问题;计费数据库启动失败,提示无法lock控制文件,查看vg状态,都正常,最后查lv的个数,主库26,bcv上有34......
很多经验表明,启用应急数据库是一件极其重大的决定,在没有100%的把握时,尽量不要采取这个措施。当然,如果应急只是作为只读环境,那要简单得多。
bcv问题处理完,暂时业务不用中断,继续打patch。
局方的人将数据库切换到备机,我在主机打patch,又提示文件无法覆盖;执行/usr/sbin/slibclean也不管用!
ps -ef|grep ora发现很多oracle进程存在,ps -ef | grep pmon,没看到有记录;刚开始怀疑是局方没有切换HA,但是登录到备库,发现数据库已经在备库启动。
HA切换脚本是,先停listener,然后再停数据库,umount盘阵。但是不知道为什么还有进程在备库存在。
确认应用都已切换到应急数据库,杀掉主库所有oracle进程。
ps -ef|grep $ORACLE_SID|grep -v ora_|grep LOCAL=NO|awk '{print $2}'|xargs kill
重新打patch,一切正常。
颇为曲折。
后来在bcv验证,数据库启动不了,主要是share pool改小引起;本来以为100%没有事情的事情,最后还是出事了!
墨菲定律,没有100%的安全,所以事前的完善规划是极为重要的。
在这次补丁应用过程中,如果在各个步骤的操作之后,加上一些测试验证步骤,就可以避免异常出现时的忙乱,也就可以多一份从容。
-The End-
相关文章|Related Articles
- 何去何从 - 关于DBA前途问题的探讨
- DBA日常工作职责 - 我对DBA的七点建议
- 谁与争锋-数据库管理工具OEM、I3的取舍
- Oracle Database 10g 与 DBA 2.0的时代
- DBA 2.0的时代与 Oracle促进的变革
评论数量(1)|Add Comments
本文网址:http://www.eygle.com/archives/2010/02/dba.html
2010-02-01 Mon
作者:Jacky 发布在 dbanotes.net.
自从 Oracle 和 HP 推出 Exadata 之后,我就很关注这个产品,之前也写了一篇Oracle Database Machine介绍它。去年,Oracle和SUN合并后,推出了Oracle Exadata V2,相比较上一代产品有几个变化:第一,使用 SUN 的硬件;第二,宣称支持 OLTP 应用;第三,Oracle 11g R2 提供了更多的新特性。
Exadata Smart Flash Cache
Exadata V2整体架构并没有太多改变,换用了 SUN 的硬件,除了采用 Intel 最新的 Nehalem CPU 以外,每台 Storage Cell 更是配置了 384GB 的 Flash,这也是为什么 V2 可以支持 OLTP 应用的关键。
Flash Cache 完全是自动管理,Oracle 会根据数据的访问情况,决定哪些数据放在 Flash Cache 中。所有的数据都是先被写到普通磁盘上,再根据访问情况读入 Flash Cache 的,所以如果 Flash Card 发生故障,数据不会丢失。当然,Oracle提供了方式,可以让用户手动将表或者索引 Pin 在 Flash Cache 中。
在自动管理的方式之外,Oracle还允许用户人工创建flash disks,和普通磁盘一样,这些 Flash Disks 通过 ASM 输出给数据库使用,用户可以把一些访问非常频繁的数据文件放在上面。这些 Flash Disks 不仅仅是 Cache 了,所以 ASM 会在Cell 和 Cell 之间做镜像。如果某块卡发生故障,那么整个 Storage Cell 上的 Flash Disks 会 offline,保证数据不会丢失。
Smart Scan
Smart Scan是 Exadata 最重要的一个功能,它的作用就是把 SQL 放在每个 Cell 上去运行,然后每个 Cell 只返回符合条件的数据给数据库,这样就极大的降低了数据库服务器的负载和网络流量,并充分利用了 Cell 的计算资源和 IO 资源。
传统方式:所有的数据都需要返回给数据库服务器,网络带宽要求高,所有的计算在数据库服务器上完成。
Smart scan:只返回符合条件的数据,减少网络带宽,并充分利用了 Cell 上的计算和 IO 资源。
这里有一点要注意,在使用 Smart Scan 时,每个 Cell 返回给 DB Server 的是结果集,而不再是传统的 Block, DB Server 完成结果集的处理,并返回给客户端。
Smart Scan 如何处理 Join ?
这是我一直想要搞清楚的问题。事实上, Smart Scan 只能处理 Join filtering,而真正 Join 的工作必须在 DB Server上完成,而且Smart Scan 仅适合于处理 DSS 环境的复杂 Join,对于 OLTP 类型的简单 Join,Smart Scan 并不能发挥其优势。设想下面的查询:
select e.ename,d.dname from emp e, dept d where and e.ename='Jacky' and e.deptno=d.deptno;
假设采用 nested loops join,Smart Scan 只能完成 e.ename='Jacky' 这个条件的过滤,然后将符合条件的 emp 表的数据返回到 DB server,然后由 DB Server 完成 join 的工作,逐条查询dept表 (e.deptno=d.deptno) 的数据。所以 Smart Scan 并不适合nested loop join(我认为 Smart Scan 只有在适合的条件下才会启用),只有 DSS 环境的大数据量复杂join才会发挥出优势。而且 Smart Scan 只能完成filtering的工作,而不能真正完成 Join 的工作,这个与 Greenplum 数据库是不同的(有兴趣可以看我的文章,Greenplum技术浅析)。设想下面的查询(emp和dept都是大表):
select e.ename,d.dname from emp e, dept d where e.deptno=d.deptno;
假设采用 Hash Join ,由于没有任何过滤条件, Smart Scan 只能把两个表的数据全部返回到 DB Server 上进行join操作,不过 Smart Scan 也不是一点用都没有,至少还可以进行 column 的过滤,只返回需要的字段就可以了。
Oracle 的文档中,曾经提到对于一个大表和小表join时, Smart Scan 会采用bloom filter来快速定位(可以看我以前的文章,有趣的 bloom filter )。方法是把小表build成为bloom filter,然后在每个storage cell上对大表做scan,利用bloom filter快速定位符合条件的结果,并返回给 DB Server 作 join。
Storage Index
存储索引,顾名思义是在存储级别建立的索引,简单的说就是为表中的每一列数据建立一个索引,每个index entry记录一段数据区间的最大值,最小值以及它们的物理位置,文档上说1MB数据对应一条index entry,见下图:
如果我们查询B<2,或者B>8的数据,根据存储索引,我们就可以跳过这些不在min和max之间的数据块,极大的提高了扫描的速度,这就是存储索引的意义。
Hybrid Columnar Compress
首先我们要搞清楚,什么是行压缩,什么叫列压缩。我们熟悉的数据库,如Oracle、MySQL等都是基于行的数据库,就是行的不同字段物理上存放在一起,还有一种是基于列的数据库,就是每个字段的不同行物理上存放在一起。他们的优缺点同样突出:
基于行的数据库,访问一行非常方便,但是由于同一列的数据是分开存放的,如果要针对某一列进行查询时,几乎要扫描整个表才能得到结果。基于行数据库的压缩,称为行压缩。
基于列的数据库,因为同一列的数据物理上放在一起,所以访问一列非常方便,也就是说如果针对某一列进行查询时,不需要扫描整个表,只需要扫描这一列的数据就可以了,但是访问一行的全部字段非常不方便(又是废话)。基于列数据库的压缩,称为列压缩。
Oracle 通常说的 compress 功能(包括11g R2的Advanced compress),都是行压缩,因为Oracle是个基于行的数据库。大概的方法就是在block头部存放一个symbol table,然后将相同的值放在那里,每行上相同的数据指向symbol table,以此来达到压缩的目的。行压缩的效果通常不好,因为我们知道行与行之间,其实相同的数据并不多。但是列压缩则不同,因为相同列的数据类型相同,很容易达到很好的压缩效果。
行压缩和列压缩都有其优缺点,而Oracle的混合列压缩技术,实际上是融合了列压缩的高压缩比和行数据库的访问特性,将两者的优点结合起来。Oracle提出了 CU 的概念(compress unit),在一个 CU 内,是一个基于列的存储方式,采用列压缩,但是一个 CU 内保存了行的所有字段信息,所以在CU与CU之间,Oracle还是一个基于行的数据库,访问某一行,总是只在一个 CU 内。每个CU由一些连续的block组成,CU header中记录了每一行的各个列在CU中的分布情况,在混合列压缩模式下,一行通常是跨多个block的。
所以说混合列压缩,结合了列压缩和行访问的特点,即可以提供非常高的压缩率,又很好的保证了基于行类型的访问。
Exadata的另一个重要功能是 IO resource management,如果我们在一个 Exadata 上部署了很多个数据库,可以用它来管理 IO 资源,这里就不作阐述了。
目前,我还没有了解到在国内有 Exadata 的应用,而且资料也是比较少的。希望有机会可以真实的测试一下它的性能,我不怀疑他在 DSS 环境下的表现,但是对于 OLTP 类型的应用,是否真的象 Oracle 说的那么强劲,还有待于验证。
-EOF-
稿件来源。
最近文章|Recent Articles
本站赞助商:豆瓣网
评论数(2)|添加评论 | 最近作者还说了什么? Follow Fenng@Twitter
本文网址:http://www.dbanotes.net/database/oracle_exadata.html
DBA Notes 理念: 用简约的技术取得最大的收益...
每年的春运总是牵动着无数中国人的心,顺顺利利回家、高高兴兴团圆是每个身在异乡的中国人此时最急切的心愿。为了让大家回家过年更方便,重装上阵的“谷歌春运地图”在谷歌中国地图团队的努力下,今天正式上线!更加丰富的内容、更加强大的功能必将带给大家前所未有的体验。
与以往不同的是,今年的谷歌春运地图提供了更加完整的交通、出游和节日休闲购物等各类信息。包括全国31个主要城市的数千个火车售票点、160个机场的实时航班状态查询、省际高速路况、天气和最新春运资讯。不仅如此,春运地图还整合了北京,上海,武汉,成都,西安,广州六大城市春节期间的烟花禁放区域和近千个吃喝玩乐好去处,让你安全、开心地过大年!
1)火车售票:在“谷歌春运地图”上,你可以通过火车票查询,找到回家的车次和价格 。然后,你可以输入自己的位置,查找最近的火车售票点。如果你动作晚了,没有在第一时间买到回家的票, 那你不妨通过车次查询,找到“谷歌生活”为你搜集到的网友在各个网站上发布的车票转让信息。

2) 航班信息:航班是否准时起飞?归家的亲人是否已经上路?你可以键入飞机航班号,就知道飞机是否按时起飞。这些内容是实时的呦!全国160个机场的实时流量信息尽在你的掌握之中!

3) 高速路况:想开车回家吗?谷歌春运地图还整合了“中国公路信息网”的最新内容,出发前务必了解一下,千万别在这个时候被困在路上。

4)六大城市春节好去处:除了与春运相关的交通信息,谷歌春运地图还为大家提供了北京、上海、广州、西安、武汉和成都六大城市的休闲娱乐场所信息。试试看,你可能会发现自己竟然还不知道的新商场、餐厅、酒吧和KTV。过年了,让谷歌春运地图帮你实现城市发现之旅吧!快乐节日将会由你带给家人和朋友!




5) 如果你有自己的博客或网站,不妨嵌入谷歌地图。这样,读者从你的网站上就可以直接查看到这些信息喽!

请即登录谷歌春运地图, 立即体验。
周六上午自然醒,睁开眼就看见盖老咪看着我笑,他说做了一个梦,梦见盖小咪说:“射雕英雄传第一章第一节到此结束。” 这个梦把盖老咪乐醒了。
上午一边练瑜伽,一边看李敖的大学演讲,煲汤。
午饭后看了《福尔摩斯》,新片,挺有意思的。然后我们拉着小车去买菜了,中途决定去看房,于是被中介带着看了四五套房子,天黑之前买足了下一周的蔬菜和肉。跟盖老咪一起做饭,晚饭后看了套新片《成事在人》,可能是在户外着凉了,头疼。
《成事在人》讲述的是南非领袖孟德拉与橄榄球队跳羚的故事,我们都觉得很好看,Beyond有首歌‘光辉岁月’,就是向孟德拉致敬的。于是我和盖老咪赶紧搜到歌词,一起唱,凌晨12点。
关灯后,这晚的卧谈主题是关于文学家的,我们聊了很久很久,我们比赛,看谁记得最多的文学家,盖老咪按着我不让我上厕所,因为怕我作弊,中途跑去翻书。肚子饿,起床吃饼干的时候已经凌晨两点。
都不知道是周六哪个环节出了问题,或者是从上年年尾开始积劳成疾,周日醒来胳膊和脖子就僵硬了,很痛,稍微动一下,呼吸,打喷嚏我都感觉到身体的崩溃,痛得心惊胆跳的。盖老咪和盖小菊照顾我,于是一整天,我都躺在床上,听盖老咪给我下载的李敖访谈,有时候看见近年的李敖有点老态,他自己也这样认为,心挺酸的,可是谁也逃避不了啊。李敖太牛了,以至于他那么风流我都觉得他超可爱。
盖老咪整天地照料着我,喂我吃东西,扶我上下床,还做饭给我吃,其实整天躺在床上的时光也是很美好的,阳光很充足,照在脚丫子上,北京的冬天朝南的房间特别温暖,不用开暖气,穿短袖就够了,阳光晒着脚丫,晒着大腿和手臂,晒着鼻尖,拿一本很轻的书,一边看一边跟盖老咪说说话。。。
傍晚做饭的时候我们谈起古代的英雄,他说要当李世民,我呢,我要当成吉思汗,我觉得胡人啊,蒙古人啊特别有型,可惜匈奴不复存在了(又或者匈牙利人的祖先是匈奴?)
晚上盖小菊和丰丰一起回来了,我们一起看了一套烂片《Eagle Eye》,其实我觉得盖小菊和丰丰真挺配的,我知道他们真的拍拖的话,我会很开心。我特别特别希望他们能在一起...
周一上午休病假,颈椎好痛,吃了消炎药,胃也开始疼了。。。

...

...






