Metric evaluation error start – EMS-01076: Unexpected error while deploying a plug-in in sync mode for emd url https://hostname:3872/emd/main/: EMS-01015: Error occurred while deploying AGENT plug-in.
if you get the above issue while trying to add targets to cloud control: check the mount options for the /tmp filesystem. if there is the “noexec” attribute this is probably the issue.
to fix it (if you have root):
mount -o remount,exec /tmp
another ouch with the grid infrastructure (tested with 12.1.0.2). steps to reproduce:
1. configure the GI on the first node
2. deconfigure the GI on the first node ( rootcrs.pl -deconfig -force )
3. change the network configuration (ip address) for the privat interconnect
4. configure the GI again => this will fail
the reason is that “rootcrs.pl -deconfig -force” does not delete the gpnp profile. to fix this just delete the profile:
rm -rf [GI_HOME]/gpnp/[NODE_NAME]/
This is somehow documented in mos note 942166.1
saves another few clicks :) :
echo "alias newsr='nohup firefox https://support.oracle.com/epmos/faces/SrCreate &'" >> ~/.bashrc . ~/.bashrc newsr
if you get this when trying to start a database using srvctl:
PRCR-1079 : Failed to start resource ora.xxxxx.db ORA-46362: Could not translate variable ORACLE_BASE. ORA-46362: Could not translate variable ORACLE_BASE. CRS-5017: The resource action "ora.xxxxx.db start" encountered the following error: ORA-46362: Could not translate variable ORACLE_BASE. ORA-46362: Could not translate variable ORACLE_BASE. . For details refer to "(:CLSN00107:)" in "xxxxx.trc". CRS-2674: Start of 'ora.xxxxxxx.db' on 'xxxxxx' failed ORA-46362: Could not translate variable ORACLE_BASE. ORA-46362: Could not translate variable ORACLE_BASE.
modify the database resource:
srvctl setenv database -d [DBNAME] -env ORACLE_BASE=$ORACLE_BASE
… and try again
quickly need a calender on the console? try cal:
cal
September 2014
Su Mo Tu We Th Fr Sa
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30
the whole year?
cal -y
2014
January February March
Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa
1 2 3 4 1 1
5 6 7 8 9 10 11 2 3 4 5 6 7 8 2 3 4 5 6 7 8
12 13 14 15 16 17 18 9 10 11 12 13 14 15 9 10 11 12 13 14 15
19 20 21 22 23 24 25 16 17 18 19 20 21 22 16 17 18 19 20 21 22
26 27 28 29 30 31 23 24 25 26 27 28 23 24 25 26 27 28 29
30 31
April May June
Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa
1 2 3 4 5 1 2 3 1 2 3 4 5 6 7
6 7 8 9 10 11 12 4 5 6 7 8 9 10 8 9 10 11 12 13 14
13 14 15 16 17 18 19 11 12 13 14 15 16 17 15 16 17 18 19 20 21
20 21 22 23 24 25 26 18 19 20 21 22 23 24 22 23 24 25 26 27 28
27 28 29 30 25 26 27 28 29 30 31 29 30
July August September
Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa
1 2 3 4 5 1 2 1 2 3 4 5 6
6 7 8 9 10 11 12 3 4 5 6 7 8 9 7 8 9 10 11 12 13
13 14 15 16 17 18 19 10 11 12 13 14 15 16 14 15 16 17 18 19 20
20 21 22 23 24 25 26 17 18 19 20 21 22 23 21 22 23 24 25 26 27
27 28 29 30 31 24 25 26 27 28 29 30 28 29 30
31
October November December
Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa
1 2 3 4 1 1 2 3 4 5 6
5 6 7 8 9 10 11 2 3 4 5 6 7 8 7 8 9 10 11 12 13
12 13 14 15 16 17 18 9 10 11 12 13 14 15 14 15 16 17 18 19 20
19 20 21 22 23 24 25 16 17 18 19 20 21 22 21 22 23 24 25 26 27
26 27 28 29 30 31 23 24 25 26 27 28 29 28 29 30 31
next year?
cal -y 2015
2015
January February March
Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa
1 2 3 1 2 3 4 5 6 7 1 2 3 4 5 6 7
4 5 6 7 8 9 10 8 9 10 11 12 13 14 8 9 10 11 12 13 14
11 12 13 14 15 16 17 15 16 17 18 19 20 21 15 16 17 18 19 20 21
18 19 20 21 22 23 24 22 23 24 25 26 27 28 22 23 24 25 26 27 28
25 26 27 28 29 30 31 29 30 31
April May June
Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa
1 2 3 4 1 2 1 2 3 4 5 6
5 6 7 8 9 10 11 3 4 5 6 7 8 9 7 8 9 10 11 12 13
12 13 14 15 16 17 18 10 11 12 13 14 15 16 14 15 16 17 18 19 20
19 20 21 22 23 24 25 17 18 19 20 21 22 23 21 22 23 24 25 26 27
26 27 28 29 30 24 25 26 27 28 29 30 28 29 30
31
July August September
Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa
1 2 3 4 1 1 2 3 4 5
5 6 7 8 9 10 11 2 3 4 5 6 7 8 6 7 8 9 10 11 12
12 13 14 15 16 17 18 9 10 11 12 13 14 15 13 14 15 16 17 18 19
19 20 21 22 23 24 25 16 17 18 19 20 21 22 20 21 22 23 24 25 26
26 27 28 29 30 31 23 24 25 26 27 28 29 27 28 29 30
30 31
October November December
Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa Su Mo Tu We Th Fr Sa
1 2 3 1 2 3 4 5 6 7 1 2 3 4 5
4 5 6 7 8 9 10 8 9 10 11 12 13 14 6 7 8 9 10 11 12
11 12 13 14 15 16 17 15 16 17 18 19 20 21 13 14 15 16 17 18 19
18 19 20 21 22 23 24 22 23 24 25 26 27 28 20 21 22 23 24 25 26
25 26 27 28 29 30 31 29 30 27 28 29 30 31
While browsing http://planet.postgresql.org/ today I came across a link to a nice paper which is definitely worth reading:
do not apply PSU 12.1.0.1.4 if you are using APEX and the embedded plsql gateway: you might hit bug 18610915 which is internal and therefore no description is available.
if you hit this you are either not able to even bring up the apex login page (neither http nor https) or it stops working after a few connections (dispatchers are dying).
path “Patch 18610915: INTERMITTENT SEGMENTATION FAULT DURING NZ/PRNG INIT” is only available for 12.1.0.2.
once a session which is doing a transaction gets killed before the session commits or rollbacks oracle needs to recover(undo) the work done by this session. one way to watch the progress of this recovery is to use the v$fast_start_servers and v$fast_start_transactions views.
small test case:
-- FIRST SESSION drop user u1 cascade; create user u1 identified by u1 default tablespace users temporary tablespace temp quota unlimited on users; grant create session, create table to u1; grant select on dba_objects to u1; connect u1/u1 create table t1 as select * from dba_objects; insert into t1 select * from t1; / / / commit;
in a second session get the sid and serial# for the first session:
connect / as sysdba select sid,serial# from v$session where username = 'U1';
back in the first session do some (stupid) work on the table:
begin
while 1=1 loop
update t1 set OBJECT_NAME = OBJECT_NAME;
end loop;
end;
/
this will write undo data without committing the work. now, in the first session, kill the session which is doing the transaction:
alter system kill session '[SID_FROM_ABOVE],[SERIAL#_FROM_ABOVE]';
if your hardware is slow enough or you are fast enough or you keep the loop running for some time before killing the session you can now see the slave(s) doing recovery:
select * from v$fast_start_servers; STATE UNDOBLOCKSDONE PID XID ----------- -------------- ---------- ---------------- RECOVERING 9379 26 020021006D010000
… and the transaction(s) being recovered:
select * from v$fast_start_transactions;
USN SLT SEQ STATE UNDOBLOCKSDONE UNDOBLOCKSTOTAL PID CPUTIME PARENTUSN PARENTSLT PARENTSEQ XID
---------- ---------- ---------- ---------------- -------------- --------------- ---------- ---------- ---------- ---------- ---------- ----------------
PXID RCVSERVERS
---------------- ----------
2 33 365 RECOVERED 19357 19357 11 020021006D010000
1
5 4 357 RECOVERED 17220 17220 13 0500040065010000
consider reading this before jumping on this train:
Daniel Westermann's Blog 