ORACLE DBA必备技能 – 使用OSWatcher(OSWBB)工具监控系统性能负载

QQ截图20140728134817

oswbb

 

 

 ORACLE DBA必备技能 – 使用OSWatcher工具监控系统性能负载.pdf

ORACLE DB数据库常见问题解决及诊断技巧集锦-ORACLE DBA故障修复必备手册

ORACLE DB数据库常见问题解决及诊断技巧集锦-ORACLE DBA故障修复必备手册下载

PRM for Oracle Database灾难恢复工具,Schema级别数据恢复。JAVA图形化界面版Oracle DUL

图片4

Oracle DBA神器:PRM灾难恢复工具,Schema级别数据恢复。PRM For Oracle Database – schema级别oracle数据库数据恢复特性 ,PRM即ParnassusData Recovery Manager是企业级别Oracle数据库灾难恢复工具。PRM可以在无备份的情况下恢复被truncated掉的表,也可以恢复无法打开的Oracle数据库(Alter Database Open失败)中的数据。 PRM是图形化增强版的Oracle DUL工具,同时具备很多Oracle DUL不具备的特性

#上海ORACLE用户组2014年高峰论坛#精彩瞬间

PRM – PARNASSUSDATA RECOVERY MANAGER For Oracle Database介绍手册

PRM – PARNASSUSDATA RECOVERY MANAGER For Oracle Database介绍手册下载:

 

PRM – ParnassusData Recovery Manager For Oracle Database, ParnassusData Software System提供,高效地恢复损坏ORACLE数据库中的数据。

 

PRM服务

 

PRM – ParnassusData Recovery Manager For Oracle Database,是由ParnassusData Software System(暨诗檀(上海)软件系统有限公司)独立研发的Oracle数据库灾难修复软件,拥有独立的软件著作权。用户可以购买PRM,通过其全程图形化交互的简单使用体验来自行恢复数据;用户也可以购买ParnassusData提供的Oracle数据库灾难恢复服务,由ParnassusData派遣专家级恢复工程师远程或现场协助用户应对数据库损坏难题。传统数据库损坏后的恢复总是需要资深数据库专家或者原厂专家的帮忙,但是PRM独创的高易用性恢复向导将恢复过程浓缩到简要的几个步骤,任何一个稍有基础的技术人员均可以独立完成恢复作业。由于PRM是直接从损坏数据库的数据文件中抽取数据,故其所做的读取是脏读。在没有充分备份条件下数据库灾难恢复的性质决定了任何软件工具不可能保证可以恢复100%一致的数据,但只要数据还没有被彻底覆盖,那么PRM可以保证恢复99.9%的数据。

 

 

PRM的优势

 

 

ParnassusData立志于提供更高效、简便的Oracle数据库灾难恢复产品:

 

  • 可以从无法打开的数据库中直接抽取Table和Cluster中的数据
  •   独创DataBridge模式将抽取出来的数据直接发送到目标数据库,无需用户费时费力再手动导入
  •   直接从数据文件中恢复数据,健壮度极强
  •   如果有SYSTEM表空间,适用于字典模式(Dict-Mode),提供图形化树形图预览数据
  •   如果丢失了SYSTEM表空间,通过PRM智能扫描同样可以轻松预览数据
  •   无需数据库完成介质恢复或崩溃恢复,即可绕过归档日志archivelog
  •   即便对于已经部分损坏的数据块,PRM仍能恢复其中的可用数据
  •   从ORACLE 9i到12c等多个版本均经过严格测试
  •    基于JAVA开发,最低软件要求为JDK 1.4,绿色无需安装,跨所有操作系统平台包括但不限于:常见Unix如AIX,HPUX ,Solaris, Linux(redhat、OEL、SUSE)以及Windows
  •   全面支持ASM

重整旗鼓

 

虽然我们可以通过PRM为用户克服数据库损坏难关,但数据库灾难恢复仍十分危险。ParnassusData拥有对ORACLE数据库备份恢复的丰富经验和解决方案,可以在用户有限的硬件资源条件下提供最实用的备份恢复方案,这些方案包括但不限于:DataGuard,物理或逻辑备份。ParnassusData将为用户在备份成本控制与备份有效性之间作出最佳平衡。

ParnassusData Recovery Manager For Oracle 白皮书(Version 0.2)

附件为临时的ParnassusData Recovery Manager For Oracle白皮书(Version 0.2),这个白皮书还在完善中,你可以把它当做一个临时的PRM使用手册。

 

prm-pic1_0

 下载ParnassusData Recovery Manager For Oracle社区版本,http://parnassusdata.com/d01/ParnassusData_PRMforOracle_2001.zip

 

 

ORACLE RAC节点意外重启Node Eviction诊断流程图

ORACLE RAC节点意外重启Node Eviction诊断流程图

 

oracle rac Node Evictions

ORACLE RAC clusterware/GI 启动诊断流程图

troubleshooting cluster startup

ORACLE RAC安装故障的诊断流程图

ORACLE RAC安装故障的诊断流程图

 

troubleshooting rac installation

OMF下Restore Oracle Datafile的优先级问题

OMF 即Oracle Managed Files   下管理的数据文件,如果 原数据文件存在 则会restore 到原数据文件的位置,如果不存在 则会restore到db_create_file_dest  指向的位置,详见如下测试:

 

restore的优先级如下:

  1. If “SET NEWNAME” is specified, RMAN will use that name for restore.
  2. If the original file exists, RMAN will use the original filename for restore.
  3. If the DB_CREATE_FILE_DEST is set, RMAN will use the diskgroup name specified.
  4. If no DB_CREATE_FILE_DEST is set and the original file does not exist, then RMAN will create another name
  5. for that file in the original disk group.                                          askmaclean.com

注意 只要 一旦使用“DB_CREATE_FILE_DEST有值” restore过数据文件,则 控制文件内容将被”污染” 变成指向新的DB_CREATE_FILE_DEST的文件位置。

 


SQL> show parameter db_create_file_dest

NAME TYPE
------------------------------------ ----------------------
VALUE
------------------------------
db_create_file_dest string
C:\APP\XIANGBLI\ORADATA




SQL> create tablespace test_omf datafile size 5M;

表空间已创建。

SQL> select name from v$datafile;

NAME
-----------------------------------------------------------------------------
C:\APP\XIANGBLI\ORADATA\MACLEAN\SYSTEM01.DBF
C:\APP\XIANGBLI\ORADATA\MACLEAN\EXAMPLE01.DBF
C:\APP\XIANGBLI\ORADATA\MACLEAN\SYSAUX01.DBF
C:\APP\XIANGBLI\ORADATA\MACLEAN\MACLEAN1.DBF
C:\APP\XIANGBLI\ORADATA\MACLEAN\UNDOTBS01.DBF
C:\APP\XIANGBLI\ORADATA\MACLEAN\USERS01.DBF
C:\APP\XIANGBLI\ORADATA\MACLEAN\ILM_PART1.DBF
C:\APP\XIANGBLI\ORADATA\MACLEAN\ILM_PART2.DBF
C:\APP\XIANGBLI\ORADATA\MACLEAN\LOW_COST_STORE.DBF
C:\APP\XIANGBLI\ORADATA\MACLEAN\SOURCE_TBS.DBF
C:\APP\XIANGBLI\PRODUCT\12.1.0\DBHOME_2\DATABASE\MISSING00011

NAME
-----------------------------------------------------------------------------
C:\APP\XIANGBLI\PRODUCT\12.1.0\DBHOME_2\DATABASE\MISSING00012
C:\APP\XIANGBLI\ORADATA\MACLEAN\DATAFILE\O1_MF_USERS_93RDWOBL_.DBF
C:\APP\XIANGBLI\ORADATA\MACLEAN\DATAFILE\O1_MF_TEST_OMF_93X25VFH_.DBF

已选择 14 行。





C:\Users\xiangbli>mkdir C:\APP\XIANGBLI\ORADATA1


