ITPub博客

现在的SSD和Fusion IO，不同厂家的做法也很不一样，这里整理一些实测值供参考。单盘挂PC,SSD SLC Iops 8k 随机读16500，Iops 8k 随机写11700 SSD MLC Iops 8k 随机读7074，Iops 8k 随机写3065 Fusion IO MLC Iops 8k 随机读53000，Iops 8k 随机写14200 Fusion IO MLC Iops 16k 随机读35000。Iops 16K 随机写6600这里Fusion IO是我压测的，写在4ms的响应时间内有个高峰，估计到2000多IOPS，但随着压力增大，很快就降下来，大部分时间都在12000上波动。附上B2B一哥们的SSD测试结果，其中SLC与我们测试结果相近。一款MLC的SSD测试结果：8k ra

我们在10.2.0.4上遇到过好几次了，enqueue HW wait不仅堵塞了事务，表空间也一下被用了很多，后来每次都预留几十GB的空间，但事务还是被堵塞，下面说说这个WAIT。在高并发的oltp数据库，平时150多的active session，数据库的总session数会经常波动，可能从1000波动到1500或2000，几分钟后又回到1000左右。一个表同时有大量的insert或update时，会有enq HW wait。因为insert/update会请求空间，而如果HWM下的free list 用完，没有剩余的数据块时，请求段内的空数据块，高水位往上移。而每个请求都需要HW enqeue。出现排队，此时如果高水位之

调整prepare statement cache size对数据库的影响，简单的说这个statement cache设置在应用端，缓存了应用到数据库的一些sql。[@more@]关于这个参数的说明： Statement caching improves performance by caching executable statements that are used repeatedly, such as in a loop or in a method that is called repeatedly. Starting from JDBC 3.0, JDBC standards define a statement-caching interface. Statement caching can do the following: * Prevent the overhead of repeated cursor creation * Prevent repeat

昨天同时说数据库的load突然飙升了一下，幸好应用没有什么异常。记得上次也是linux上添加ext3上的数据文件，把os给搞hang，怎么也ssh不进去，后来重启解决的。避免添加 datafile给数据库造成冲击的方法，一是选择业务低峰操作；二，一次添加几个文件，停几分钟，再添加其他的。用sar -B发现4:00PM 有较大的pgpgout11:00:01 AM pgpgin/s pgpgout/s fault/s majflt/s03:20:01 PM 1744.57 210.01 6474.38 0.0003:30:01 PM 1769.84 209.52 6422.80 0.0003:40:01 PM 1844.21 223.05 6708.21 0.0003:50:01 PM 1800.47 211.58 6500.01 0.0004:00:

今天在装完11g后想卸载，从runInstaller找不到卸载的入口了。最后发现$ORACLE_HOME目录下有卸载脚本，跑完后很干净，重装很顺利。oracle确实为用户考虑了很多东西。[@more@]

最近做了下实验，尝试oracle dataguard 从10.2.0.4升级到11.2.0.1，可以有三种升级方式。

通过user profile限制管理帐号的资源使用，create profile admin_user limit sessions_per_user 50 cpu_per_session unlimited cpu_per_call 3000 connect_time 30 idle_time 20 logical_reads_per_session default logical_reads_per_call 1000; alter user admin profile admin_user; alter system set resource_limit=true scope=both;每个参数的含义如下[@more@]How To Calculate The Blocks

前两天从10.2.0.4到11.2.0.1.0升级了一个库，主库升级完打开，在主库重建密码文件传到备库，备库以11g的环境变量打开升级。结果发现主库一直报这个错：Error 12154 received logging on to the standbyErrors in file /u01/diag/rdbms/test/test/trace/test_arc0_7115.trc:ORA-12154: TNS:could not resolve the connect identifier specifiedPING[ARC0]: Heartbeat failed to connect to standby 'test_stb'. Error is 12154.tnsping可以通，sqlplus 去连备库也没有问题。重启备库没有解决，临时使用脚本去做register.最终这个问题是重启

Normal 0 7.8 磅 0 2 false false false MicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:普通表格; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan;

测试一下11gr2的active dataguard首先与原来10g一样，standby 跟上主库的归档，Media Recovery Waiting for thread 1 sequence 278 (in transit)然后在standby以只读打开后，启动日志恢复。SQL> recover managed standby database cancel;Media recovery complete.SQL> alter database open read only;Database altered.SQL> recover managed standby database disconnect using current logfile;Media recovery complete.[@more@]主库创建一个表SQL> create table t as select * from adult;Table created.SQL> select *

ningoo有两篇bbed的文章不错，按此做了下实验，也遇到了些问题至今无解。 介绍bbed: http://www.ningoo.net/html/2009/how_to_link_oracle_bbed_tools.html 查块结构：http://www.ningoo.net/html/tag/bbedbbed的使用及案例看这个：http://orafaq.com/papers/dissassembling_the_data_block.pdf[@more@]在9i/10g中连接生成bbed:cd $ORACLE_HOME/rdbms/libmake -f ins_rdbms.mk $ORACLE_HOME/rdbms/lib/bbed在11g中生成bbed，需要先从10g中复制如下文件到相应目录，然后再执行上述连接命令:$ORACLE_HOME/rdbms/lib/ssbbded.o$ORACLE_HOME

