异机恢复过程：
在rman>run
{
allocate channel ch00 type 'sbt_tape' parms="ENV=(NB_ORA_CLIENT=zjddms1)";
set newname for datafile 1 to '/oradata/zjdms/1.dbf';
......
set newname for datafile 23 to '/oradata/test/23.dbf';
set newname for datafile 24 to '/oradata/test/24.dbf';
restore database;
switch datafile all;
recover database;
release channel ch00;
}
在恢复完数据文件后，
报错情况：
Starting recover at 21-5月 -07
starting media recovery
Oracle Error:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '/oradata/zjdms/1.dbf'
released channel: ch00
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 05/21/2007 12:15:56
RMAN-06053: unable to ......
今天客户的一套RAC环境出现问题
双节点RAC环境中，一个节点因为锁竞争而挂起，shutdown之后无法启动。
故障出现时我正在路上，匆匆回到家中，处理故障。
解决之后查找故障原因。
检查当时的AWR信息发现Top 5 Timed Events显示如下信息：
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) ......
oracle实现汉字按照拼音、笔画和部首排序
找了相关的一些资料，都说的不是很清楚，自己也研究了下，终于搞明白了，希望对大家有帮助。
需要说明的是下面的方法需要ORACLE9i和以上的版本才支持。
Oracle9i之前，中文是按照二进制编码进行排序的。
在oracle9i中新增了按照拼音、部首、笔画排序功能。设置NLS_SORT值
SCHINESE_RADICAL_M 按照部首（第一顺序）、笔划（第二顺序）排序
SCHINESE_STROKE_M 按照笔划（第一顺序）、部首（第二顺序）排序
SCHINESE_PINYIN_M 按照拼音排序
helloword代码如下：
表名为 mt ，其中mtmc字段是中文，下面分别实现按照单位名称的笔划、部首和拼音排序。
1: 按照笔划排序
select * from mt order by nlssort(mtmc,'NLS_SORT=SCHINESE_STROKE_M');
2: 按照部首排序
select * from mt order by nlssort(mtmc,'NLS_SORT=SCHINESE_RADICAL_M');
3: 按照拼音排序，此为系统的默认排序方式
select * from mt order by nlssort(mtmc,'NLS_SORT=SCHINESE_PINYIN_M');
......
今天客户的一套RAC环境出现问题
双节点RAC环境中，一个节点因为锁竞争而挂起，shutdown之后无法启动。
故障出现时我正在路上，匆匆回到家中，处理故障。
解决之后查找故障原因。
检查当时的AWR信息发现Top 5 Timed Events显示如下信息：
Top 5 Timed Events Avg %Total
~~~~~~~~~~~~~~~~~~ wait Call
Event Waits Time (s) (ms) ......
Just a few days ago a got to two Oracle DBAs discussing why the have so much “PX Deq Credit : send blkd” on a system. And if that is causing their performance problems.
The are some blog on the internet claiming it has to do with qc distribution and what ever.
But in many cases, especial if you experince huge waits on “PX Deq Credit : send blkd” the explanation can be much simpler. But first some background information.
If a query is run in parallel there is a query coordinator (QC) and the query slaves. The slaves do the actual work an send the result to the query coordinator. This is done through message buffers which you specified with the parallel_execution_message_size.
This buffer exists in the large or in the shared pool depending how PARALLEL_AUTOMATIC_TUNING is set.
Metalink states about the PX Deq Credit: send blkd event
This is considered as idle wait event.
You should investigate the sender (decode the senderid).
There is no general advice to ......
oracle wait event:cursor: pin S wait on X
cursor: pin S wait on X等待事件的处理过程
http://database.ctocio.com.cn/tips/114/8263614_1.shtml
cursor: pin S wait on X等待！
http://www.itpub.net/viewthread.php?tid=1003340
解决cursor: pin S wait on X 有什么好办法:
http://www.itpub.net/thread-1163543-1-8.html
cursor: pin S wait on X:
http://space.itpub.net/756652/viewspace-348176
cursor: pin S:
http://yumianfeilong.com/html/2008/11/01/254.html
OTN的解释,
cursor: pin SA session waits on this event when it wants to update a shared mutex pin and another session is currently in the process of updating a shared mutex pin for the same cursor object. This wait event should rarely be seen because a shared mutex pin update is very fast.(Wait Time: Microseconds)
Parameter Description
P1 Hash value of cursor
P2 Mutex value (top 2 bytes contains SID holding mutex in exclusive mode, and bottom two bytes usually hold the value 0)
P3 Mutex where (an internal code locator) OR’d with M ......
最新文章 : Oracle