SQL> alter system set db_create_file_dest='C:\APP\XIANGBLI\ORADATA1';

系统已更改。


RMAN> alter tablespace test_omf offline;

已处理语句




RMAN> backup tablespace test_omf;

RMAN> report schema;

db_unique_name 为 MACLEAN 的数据库的数据库方案报表

永久数据文件列表
===========================
文件大小 (MB) 表空间 回退段数据文件名称
---- -------- -------------------- ------- ------------------------
1 1117 SYSTEM *** C:\APP\XIANGBLI\ORADATA\MACLEAN\SYSTEM01.DBF
2 358 EXAMPLE *** C:\APP\XIANGBLI\ORADATA\MACLEAN\EXAMPLE01.DBF
3 1390 SYSAUX *** C:\APP\XIANGBLI\ORADATA\MACLEAN\SYSAUX01.DBF
4 10 ILM_DATA *** C:\APP\XIANGBLI\ORADATA\MACLEAN\MACLEAN1.DBF
5 725 UNDOTBS1 *** C:\APP\XIANGBLI\ORADATA\MACLEAN\UNDOTBS01.DBF
6 32763 USERS *** C:\APP\XIANGBLI\ORADATA\MACLEAN\USERS01.DBF
7 20 ILM_PART1 *** C:\APP\XIANGBLI\ORADATA\MACLEAN\ILM_PART1.DBF
8 20 ILM_PART2 *** C:\APP\XIANGBLI\ORADATA\MACLEAN\ILM_PART2.DBF
9 40 LOW_COST_STORE *** C:\APP\XIANGBLI\ORADATA\MACLEAN\LOW_COST_STORE.DBF
10 10 SRC_TBS *** C:\APP\XIANGBLI\ORADATA\MACLEAN\SOURCE_TBS.DBF
11 0 NONOMF *** C:\APP\XIANGBLI\PRODUCT\12.1.0\DBHOME_2\DATABASE\MISSING00011
12 0 LLV *** C:\APP\XIANGBLI\PRODUCT\12.1.0\DBHOME_2\DATABASE\MISSING00012
13 10 USERS *** C:\APP\XIANGBLI\ORADATA\MACLEAN\DATAFILE\O1_MF_USERS_93RDWOBL_.DBF
14 0 TEST_OMF *** C:\APP\XIANGBLI\ORADATA\MACLEAN\DATAFILE\O1_MF_TEST_OMF_93X25VFH_.DBF




RMAN> restore tablespace test_omf;

启动 restore 于 22-9月 -13
使用通道 ORA_DISK_1

正在略过数据文件 14; 已还原到文件 C:\APP\XIANGBLI\ORADATA\MACLEAN\DATAFILE\O1_MF_TEST_OMF_93X25VFH_.DBF
没有完成还原; 所有文件均为只读或脱机文件或者已经还原
完成 restore 于 22-9月 -13


RMAN> restore tablespace test_omf force;

启动 restore 于 22-9月 -13
使用通道 ORA_DISK_1

通道 ORA_DISK_1: 正在开始还原数据文件备份集
通道 ORA_DISK_1: 正在指定从备份集还原的数据文件
通道 ORA_DISK_1: 将数据文件 00014 还原到 C:\APP\XIANGBLI\ORADATA\MACLEAN\DATAFILE\O1_MF_TEST_OMF_93X25VFH_.DBF
通道 ORA_DISK_1: 正在读取备份片段 C:\APP\XIANGBLI\FAST_RECOVERY_AREA\MACLEAN\BACKUPSET\2013_09_22\O1_MF_NNNDF_TAG20130922T140621_93X26Y00_.BKP
通道 ORA_DISK_1: 段句柄 = C:\APP\XIANGBLI\FAST_RECOVERY_AREA\MACLEAN\BACKUPSET\2013_09_22\O1_MF_NNNDF_TAG20130922T140621_93X26Y00_.BKP 标记 = TAG20130922T14062
通道 ORA_DISK_1: 已还原备份片段 1
通道 ORA_DISK_1: 还原完成, 用时: 00:00:01
完成 restore 于 22-9月 -13



C:\Users\xiangbli>del C:\APP\XIANGBLI\ORADATA\MACLEAN\DATAFILE\O1_MF_TEST_OMF_93X25VFH_.DBF

这里还原到了C:\APP\XIANGBLI\ORADATA\MACLEAN\DATAFILE\O1_MF_TEST_OMF_93X25VFH_.DBF,由于数据文件本身存在

C:\Users\xiangbli>rman target /

恢复管理器: Release 12.1.0.1.0 - Production on 星期日 9月 22 14:07:21 2013

Copyright (c) 1982, 2013, Oracle and/or its affiliates. All rights reserved.

已连接到目标数据库: MACLEAN (DBID=1694338843)

RMAN> restore tablespace test_omf;

启动 restore 于 22-9月 -13
使用目标数据库控制文件替代恢复目录
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=20 设备类型=DISK

通道 ORA_DISK_1: 正在开始还原数据文件备份集
通道 ORA_DISK_1: 正在指定从备份集还原的数据文件
通道 ORA_DISK_1: 将数据文件 00014 还原到 C:\APP\XIANGBLI\ORADATA\MACLEAN\DATAFILE\O1_MF_TEST_OMF_93X25VFH_.DBF
通道 ORA_DISK_1: 正在读取备份片段 C:\APP\XIANGBLI\FAST_RECOVERY_AREA\MACLEAN\BACKUPSET\2013_09_22\O1_MF_NNNDF_TAG20130922T140621_93X26Y00_.BKP
通道 ORA_DISK_1: 段句柄 = C:\APP\XIANGBLI\FAST_RECOVERY_AREA\MACLEAN\BACKUPSET\2013_09_22\O1_MF_NNNDF_TAG20130922T140621_93X26Y00_.BKP 标记 = TAG20130922T14062
通道 ORA_DISK_1: 已还原备份片段 1
通道 ORA_DISK_1: 还原完成, 用时: 00:00:01
完成 restore 于 22-9月 -13


C:\Users\xiangbli>dir C:\APP\XIANGBLI\ORADATA\MACLEAN\DATAFILE\O1_MF_TEST_OMF_93X25VFH_.DBF
 驱动器 C 中的卷是 System
 卷的序列号是 C23A-ECDA

 C:\APP\XIANGBLI\ORADATA\MACLEAN\DATAFILE 的目录

找不到文件

C:\Users\xiangbli>dir C:\APP\XIANGBLI\ORADATA1\MACLEAN\DATAFILE\O1_MF_TEST_OMF_93X28YSV_.DBF
 驱动器 C 中的卷是 System
 卷的序列号是 C23A-ECDA

 C:\APP\XIANGBLI\ORADATA1\MACLEAN\DATAFILE 的目录

2013/09/22 14:07 5,251,072 O1_MF_TEST_OMF_93X28YSV_.DBF
 1 个文件 5,251,072 字节
 0 个目录 84,377,939,968 可用字节


 
 
RMAN> report schema;

使用目标数据库控制文件替代恢复目录
db_unique_name 为 MACLEAN 的数据库的数据库方案报表