1、不要想把表空间备份，然后删除再restore回来。因为删除时控制文件里不再包含表空间的信息，RMAN备份信息放在控制文件的话，也一块儿没了。RMAN backup tablespace后，drop tablespace 无法再Restore回来，必须restore database（上一次的全备）。 2、10.2的alter tablespace drop datafile 不一定有效。已经alter database datafile 72 offline drop的，不能再用。 SQL> alter database datafile '/u01/oradata/t03.dbf' offline; SQL> alter tablespace test drop datafile '/u01/oradata/t03.dbf'; alter table

sys@ORCL>alter tablespace users drop datafile2 '/u01/app/oracle/oradata/orcl/users02.dbf'; 对于DataGuard，不能使用这个命令，否则redo会坏掉使得备库要重做。到10204还需打上Genernal Bundle。[@more@]作者 ：OoNiceDream【转载时请务必以超链接形式标明文章原始出处和作者信息】链接：http://www.dbaroad.com/archives/2009/05/10g_drop_datafile.html Oracle 9I、10G都可以采用：Alter database datafile file_name offline drop;来删除数据文件，但当数据文件为非空时，存放在该数据文件上的数据就无法读据了：SYS@sky> a

在9i时代，如果在控制文件或者catalog数据库中的备份信息被覆盖或者清除，那么即使所有的备份文件都在，rman也无法简单的利用这些文件来做恢复了，必须得用些特别的方法才能办到，比如以前很多牛人写的使用dbms_backup_restore包从备份片中释放出数据文件，然后再使用手工方式做恢复。但是实际上，oracle完全可以将恢复时需要的一些信息保存在备份文件的文件头中，如果控制文件或者catalog数据库中的信息丢失，再扫描一遍文件头，取出这些信息就可以了。转自：http://www.ningoo.net/html/2007/oracle10g_rman_catalog_command.html[@more

差点丢失数据的RMAN 恢复，最后用隐藏参数打开。Oracle Error: ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error belowORA-01152: file 1 was not restored from a sufficiently old backup ORA-01110: data file 1: '/u01/oracle/oradata/dbc/data1/system01.dbf'RMAN-00571: ===============================================RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS RMAN-00571: =================================================RMAN-03002: failure of recover command at 04/02/2009

说一下过程及遇到的问题[@more@] recover databasealter database open upgrade@?/rdbms/admin/utlirp.sql //数据位数不一样升级数据字典SPOOL /home/oracle/upgrade.log@?/rdbms/admin/catupgrd.sqlSPOOL off@?/rdbms/admin/utlrp.sql //重编译对象检查升级后各组件状态@?/rdbms/admin/utlu102s.sql检查dba_registrycol comp_name for a30select comp_name,version,status from dba_registry;如果utlu102s.sql的结果与dba_registry冲突，则以dba_registry结果为准检查invalid对象col object_name format a32select owner,object_name f

Subject: Receiving error Ora-27054 When Running Rman With NFSDoc ID: 424785.1[@more@]CauseImproper NFS mount options are used. This behaviour has been observed on Solaris Linux and AIX Platforms.Bug 5146667 ORA-27054 ERRORS WHEN RUNNING RMAN WITH NFS SolutionWorkarounds:*.event='10298 trace name context forever, level 32'- Use the event 10298 (It can have a side effect of disabling direct IO on RAC using regular files on NFS mounts) Reference : Note 387700.1 ORA-27054 ERRORS WHEN RUNNING RMAN WI

-- 确定角色的权限select * from role_tab_privs ; 数据字典视图包含了授予角色的对象权限select * from role_role_privs ; 包含了授予另一角色的角色select * from role_sys_privs ; 包含了授予角色的系统权限-- 确定用户帐户所授予的权限select * from DBA_tab_privs ; 直接授予用户帐户的对象权限select * from DBA_role_privs ; 授予用户帐户的角色select * from DBA_sys_privs ; 授予用户帐户的系统权限查看当前用户权限:[@more@]http://blog.ixpub.net/html/62/8026162-375749.html-- 确定角色的权限

lgwr与arch[@more@]10g中用lgwr传归档,他有专门写到备库的进程，9i中用的话有压力的。很多还是用arcn传。arc传的话，主库的redolog归档后，standby的RFS才收到归档，RFS把归档拷到本地，MPR开始从归档恢复，中间没有standby redo log 或realtime的概念。而使用LGWR：real-time apply指的是从primary lgwr传过来的日志立即应用，所以主备库在同一个时间点上基本上是完全一致辞。不采用real-timeapply，常规的还是要等standby redo log归档成归档日志后再应用归档日志，那么主备库就会相差一段时间的数据（standby redolog中的数据）因为red

ORA-12514: TNS:listener does not currently know of service requested in connect descriptor*** 2008-03-12 23:57:11.107 62692 kcrr.cPING[ARC0]: Heartbeat failed to connect to standby 'wtstandby'. Error is 12514.[@more@]*** 2008-03-12 23:57:11.107 62692 kcrr.cError 12514 received logging on to the standbyError 12514 connecting to destination LOG_ARCHIVE_DEST_2 standby host 'wtstandby'Error 12514 attaching to destination LOG_ARCHIVE_DEST_2 standby host 'wtstandby'ORA-12514: TNS:listener does not cur