« April 2007 | 首页

1 2 3 4 (Page 3 of 4)



| June 2007 »

May 16, 2007

导致 Oracle 10gR2 出现 ORA-39095 的另一种原因

Oracle 10g R2 的 Data Pump 是一个好工具,弥补了传统 export/import 工具的很多不足。相关信息可以参考一下我以前对 Data Pump 的介绍

最近在 Linux 平台上经常遇到 ORA-39095 错误。这个错误。这个错误号,文档的解释:

ORA-39095:Dump file space has been exhausted: Unable to allocate string bytes
Cause: The Export job ran out of dump file space before the job was completed.
Action: Reattach to the job and add additional dump files to the job restarting the job.

这个解释只针对一般情况。我遇到的这个案例,目录的空间还有很多,可是也一样报错了。而且,一般在第 100 个 导出文件出错(更正:%U参数是2位,定长的,最大99)。开始以为是 Bug,可是遍查 Metalink,发现和 ORA-39095 错误有关只有两条信息,和我遇到的情况不符。

偶然在阅读 Oracle Database Utilities 手册的时候,发现了这一段话:

Because each active worker process or I/O server process writes exclusively to one file at a time, an insufficient number of files can have adverse effects. Some of the worker processes will be idle while waiting for files, thereby degrading the overall performance of the job. More importantly, if any member of a cooperating group of parallel I/O server processes cannot obtain a file for output, then the export operation will be stopped with an ORA-39095 error. Both situations can be corrected by attaching to the job using the Data Pump Export utility, adding more files using the ADD_FILE command while in interactive mode, and in the case of a stopped job, restarting the job.

真是孤陋寡闻了,我的并行度用的是 4 ,减小这个并行度,该错误不再出现。

You can supply multiple file_name specifications as a comma-delimited list or in separate DUMPFILE parameter specifications. If no extension is given for the filename, then Export uses the default file extension of .dmp. The filenames can contain a substitution variable (%U), which implies that multiple files may be generated. The substitution variable is expanded in the resulting filenames into a 2-digit, fixed-width, incrementing integer starting at 01 and ending at 99. If a file specification contains two substitution variables, both are incremented at the same time. For example, exp%Uaa%U.dmp would resolve to exp01aa01.dmp, exp02aa02.dmp, and so forth.

--EOF--

May 13, 2007

学习 Flickr 的 基于 LAMP 的容量规划经验

好久没怎么正式更新 Blog 了,快荒芜了,长满了 Spam 的荒草。

最近其实发现了不少可以和大家一起学习的好内容。FlickrJohn AllspawMySQL Conf 2007 作了一个题为 Capacity planning for LAMP (下载PDF文件) 的技术报告,说起容量规划,多少有点空对空的意思,不过这个 PPT 还是介绍了不少 Flickr 的网站运维经验。

Flickr 的数据量的确越来越惊人了,根据文档中透漏的数据:

Squid Cache 中共有 3500 万张图片;
在 Squid RAM 中有 200 万张图片;
4.7亿的图片,每张图片有4到5种尺寸;
每秒钟 38000 个到 memcached 的请求;
2 PB 裸存储容量(周日需要消耗1.5T 的空间)

三个主要步骤:

计划

基于实际业务,而不是抽象的理论。John Allspaw 认为基准测试(Benchmark) 作用并不大,这一点我也很赞同。在业务频繁变化的环境中,Benchmark 根本不能与实际业务情况匹配。

部署

Flickr 使用SystemImager/SystemConfigurator(自动化安装、软件分发),CVSup(网络中的文件分发、更新),Subcon(配置管理工具)提高部署效率。

度量(图形化展现)

Flickr 使用了 Ganglia 来进行容量数据的展现。Ganglia 最初设计是用于高性能集群计算的监控上面,也是以 RRDTool 为基础来进行图形展示。Ganglia 最主要的优点还是管理的方便性: Client/Server 结构, 各自跑 Demon 进行数据交互(XML形式)。相比起来, Cacti + Collectd 需要进行很多手工配置,在面对大量需要监控的主机的时候的确不那么方便。

Web 2.0 站点的运维似乎大家都在摸索着走。期望这次阿里巴巴组织的侠客行大会上也有有朋友坐下来聊聊这个话题(Flickr 的架构师本来可以来的,因为时间的问题不能成行,挺遗憾的)。

--EOF--

睡不着

可能是最近太累,昨天一口气从一点睡到了18点,邻居家的装修都没能让我清醒。当然中午的时候还是清醒了一会儿吃了一点东西就接着睡的。

结果晚上无论如何也睡不着。干躺了几个小时,干脆还是起来算了。

清晨小区里的鸟叫的不是一般的欢。不知道是什么鸟,反正这种鸟杭州特别多。

--EOF--

May 7, 2007

AIX RAW LVM 的 4k Offset 问题

这可能是 Oracle 在 AIX 平台上最重要的一个潜在问题。

一般情况下,AIX 的逻辑卷前 4k 用于存储 control block (LVCB),在 Oracle 9iR2 之前,Oracle 软件自动跳过这 4k 而不用。这带来了一个潜在的问题,当 Oracle 的 db_block_size 大于 4k 的时候,一个 Block 可能跨在两个 PV/LUN/磁盘 上(如果做了条带化,那么将总有数据块跨在两个条带上--其实也还是将跨在不同的 PV/LUN/磁盘上。这样当系统崩溃的时候,很有可能造成大量的 IO 不完整,一个 PV 上 IO 写入,另一边可能未完成,启动 Oracle 的时候将会看到 ORA-1578 错误,这几乎是致命的。

为了解决这个问题,AIX 推出了 Big Volume Groups 作为应对。建立 Big VG 后,创建 LV 的时候可以通过 -T O 的参数强制征用 LV 的前 4K 空间, LVCB 的信息保存在 VGDA(volume group describe area) 里面。前 4k 空间被使用的 LV 有了一个新的设备子类型(devsubtype)标记: DS_LVZ,通过 lslv 可以看到。(Oracle 也在 9.2.0.3 之后自动识别 AIX 的新 LV 类型,直接开始使用 LV 的前 4K 空间)

对于 AIX 的可扩展性 VG,则默认创建的 LV 就会 DS_LVZ 类型,不使用 -T O 也是这样子。Big VG 可能只是一个过度类型。

在 IBM 的系统手册中可以看到:

The IOCINFO ioctl operation returns the devinfo structure, as defined in the /usr/include/sys/devinfo.h file

如何知道当前裸设备创建的时候使用了 -TO ? Oracle 10g 的文档中说 $ORACLE_HOME/bin/offset 工具可以做到。可是我居然找不到这个工具。莫非是忽悠人来着? 通过另一个工具可以看到相关信息:

$ dbfsize /dev/rfoo01_pay
Database file: /dev/rfoo01_pay
Database file type: raw device without 4K starting offset
Database file size: 920 8192 byte blocks


要想得到完美的东西太难了, AIX 在 BIG VG 上仍然还有很多问题,目前已知的当属这个“MKLV -TO ON BIG VOLUME GROUPS FAILS TO PUT SOME LV INFORMATION”最为严重--得不到正确的devsubtype 类型,Oracle 则会报告读取数据文件头错误,这个更要人命。

DBA 这个工作,还真是脑袋悬在腰带上,风险莫测。

--EOF--

Updated: offset 命令工具需要安装 RAC 组件才可用,Oracle 另外提供了一个补丁来弥补这个问题,在 Patch 3242957 中可以找到,直接解压缩,把工具提取出来即可用。

本站相关标签|Tags Cloud