永久数据文件列表
===========================
文件大小 (MB) 表空间 回退段数据文件名称
---- -------- -------------------- ------- ------------------------
1 1117 SYSTEM *** C:\APP\XIANGBLI\ORADATA\MACLEAN\SYSTEM01.DBF
2 358 EXAMPLE *** C:\APP\XIANGBLI\ORADATA\MACLEAN\EXAMPLE01.DBF
3 1390 SYSAUX *** C:\APP\XIANGBLI\ORADATA\MACLEAN\SYSAUX01.DBF
4 10 ILM_DATA *** C:\APP\XIANGBLI\ORADATA\MACLEAN\MACLEAN1.DBF
5 725 UNDOTBS1 *** C:\APP\XIANGBLI\ORADATA\MACLEAN\UNDOTBS01.DBF
6 32763 USERS *** C:\APP\XIANGBLI\ORADATA\MACLEAN\USERS01.DBF
7 20 ILM_PART1 *** C:\APP\XIANGBLI\ORADATA\MACLEAN\ILM_PART1.DBF
8 20 ILM_PART2 *** C:\APP\XIANGBLI\ORADATA\MACLEAN\ILM_PART2.DBF
9 40 LOW_COST_STORE *** C:\APP\XIANGBLI\ORADATA\MACLEAN\LOW_COST_STORE.DBF
10 10 SRC_TBS *** C:\APP\XIANGBLI\ORADATA\MACLEAN\SOURCE_TBS.DBF
11 0 NONOMF *** C:\APP\XIANGBLI\PRODUCT\12.1.0\DBHOME_2\DATABASE\MISSING00011
12 0 LLV *** C:\APP\XIANGBLI\PRODUCT\12.1.0\DBHOME_2\DATABASE\MISSING00012
13 10 USERS *** C:\APP\XIANGBLI\ORADATA\MACLEAN\DATAFILE\O1_MF_USERS_93RDWOBL_.DBF
14 0 TEST_OMF *** C:\APP\XIANGBLI\ORADATA1\MACLEAN\DATAFILE\O1_MF_TEST_OMF_93X28YSV_.DBF


这次还原到了C:\APP\XIANGBLI\ORADATA1\MACLEAN\DATAFILE\O1_MF_TEST_OMF_93X28YSV_.DBF



C:\Users\xiangbli>del C:\APP\XIANGBLI\ORADATA1\MACLEAN\DATAFILE\O1_MF_TEST_OMF_93X2MBCN_.DBF

【Oracle ASM】PST Partnership Status Table介绍

Partner and Status Table

相关:http://www.askmaclean.com/archives/know-oracle-asm-basic-html.html

一般来说aun=1 是保留给Partner and Status Table(PST)的拷贝使用的。 一般5个ASM DISK将包含一份PST拷贝。多数的PST内容必须相同且验证有效。否则无法判断哪些ASM DISK实际拥有相关数据。

在 PST中每一条记录对应Diskgroup中的一个ASM DISK。每一条记录会对一个ASM disk枚举其partners的ASM DISK。同时会有一个flag来表示该DISK是否是ONLINE可读写的。这些信息对recovery是否能做很重要。

PST表的Blkn=0是PST的header,存放了如下的信息:

  • Timestamp to indicate PST is valid
  • Version number to compare with other PST copies
  • List of disks containing PST copies
  • Bit map for shadow paging updates

PST的最后一个块是heartbeat block,当diskgroup mount时其每3秒心跳更新一次。

以下为PST header

kfed read /oracleasm/asm-disk01 aun=1 blkn=0 aus=4194304 |less 

kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                           17 ; 0x002: KFBTYP_PST_META
kfbh.datfmt:                          2 ; 0x003: 0x02
kfbh.block.blk:                    1024 ; 0x004: blk=1024
kfbh.block.obj:              2147483648 ; 0x008: disk=0
kfbh.check:                  3813974007 ; 0x00c: 0xe3549ff7
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdpHdrPairBv1.first.super.time.hi:32999670 ; 0x000: HOUR=0x16 DAYS=0x7 MNTH=0x2 YEAR=0x7de
kfdpHdrPairBv1.first.super.time.lo:1788841984 ; 0x004: USEC=0x0 MSEC=0x3e4 SECS=0x29 MINS=0x1a
kfdpHdrPairBv1.first.super.last:      2 ; 0x008: 0x00000002
kfdpHdrPairBv1.first.super.next:      2 ; 0x00c: 0x00000002
kfdpHdrPairBv1.first.super.copyCnt:   5 ; 0x010: 0x05
kfdpHdrPairBv1.first.super.version:   1 ; 0x011: 0x01
kfdpHdrPairBv1.first.super.ub2spare:  0 ; 0x012: 0x0000
kfdpHdrPairBv1.first.super.incarn:    1 ; 0x014: 0x00000001
kfdpHdrPairBv1.first.super.copy[0]:   0 ; 0x018: 0x0000
kfdpHdrPairBv1.first.super.copy[1]:   1 ; 0x01a: 0x0001
kfdpHdrPairBv1.first.super.copy[2]:   2 ; 0x01c: 0x0002
kfdpHdrPairBv1.first.super.copy[3]:   3 ; 0x01e: 0x0003
kfdpHdrPairBv1.first.super.copy[4]:   4 ; 0x020: 0x0004
kfdpHdrPairBv1.first.super.dtaSz:    15 ; 0x022: 0x000f
kfdpHdrPairBv1.first.asmCompat:186646528 ; 0x024: 0x0b200000
kfdpHdrPairBv1.first.newCopy[0]:      0 ; 0x028: 0x0000
kfdpHdrPairBv1.first.newCopy[1]:      0 ; 0x02a: 0x0000
kfdpHdrPairBv1.first.newCopy[2]:      0 ; 0x02c: 0x0000
kfdpHdrPairBv1.first.newCopy[3]:      0 ; 0x02e: 0x0000
kfdpHdrPairBv1.first.newCopy[4]:      0 ; 0x030: 0x0000
kfdpHdrPairBv1.first.newCopyCnt:      0 ; 0x032: 0x00
kfdpHdrPairBv1.first.contType:        1 ; 0x033: 0x01
kfdpHdrPairBv1.first.spares[0]:       0 ; 0x034: 0x00000000
kfdpHdrPairBv1.first.spares[1]:       0 ; 0x038: 0x00000000
kfdpHdrPairBv1.first.spares[2]:       0 ; 0x03c: 0x00000000
kfdpHdrPairBv1.first.spares[3]:       0 ; 0x040: 0x00000000
kfdpHdrPairBv1.first.spares[4]:       0 ; 0x044: 0x00000000
kfdpHdrPairBv1.first.spares[5]:       0 ; 0x048: 0x00000000
kfdpHdrPairBv1.first.spares[6]:       0 ; 0x04c: 0x00000000
kfdpHdrPairBv1.first.spares[7]:       0 ; 0x050: 0x00000000
kfdpHdrPairBv1.first.spares[8]:       0 ; 0x054: 0x00000000
kfdpHdrPairBv1.first.spares[9]:       0 ; 0x058: 0x00000000
kfdpHdrPairBv1.first.spares[10]:      0 ; 0x05c: 0x00000000
kfdpHdrPairBv1.first.spares[11]:      0 ; 0x060: 0x00000000
kfdpHdrPairBv1.first.spares[12]:      0 ; 0x064: 0x00000000
kfdpHdrPairBv1.first.spares[13]:      0 ; 0x068: 0x00000000
kfdpHdrPairBv1.first.spares[14]:      0 ; 0x06c: 0x00000000
kfdpHdrPairBv1.first.spares[15]:      0 ; 0x070: 0x00000000
kfdpHdrPairBv1.first.spares[16]:      0 ; 0x074: 0x00000000
kfdpHdrPairBv1.first.spares[17]:      0 ; 0x078: 0x00000000
kfdpHdrPairBv1.first.spares[18]:      0 ; 0x07c: 0x00000000
kfdpHdrPairBv1.first.spares[19]:      0 ; 0x080: 0x00000000

  • super.time wall clock time of last PST commit
  • super.last  last committed content version number
  • super.next next available content version number
  • super.copyCnt  # of disks holding PST copies
  • super.version   version of PST header format
  • super.ub2spare  pad to ub4 align
  • super.incarn incarnation of <copy> list
  • super.copy[0]  disks holding the PST copies
  • super.dtaSz  data entries in PST
  • newCopy[0]   new disks holding PST copies
  • newCopyCnt  new # disks holding PST copies

以下为PST table block:

kfed read /oracleasm/asm-disk02 aun=1 blkn=3 aus=4194304 |less 

kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                           18 ; 0x002: KFBTYP_PST_DTA
kfbh.datfmt:                          2 ; 0x003: 0x02
kfbh.block.blk:                    1027 ; 0x004: blk=1027
kfbh.block.obj:              2147483649 ; 0x008: disk=1
kfbh.check:                  4204644293 ; 0x00c: 0xfa9dc7c5
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdpDtaEv1[0].status:               127 ; 0x000: I=1 V=1 V=1 P=1 P=1 A=1 D=1
kfdpDtaEv1[0].fgNum:                  1 ; 0x002: 0x0001
kfdpDtaEv1[0].addTs:         2022663849 ; 0x004: 0x788f66a9
kfdpDtaEv1[0].partner[0]:         49154 ; 0x008: P=1 P=1 PART=0x2
kfdpDtaEv1[0].partner[1]:         49153 ; 0x00a: P=1 P=1 PART=0x1
kfdpDtaEv1[0].partner[2]:         49155 ; 0x00c: P=1 P=1 PART=0x3
kfdpDtaEv1[0].partner[3]:         49166 ; 0x00e: P=1 P=1 PART=0xe
kfdpDtaEv1[0].partner[4]:         49165 ; 0x010: P=1 P=1 PART=0xd
kfdpDtaEv1[0].partner[5]:         49164 ; 0x012: P=1 P=1 PART=0xc
kfdpDtaEv1[0].partner[6]:         49156 ; 0x014: P=1 P=1 PART=0x4
kfdpDtaEv1[0].partner[7]:         49163 ; 0x016: P=1 P=1 PART=0xb
kfdpDtaEv1[0].partner[8]:         10000 ; 0x018: P=0 P=0 PART=0x2710
kfdpDtaEv1[0].partner[9]:             0 ; 0x01a: P=0 P=0 PART=0x0
kfdpDtaEv1[0].partner[10]:            0 ; 0x01c: P=0 P=0 PART=0x0
kfdpDtaEv1[0].partner[11]:            0 ; 0x01e: P=0 P=0 PART=0x0
kfdpDtaEv1[0].partner[12]:            0 ; 0x020: P=0 P=0 PART=0x0
kfdpDtaEv1[0].partner[13]:            0 ; 0x022: P=0 P=0 PART=0x0
kfdpDtaEv1[0].partner[14]:            0 ; 0x024: P=0 P=0 PART=0x0
kfdpDtaEv1[0].partner[15]:            0 ; 0x026: P=0 P=0 PART=0x0
kfdpDtaEv1[0].partner[16]:            0 ; 0x028: P=0 P=0 PART=0x0
kfdpDtaEv1[0].partner[17]:            0 ; 0x02a: P=0 P=0 PART=0x0
kfdpDtaEv1[0].partner[18]:            0 ; 0x02c: P=0 P=0 PART=0x0
kfdpDtaEv1[0].partner[19]:            0 ; 0x02e: P=0 P=0 PART=0x0
kfdpDtaEv1[1].status:               127 ; 0x030: I=1 V=1 V=1 P=1 P=1 A=1 D=1
kfdpDtaEv1[1].fgNum:                  2 ; 0x032: 0x0002
kfdpDtaEv1[1].addTs:         2022663849 ; 0x034: 0x788f66a9
kfdpDtaEv1[1].partner[0]:         49155 ; 0x038: P=1 P=1 PART=0x3
kfdpDtaEv1[1].partner[1]:         49152 ; 0x03a: P=1 P=1 PART=0x0
kfdpDtaEv1[1].partner[2]:         49154 ; 0x03c: P=1 P=1 PART=0x2
kfdpDtaEv1[1].partner[3]:         49166 ; 0x03e: P=1 P=1 PART=0xe
kfdpDtaEv1[1].partner[4]:         49157 ; 0x040: P=1 P=1 PART=0x5
kfdpDtaEv1[1].partner[5]:         49156 ; 0x042: P=1 P=1 PART=0x4
kfdpDtaEv1[1].partner[6]:         49165 ; 0x044: P=1 P=1 PART=0xd
kfdpDtaEv1[1].partner[7]:         49164 ; 0x046: P=1 P=1 PART=0xc
kfdpDtaEv1[1].partner[8]:         10000 ; 0x048: P=0 P=0 PART=0x2710
kfdpDtaEv1[1].partner[9]:             0 ; 0x04a: P=0 P=0 PART=0x0
kfdpDtaEv1[1].partner[10]:            0 ; 0x04c: P=0 P=0 PART=0x0
kfdpDtaEv1[1].partner[11]:            0 ; 0x04e: P=0 P=0 PART=0x0
kfdpDtaEv1[1].partner[12]:            0 ; 0x050: P=0 P=0 PART=0x0
kfdpDtaEv1[1].partner[13]:            0 ; 0x052: P=0 P=0 PART=0x0
kfdpDtaEv1[1].partner[14]:            0 ; 0x054: P=0 P=0 PART=0x0
kfdpDtaEv1[1].partner[15]:            0 ; 0x056: P=0 P=0 PART=0x0
kfdpDtaEv1[1].partner[16]:            0 ; 0x058: P=0 P=0 PART=0x0

  • kfdpDtaEv1[0].status: 127 ; 0×000: I=1 V=1 V=1 P=1 P=1 A=1 D=1 disk status
  • fgNum   fail group number
  • addTs   timestamp of the addition to the diskgroup
  • kfdpDtaEv1[0].partner[0]:         49154 ; 0×008: P=1 P=1 PART=0×2  partner list

aun=1 的最后第二个block中备份了一份KFBTYP_DISKHEAD

[oracle@mlab2 hzy]$ kfed read /oracleasm/asm-disk02 aun=1 blkn=1022 aus=4194304 |less  
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                    1022 ; 0x004: blk=1022
kfbh.block.obj:              2147483649 ; 0x008: disk=1
kfbh.check:                  3107059260 ; 0x00c: 0xb931f63c
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdhdb.driver.provstr:         ORCLDISK ; 0x000: length=8
kfdhdb.driver.reserved[0]:            0 ; 0x008: 0x00000000
kfdhdb.driver.reserved[1]:            0 ; 0x00c: 0x00000000
kfdhdb.driver.reserved[2]:            0 ; 0x010: 0x00000000
kfdhdb.driver.reserved[3]:            0 ; 0x014: 0x00000000
kfdhdb.driver.reserved[4]:            0 ; 0x018: 0x00000000
kfdhdb.driver.reserved[5]:            0 ; 0x01c: 0x00000000
kfdhdb.compat:                186646528 ; 0x020: 0x0b200000
kfdhdb.dsknum:                        1 ; 0x024: 0x0001
kfdhdb.grptyp:                        3 ; 0x026: KFDGTP_HIGH
kfdhdb.hdrsts:                        3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname:              DATA1_0001 ; 0x028: length=10
kfdhdb.grpname:                   DATA1 ; 0x048: length=5
kfdhdb.fgname:               DATA1_0001 ; 0x068: length=10
kfdhdb.capname:                         ; 0x088: length=0
kfdhdb.crestmp.hi:             32999670 ; 0x0a8: HOUR=0x16 DAYS=0x7 MNTH=0x2 YEAR=0x7de
kfdhdb.crestmp.lo:           1788720128 ; 0x0ac: USEC=0x0 MSEC=0x36d SECS=0x29 MINS=0x1a
kfdhdb.mntstmp.hi:             32999670 ; 0x0b0: HOUR=0x16 DAYS=0x7 MNTH=0x2 YEAR=0x7de
kfdhdb.mntstmp.lo:           1812990976 ; 0x0b4: USEC=0x0 MSEC=0x3 SECS=0x1 MINS=0x1b
kfdhdb.secsize:                     512 ; 0x0b8: 0x0200
kfdhdb.blksize:                    4096 ; 0x0ba: 0x1000
kfdhdb.ausize:                  4194304 ; 0x0bc: 0x00400000

AUN=1 的最后一个block为KFBTYP_HBEAT 心跳表:

[oracle@mlab2 hzy]$ kfed read /oracleasm/asm-disk02 aun=1 blkn=1023 aus=4194304 |less  
kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                           19 ; 0x002: KFBTYP_HBEAT
kfbh.datfmt:                          2 ; 0x003: 0x02
kfbh.block.blk:                    2047 ; 0x004: blk=2047
kfbh.block.obj:              2147483649 ; 0x008: disk=1
kfbh.check:                  1479766671 ; 0x00c: 0x5833728f
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdpHbeatB.instance:                  1 ; 0x000: 0x00000001
kfdpHbeatB.ts.hi:              32999734 ; 0x004: HOUR=0x16 DAYS=0x9 MNTH=0x2 YEAR=0x7de
kfdpHbeatB.ts.lo:            3968041984 ; 0x008: USEC=0x0 MSEC=0xe1 SECS=0x8 MINS=0x3b
kfdpHbeatB.rnd[0]:           1065296177 ; 0x00c: 0x3f7f2131
kfdpHbeatB.rnd[1]:            857037208 ; 0x010: 0x33155998
kfdpHbeatB.rnd[2]:           2779184235 ; 0x014: 0xa5a6fc6b
kfdpHbeatB.rnd[3]:           2660793989 ; 0x018: 0x9e987e85

  • kfdpHbeatB.instance   instance id
  • kfdpHbeatB.ts.hi timestamp
  • kfdpHbeatB.rnd[0]  随机加盐

  •  External Redundancy一般有一个PST
  • Normal Redundancy至多有个3个PST
  • High Redundancy 至多有5个PST

如下场景中PST 可能被重定位:

  • 存有PST的ASM DISK不可用了(当ASM启东时)
  • ASM DISK OFFLINE了
  • 当对PST的读写发生了I/O错误
  • disk被正常DROP了

  •  在读取其他ASM metadata之前会先检查PST
  • 当ASM实例被要求mount diskgroup时,GMON进程会读取diskgroup中所有磁盘去找到和确认PST拷贝
  • 如果他发现有足够的PST,那么会mount diskgroup
  • 之后,PST会被缓存在ASM缓存中,以及GMON的PGA中并使用排他的PT.n.0锁保护
  • 同集群中的其他ASM实例也将缓存PST到GMON的PGA,并使用共享PT.n.o锁保护
  • 仅仅那个持有排他锁的GMON能更新磁盘上的PST信息
  • 每一个ASM DISK上的AUN=1均为PST保留,但只有几个磁盘上真的有PST数据

 

kfbh.endian
kf3.h /*endiannessofwriter*/

Little endian = 1 Big endian = 0

kfbh.hard
kf3.h /*H.A.R.D.magic#andblocksize*/

kfbh.type
kf3.h /* metadata block type */

kfbh.datfmt
kf3.h /*metadatablockdataformat */

kfbh.block
kf3.h /*blocklocationofthisblock */

blk — Disk header should have T=0 and NUMB=0×0

obj — Disk header should have TYPE=0×8 NUMB=<disknumber> blkandobjvaluesarederivedfromaseriesofmacrosinkf3.h. See “KFBL Macros” in kf3.h for more information.

kfbh.check
kf3.h /*checkvaluetoverifyconsistency*/

kfbh.fcn
kf3.h /*changenumberoflastchange */

kfdpHdrB.time.hi
kf3.h HiorderedbitsfromthelastcommittedPSTupdate

kfdpHdrB.time.lo
kf3.h LoworderedbitsfromthelastcommittedPSTupdate

kfdpHdrB.last
kf3.h /* last version number */

kfdpHdrB.next
kf3.h /* next version number */

kfdpHdrB.copyCnt
kf3.h /* # of PST copies */

This defaults to “1″ for external redundancy, “3″ for normal redundancy and”5″forhighredundancy. Ifthenumberoffailuregroupsisless than the default value, the number failure groups is the value used.

kfdpHdrB.incarn
kf3.h /* incarnation of <copy> */

This is set to kfdpHdrB.last when the PST is moved to another disk.

kfdpHdrB.copy[0-4]
kf3.h /* disks holding the PST copies */

[0] — external redundancy [0-2] –normalredundancy [0-4] –highredundancy

kfdpHdrB.dtaSz
kf3.h /*#dtaentriesinPST */

This is the number of disks that it needs to keep track of. ub1[0-4027]

【Oracle ASM数据恢复】ORA-00600 [KFRVALACD30]错误解析

【Oracle ASM数据恢复】ORA-00600 [KFRVALACD30]错误解析,某用户遇到ORA-00600 [kfrValAcd30]错误 且导致无法打开ASM实例,之前用户有断电重启过操作系统。

该错误的stack call如下:

 

如果自己搞不定可以找诗檀软件专业ORACLE数据库修复团队成员帮您恢复!

诗檀软件专业数据库修复团队

服务热线 : 400-690-3643   备用电话: 18501767907    邮箱:service@parnassusdata.com

STACK TRACE:
————
skdstdst <- ksedst1 <- ksedst <- dbkedDefDump <- ksedmp
<- ksfdmp <- dbgexPhaseII <- dbgexProcessError <- dbgeExecuteForError
<- dbgePostErrorKGE
<- 1615 <- dbkePostKGE_kgsf <- kgeadse <- kgerinv_internal <-
kgerinv
<- kgeasnmierr <- kfrValAcd <- kfrgnr <- kfrgnc <- kfrPass1
<- kfrcrv <- kfcMountPriv <- kfcMount <- kfgInitCache <-
kfgFinalizeMount
<- 2149 <- kfgscFinalize <- kfgForEachKfgsc <- kfgsoFinalize <-
kfgFinalize
<- kfxdrvMount <- kfxdrvEntry <- opiexe <- opiosq0 <- kpooprx
<- kpoal8 <- opiodr <- ttcpip <- opitsk <- opiino
<- opiodr <- opidrv <- sou2o <- opimai_real <- ssthrdmain
<- main <- libc_start_main <- start

kfrValAcd Reap the current log read I/O.

 

该错误的原因是当recovery diskgroup时,发现ACD记录的seq=111,而实际ACD记录的seq=6

 

针对该问题 我们可以通过 PRM工具来抽取该问题diskgroup中的数据文件,并重建Diskgroup。

关于PRM FOR ORACLE 详见 http://parnassusdata.com/

PRM-DUL for oracle恢复被truncate截断掉的表

PRM DUL for oracle恢复被truncate截断掉的表 Oracle DBA神器:PRM灾难恢复工具,Schema级别数据恢复。PRM For Oracle Database – schema级别oracle数据库数据恢复特性 ,PRM即ParnassusData Recovery Manager是企业级别Oracle数据库灾难恢复工具。PRM可以在无备份的情况下恢复被truncated/drop掉的表,也可以恢复无法打开的Oracle数据库(Alter Database Open失败)中的数据。 PRM是图形化增强版的Oracle DUL工具,同时具备很多Oracle DUL不具备的特性

 

 

【转】在Oracle甲骨文中国工作是怎样一番体验?

本文转自 http://www.zhihu.com/question/24674501

 

换过好几家公司,包括国内叼丝小企业(半死不活15年历史),也待过其他大外企(18摸),也待过伪外企(美国人开的,全部员工在深圳,三分之一印度佬)。 本人经历有点多,说话有点直,以下言论必定让某些人不爽,姑且看看吧,喷我随意。
—————————————————————————————————————————————–
看甲骨文,你得分几个维度,千万不要把甲骨文当成一家公司。(实际上和IBM在中国实际上是由5家以上的子公司组成的道理一样,甲骨文是由两家公司组成的)

  1. 甲骨文全球有18万员工,除了美国,印度最大(3万人),中国应该不超过5000,所以印度也是我们的老板。 这一点和最近裁员诺基亚不一样(中国主力研发),甲骨文数据库的主要研发是在美国,ERP的研发是在印度(事实上EBS是甲骨文20年前收购的印度公司)。中国研发啥呢?研发一些花边技术吧,或者给他们修一修bug。一定要认清楚EBS的重要,不仅仅是世界第二大ERP,也是甲骨文第二大的现金流来源(有些时候甚至超过Oralce DB!),国内腾讯,以前阿里,广发,招商,等等都是用的EBS(没错,就是那个难用得要死的报销休假采购系统)
  2. 另外一个划分标准是甲骨文分两家法人甲骨文研究开发中心有限公司,和甲骨文有限公司。前者是研发,后者是销售。销售也要技术,做售前售后,都是技术。同样的技术能力,去了后者工资是前者的2-4倍,并且,后者出差一天算一天调休,理论上一年最多180天调休。而前者的工资就是勉强比IBM GDC高点。
  3. 第三个维度就是,北京的研发,和深圳苏州的研发。北京是研发所谓的业界前沿技术(不代表甲骨文的研究成果就前沿了,哈哈),但是甲骨文不擅长的东西,比如说云啦,大数据啦(如果是收购的SUN和BEA的研发,北京也有,我不了解,可以参考EBS组的情况)。苏州深圳,就是EBS(世界排名第二的ERP,仅次于SAP)的支持。苏州这个点新开的,之前不存在。除了几个点以外的甲骨文公司,肯定都不是研发,而是销售。甲骨文研发根本不需要出差。真需要在一起,也是经理买个机票从美国飞过来坐你旁边,而不是你飞过去……

以下针对深圳苏州的以及部分北京的甲骨文研究开发中心子公司的员工:

甲骨文(北京部分岗位除外)的研发,工作还是比较轻松的,因为甲骨文的研究开发中心的工资竞争力不够,所以留人的办法主要是靠Work From Home。我观察,很多人每工作满一年,在家工作时间每周增加一天,也就是说你混得好,甲骨文待5年你就不必来公司上班了。有几个传说中的team,我就不点名了,一年我也就能见到几次(他们真的是和我们工作在一层楼么?!)有些组,带头大姐修个产假,回来也照样升职。我在甲骨文认识的很多大哥,都回什么广安啦、珲春啦、包头啦,在家上班去了。

至于研发到底做了啥事?我不是不承认真的有开发,但是主要还是改bug吧。要不要加班?忙起来还真要,不过一年估计就忙1-2个月吧。其他时间,某些人都选择在家……某些人还是选择来公司,不然都不好玩了…

甲骨文可能是整个IT业界,最后一个使用瀑布开发流程的公司了(据说连邪恶的微软都敏捷了……)。严格按照需求分析,概要设计,详细设计……开发人员嘛,把详细设计的代码复制黏贴出来差不多了,然后主要的工作是测试呗(所以导致fixbug的技术含量更高,fix得好了,转岗去干销售double pay走起)。有一堆惨无人道难用到极点的内部软件,有一堆完全没有任何必要的流程。导致的结果是,每天平均代码大概十多行吧。你还别急,快不了。开发一天,走流程到最终合并进去需要1-2周。1-2年才能出一个版本。那个版本,估计三个月开放几天时间给你提交代码。里面几乎所有的的都不是用的开源,难用到极点。

以下针对深圳苏州的以及部分上海北京的甲骨文子公司的员工:

裁员经常裁他们,因为他们比较贵。很多人出差到华为、华润之类的客户公司。只有研发的“精英”才能去(数据库的话有ACE吧,EBS的话起码懂1.6万张表中的3000-4000张吧)。其实接触过,感觉这些人真正的特点是头脑灵活,像我一样(嘻嘻,感觉自己萌萌达)。这群人其实更像Business Analysis。

以下针对深圳北京的看家本领研发(DB):

如果是开发,听说必须是清华北大上交复旦和北邮五所学校读过本科才能进,但是同时得有硕士学历。当然斯坦福、MIT什么的也行。如果是测试或者支持要求低一点。

针对global pay的员工来说:

他们只是来中国旅游上班的。每年要回美国几个月,这样绿卡不会丢。通常看家本领的开发,都是global pay。

——————————————–补充三点———————————————————————————–
1. 我忘记iflex/flexcube team这个广泛的存在了
iflex也是收购的印度的银行外包公司,和TCS infosys 等齐名。印度外包福利很好的也是16天年假,补充医疗保险,20天病假之类,所以收购进来福利和甲骨文没区别。iflex研发,其实也没研发啥东西,人力外包嘛。国内做做平安银行啥的,有些人需要到客户单位上班吧。其实HP啥的也早干这一行和IBM抢外包生意咯。

2. 甲骨文非常喜欢招到了生育年龄结婚了准备生小孩的女性
因为外企的工资10年来没啥增长,某些team男人全部走光,招这样的女人这样就不会lose head count。而且说实在的也不需要你做啥,一天几行代码……一边抱孩子一边在家vpn写,难度比换尿布还小点吧。

3. 甲骨文招人学历确实很重要很重要,以下只针对99%的情况
注意:如果你是天生神力,小学辍学,自学英语计算机,然后写得代码比linus 高司令都好。你就是那个1%的情况。
起码你得是个计算机相关专业的硕士吧,本科不是不可以概率比较小而已。不是985毕业的不是不可能,就是概率比较小(某些组对学历更挑剔)。英语得好吧,要知道有些组可能全球就你一个人在中国,老板是印度人或者美国人。不懂英语,混个毛线啊。
—————————————————————————————————-
终于有人对我上面的文字提出不同意见了,非常好。我看了一下,集中在于肯定事实,但是否定我的“心态”。而且大多数是毕业就来了甲骨文的后生,我真的为他们感到担心。
—————————————————————————————————-
甲骨文这一套方法就是传统的瀑布流开发方法,基本上是20年以前的思想。别的不说,这一套方法论彻底落后彻底过时了。世界潮流,顺之则昌,逆之则亡啊!所以说,最害人的就是刚毕业的应届生进入甲骨文,很多大学的教材本身就陈旧,再刚毕业就彻底实践,我真担心这个歧路会走太远。我都不直接推荐你看scrum的书,你去看看《人月神话》《大教堂和市集》。每天平均十行代码,甚至几个月一行代码,这只是表象,深层原因是方法论彻底错了。人月神话说得很清楚,团队里面人与人的沟通是全连接,所以是N!的连接。EBS的团队都到了几千人,能够开发出软件而不失败简直就是奇迹。所以一天能有十行代码真的是阿弥陀佛了。
(话说我们当年也用TDD,TDD到了啥程度?就是详细设计的文档取名为TDD文档。我这个真做过TDD的人,当时一口老血啊%…………)

说来甲骨文可以学到流程,这样代码质量高,是鬼扯。代码质量高,还养了一千人修bug?某些java代码,我真的看了无语得很,印度的java代码尤其烂到家了。有文档不代表代码质量高,流程多和复杂更不代表代码质量高。这是错误的方法,你还学,大错特错。

個人與互動 重於 流程與工具 
可用的軟體 重於 詳盡的文件 
與客戶合作 重於 合約協商 
回應變化 重於 遵循計劃

EBS确实牛,ERP老二,和SAP分享全球30%的企业所有信息系统。但是也要知道有垂直ERP,他们没有几千人开发30年,他们就几十个人上百人,开发周期一年,一周一个迭代,出来的ERP不比EBS简单。他们每个人的代码产出可能是甲骨文的十倍百倍,这就是敏捷。在一个敏捷团队里面,开发人员才是主角。而不是PM是主角,而不是直接从详细设计里面复制代码出来粘贴。

社会人员入职甲骨文还是可以的。成家了,等等原因。需要平衡一下工作和生活。而且,如此轻松自己去兼职也是很自然的事情。此外,你真熟悉了产品,转到好的客户单位去也很厉害。很多甲骨文的人转华为、广发等等,基本上年薪也达到或者超过BAT同等年龄的人。关键是你的付出不多,收益太大,一个字——值!

至于工作环境,还算中上(强于IBM)。椅子不错,但不是Herman Miller的。锤子手机和腾讯(不是所有)都是Herman Miller。电话机思科的IP-Phone,估计也值个几千吧。办公室有些发霉的味道,没办法,都是高隔间又不能随便开窗户,租的楼中规中矩,楼下就是腾讯。

甲骨文人事经理的权力很大,所谓的team building fee,碰到某些奸诈的就被污了,搞得大家士气都很低下。真正靠谱的福利就是住房公积金(可以超越国企了)+补充医疗保险+1450,生日有电影票。至于啥十万的培训费,一般不会批的吧,看经理。买书报销也要看经理。

民营企业确实有些三观不正的,有的老总总喜欢渲染自己是半人半神,有的老总喜欢办公室挂一个野战地图插红旗要占领全国(挂世界地图的也有),在深圳更多的是毛主席头像。不过,正常的也很多。最关键的是,自己不要被自己的侨情给害了。如果是小公司,你啥都可以和老总谈的。现在很多创业公司MBP都是标配了。我对东西是很picky的,作为一个程序员你有啥理由不给自己上HHKB和4K显示器?以前就在我的强烈建议下,叫总经理买了现磨咖啡机。(如果不给买,我自己买带公司,离职后带走,看他面子上挂得住么?)

 

 

 

分割线


 

 

受邀请回答此题,时间突然像回到了两年前,那时准备选择我毕业第一份工作的时候。那时候我求助过知乎,可惜没有相关的问题,或许当年有这样的问题,今天的我,会有怎么样的不同?

坦白地说,而排名第一的回答大部分都是事实,只是回答过于消极以及情绪化,带有极强的负能量,欠客观。或者说,只挑选了我们工作中最为不满的一方面以带有情绪的方式述说。

以下把自己这一年多来的体验一点点的说起。

注:以下观点只代表Oracle在深圳的亚洲研发中心,其未必适用于所有Oracle在中国的所有研发中心,更可能不适用在销售、培训等的子公司。

——————————–体验篇——————————-
“工作体验”其中最重要的应该数是工作其中你的身体、心灵的感受。在这一点上,Oracle是一个极为舒适的地方。这也应该是题主最为关心的一个部分。

  • 工作环境:

第一个我想说的,是工作的环境。
有一个很小的细节很多人都没有提到,那就是地毯。办公楼的办公区铺着一个厚厚的地毯,这样做有一个最明显的效果是,附近的人走来走去,你听不到脚步声。所以一天下来,你能听到的是只有强烈的键盘敲打声,给员工的打扰极低,一天下来工作效率可以在无干扰环境中大幅提高。我曾经在广州某互联网公司实习过,那里号称有极好的工作氛围和环境,但是在那,只有极为狭窄的工作区间(像网吧一样),人来人往、讨论声、争吵声、脚步声充斥在你附近,这种环境下对于根法集中精力思考和写代码都是很强的干扰。

以下图中能看到的都是我的办公区间,我只是一个应届本科毕业,最低级别的研发岗位,但依旧拥有着

  • 极为广阔的工作位置。
  • 一部高配置手提电脑+液晶屏
  • 一个互联网电话(可免费打国内外所有电话),并且电脑也有此相关软件,可在家连VPN免费打电话回家




  • 人文关怀

根据怪诞行为学 (豆瓣) 中的观点,“社会规范”远比“市场规范”更容易培养员工的”忠诚度“,以及模糊工作与生活的界限。
在这一点上,Oracle可谓做得十分出色,我认为,这体现了美国人(欧洲人)享受生活的生活/工作态度。(相反,国内很多公司只把员工当机器、资源,企图榨出所有的价值。)

  • 所有员工从入职一天起就每年有16天的带薪年假,并且随着工作年限增加。
  • 所有员工每月两天的带薪病假。以及相关产假,陪产假等(具体几天忘了)。
  • 为员工购买额外商业医疗保险,看病全额报销(先刷医保,再报销。相当于医保体现)。员工子女也能享受报销一半的福利。
  • 洗牙、看眼、购买药品有1450的额外报销费用。
  • 上下班不打卡,并且工作时间自由分配。如果昨天晚上睡太晚或者失眠太累,直接睡多一个小时再上班,也是完全没有问题。下班也可以提早走,和经理简单说下基本都没问题。例如女朋友要过来、赶车回家,4点多走都是我经常干出来的事:)。
  • 员工可以申请work from home。这点是极少公司可以办到的。这对于员工,特别是拥有家庭的员工极为具有吸引力。我有一个同事,研究生毕业一年后来到了深圳,妻子和刚出生孩子都在广州,之前一直每周往返广州、深圳两地。今年申请通过了,直接在广州办公。除了极少时候需要办理某些手续才会过来深圳的公司。普通员工也可以时不时就在家办公,像我试过几次在短假期回家由于赶车麻烦直接申请在家办公一天。我的经理去年某一段时间由于需要家里某些原因也在家办公了一个多星期。


公司这样的关怀很大程度上增加了员工的忠诚度,并且模糊了工作与生活的界限。有些人可能会认为这样的制度会使工作时间大幅度缩水(例如我就试过好几次11点上班5 6点走),但其实很多员工的工作效率极高,并且回家之后依旧可以继续工作,这一定程度上把工作的时间提回来(像我的经理经常上班前在家收发邮件,回到家也看他挂着IM),并且模糊了一个人的生活状态——工作与生活似乎没那么明确了。简单说,就是舒适得舒适。这也是很多员工即使在薪水竞争力低的情况下不离开公司的原因。

  • 员工活动

Oracle还有一个吸引人的地方在于其中的“Social Club”。公司每年会有一批经费进行组织员工的相关活动,由员工自己建立相关俱乐部,并由会长进行组织(可以做到每天都有不同的活动)。员工免费参加,像羽毛球、网球、篮球、足球、健身、游泳、跳舞、瑜伽、cooking、唱K、攀岩 等等。
像我现在每周二、周四会去健身(有游泳池),周五可能会去唱K,周末如果有什么特殊的活动也会去参加。

  • 其余小事:
    • 茶水间有免费咖啡、饼干
    • 有兵乓球桌、桌上足球
    • 某些Team可报销家中网费
    • 免费购买相关书籍(以上图中所有书籍均是公司购买),并每个人有一个safari to go 的账号免费看正版原版英语书籍。


—————————-工作篇———————————-

像已有的回答一样,Oracle的工作特别是研发的工作会让人觉得十分繁琐无趣,但也不乏值得学习和思考的地方,以下想到什么写什么:

  • 人种天花板很明显。美国人下面是印度人,印度人下面是中国人。中华区的老大不是台湾就是香港人。
  • 公司的流程十分严密繁琐。虽然这对于公司层面上说,有利于代码、产品的质量(EBS的代码跑了20年,一个模块代码量近亿,当初写代码的人全找不到却依旧能维护)。
  • 工作的内容十分单一。每个人都是一个细小的螺丝钉,孜孜不倦的在为精密的机器(公司)做着钻孔的操作。
  • 主要大部分的时间都在改bug。由于“人种天花板”的问题,研发工作核心点的都在美国搞。次核心的都去到了印度,留给中国这边的大部分都是繁琐的工作,最常见的就是改bug。但这种bug也是极为有挑战难度的!
    • 我们无法直接接触客户的代码(客户可能会修改已有的代码),我们只能通过功能截图,以及系统的内部检测工具(日志、文件版本等)进行跨国家的远程支持与修复。
    • 系统功能极为复杂。所有ERP都有这种毛病,我们工作了好几年的资深的同事,经常遇到一个新bug,也是从头学起。先花半天找到客户的界面是怎么进去的(一个模块几十个入口,每个入口几十个子菜单,下去又几十个界面。一不小心碰到跨模的就更加悲催)。找到了还要弄懂业务的逻辑,又要翻查一堆文档。之后才能开始找相关的代码。
    • 工具极为简陋、难用!我们没有一个好用的IDE,甚至没有整个工程的代码(光工程的运行文件就装满一个移动硬盘)。只能靠一个在线工具搜代码,然后复制粘贴到文本编辑器中一行行看。需要改其中代码的做测试的时候,还很费劲的找一个可用的instance用一个很蹩脚的IDE JDevloper连上去看效果。这IDE每次改代码后都要重启服务器,居然还好意思启动的标语写着“productivity with choices”.
  • 对于新的项目和新的功能,但是用到的全都是Oracle内部的东西。这不是开源不开源的问题,iOS也不开源,但是全世界都在上面开发。但是Oracle的东西都是内部自成一派,你可以留在Oracle 20年都学不完,但离开Oracle后,找不到第二家公司使用这种框架、技术(虽然技术的理念是通的)。
  • 关于有人说开发的模型还是很老很久,这是不正确的。我现在跟着做的新项目,使用的是Scrum (software development),并且也设计到了REST、WebService以及地图服务等。
  • 公司间员工的关系极为平等。即便是上下级甚至是上级的上级,你都能感受到很大的尊重。其中两个强烈的例子是
    • 一个某国内大型ERP公司的前架构师有一天向我拿bug改(他入职一年多都在做新的项目),我说:“现在手上的bug都是历史遗留的老大难喔,要不送你几个?!嘿嘿”。他说:“那算了,你都改不了,我肯定也改不成”。要知道我只是一个刚毕业战斗力只有5的渣渣,只是去年改bug的效率有点惊人,也不至于得到这样的赞美。
    • 经理在performance review上和我说过:“我和XXX(那个前架构师)那时候开玩笑的说,要不你和Jaskey(我)两个人互为mentor,你教他项目的事,他教你改bug”。

虽然这很大程度上是过度赞美,但这能体现人与人之间的平等地位。这种平等,估计是国内的公司极难做到的。(我曾经面试过某家深圳游戏公司,公司四个词的口号带有“平等”两字,面试的时候却气焰奇高,公司口碑极差)。

  • 你很难理解,一个系统跑了20多年。一个模块近亿的代码,找不到所有当年写代码的人。依靠几个新招来的人(我们这边的团队构建时间只有2年),其中还包括几个的刚毕业的应届,是怎么样可以成功的维护起来,增加新功能、修改几万里之外客户报出来的bug的。这对于一个软件系统的设计和架构,是一个值得思考的地方,并且其中的代码看起来是多么不可思议的丑陋。
  • 公司的培训十分多。这也是当年最吸引我加入的地方。对于应届的毕业生,光培训的课程费用就接近10万元。并且公司内部有无数的关于技术、管理等的免费课程。
  • 虽然是一个科技公司,并且拥有着现在最为流行的Oracle数据库、MySQL数据库,Java等等, 但产品却是20年前写好的,现在新的模块使用的的框架也是10年前的,虽然一直有更新,但架子搭着老套的实现,由于兼容性后续的很多工作都是基于老的一套实现方式。例如Java代码中连泛型都没几行,都还在用Vector、HashTable这种已经被抛弃的实现方式。EBS中有一些很基础的功能是用20多年前的技术写的,居然使用Chrome运行不了。
  • 个人价值难以得到体现。在这样一个庞大的机器下,每个人的价值都是可量度的,没有了谁都有会新的螺丝钉来顶替你的位置。


—————————–总结————————-
一个难说好坏地方,对某些人,是天堂;对某些人,是煎熬。

在Oracle的一年多时间里,他给予了一些我认为别的公司(至少在我毕业取得得6份offer的其他公司中)给不了我的东西:

  • 自我学习、自我解决问题的能力。遇到无论技术的还是功能的问题,都可以使用英语+Google+文档得到解决方案。
  • 培养了使用优秀工具的习惯,能无障碍使用Google,Stack Overflow,Coursera.org
  • 用工作外的时间读了近十本书。
  • 完成了两门Coursera.org关于Android的课程并成功获得了证书。现在在上第三门。
  • 私下完成了一个微信公众平台的开发。
  • 看了90%的世界杯直播赛事。
  • 成功维持了一年多的一段异地恋。

 


第一次被邀请回答问题,感谢。

甲骨文在国内的情况我不了解,只能说说在硅谷的Oracle. 我12年毕业于Carnegie Mellon University, ECE专业,职位是软件工程师

1. 地理位置,甲骨文在硅谷有两个大部分,HQ总部位于红木城(Redwood City),主要产品是数据库 Fusion以及其他的软件产品,原Sun Micro-system位于Santa Clara,这里主要是Solaris和JAVA,也是我工作的地点。硅谷风景一般,但气候非常好,一年四季都阳光十足不冷不热

2. 工作环境,总部的工程师(2级-硕士毕业 3级-博士毕业或者工作2年以上)基本都是cube隔间,大小还可以,一般是一台台式机两个24寸显示器或者一个笔记本+两个显示器,反正东西摊开也不嫌挤。Manager和4级principle一般有自己的小办公室。Santa Clara这边之前相对空闲,像我12年初入职一开始就有独立办公室,现在人多了基本要两个人一间或者是Cube了。公司里面不是很挤,节奏比较休闲。Oracle不提供午饭晚饭也没有零食,只有可乐soda茶之类的饮品。两边都有健身房,早6点到晚8点,随时使用。食堂比较渣,价格也不便宜,基本都在6-8刀。

HQ的工作团队我不太了解,据我做数据库和Fusion的朋友说也比较友善。Santa Clara的话,原来SUN这边的老工程师人都很好,技术也都非常强悍(虽然Oracle卖Sun的时候走了很多大牛 不过还是有留下来的),对新人的提携也很多,基本email必回,解答也很详细。不过中间断层较大,(30-40岁)工程师数量比较少,所以当老一辈的员工走了,感觉会有一定影响。

3. 工作强度,Oracle在硅谷被誉为养老院, 和cisco ibm并称美国国企,确实对比Google Facebook之流轻松太多,主要就是表现在代码输出量比较低。尤其是solaris这边,因为是操作系统相关,代码的改动需要经过层层审核测试,所以真正花在coding上的时间反而相对是小部分。当然,组和组之间相差很多,还是有比较辛苦的组的。工作时间非常自由,我一般是11点-7点,不午休,上班时间开开小差聊聊天散散步啥的都没有问题,work from home只要跟组里说一声就OK。

4. 待遇,Oracle给新毕业的硕士生和博士生的起始工资还是不低的,14年硕士基本是115K基本工资+15K签字费+7K搬家费+4000期权(4年 这不值钱),博士135K基本工资,其他一样。

福利方面还算可以,医疗保险算是整个硅谷中上的,病假随便请,产假是公司给6周带薪,剩下的保险公司还会出。401K公司可以最多出3%的月工资。

不过Oracle几乎没有奖金和涨工资,至少我在这两年,年终评价都是Beyond expectation (仅次于最高级),还是没有一点奖金。(而且我的基本工资只有105K,比刚入职的新人都低,老板今年review完说给我升职,但钱一分不涨。。。所以有抱负的朋友都走了。。。只剩下我这种战5渣还留着)每年有13天带薪假,跟老板说说 休满3周是没有问题的,工作3年之后是18天。

5. 升职空间, 我不准备在美国长期居住,所以也不太关心。总体来说个人认为一般华人在美国大公司干到principle engineer或者中低层manager也就到头了,oracle也是一样。

6. 招聘,Oracle在美国招人非常有暴发户气质,除了工业界找人外,校招基本只招名校+高GPA,名校是指常春藤+CMU STANFORD MIT之类,高GPA是指3.7以上,但面试基本都是水过。所以对于很多我的同学以及学弟学妹(CMU),Oracle就是用来保底的……