luni, 18 noiembrie 2013

Oracle Application Server: How to change the name of the instance

Just replace the actual name in the following files 

• ias.properties
• opmn.xml 
• sysman/emd/targets.xml
• webcache.xml

Change the instancename there and restart the opmn.

opmnctl stopall
opmnctl startall

Be aware of the report server instance name, which is another thing, with another changing procedure. 

The Oracle virtual machine doesn't start, doesn't stop, could not be killed, it is locked and you just get annoyed and don't know what to do

Time to time, inherently, one of your Oracle virtual machines, or maybe not just one, goes crazy and loops indefinitely into starting or stopping procedure. If you try to shutdown, is useless, if you try to kill, either. All you can do is to restart the machine properly from the command line, by remote access on the proper vm cluster node (if you're not in the situation of having a cluster, hust enter your server).
First of all, display your domains (this is an Oracle occult name for what you know being a virtual machine), using the allmighty 

xm list
Name                               ID   Mem VCPUs      State   Time(s)
0004fb0000060000abb053eabca73f42   5  6147     2     -b---- 906557.4
0004fb0000060000c9fc96601d88f77c   8 32768    16     -b---- 8030521.5
0004fb0000060000f5785dc8a18f8578   28  8195     4     -b---- 1419442.5
0004fb0000060000ff2c2bc7ef1b5d9c   33 32768     4     -b----   2036.7
Domain-0                           0  3119    16     r----- 7885714.2

Well, these are your domains (english translation: virtual machines).

Now, you have to identify the guilty machine.Go to OVM Manager, click on the name of the machine, and look in the right panel, in the Info section:

ID: 0004fb0000060000ff2c2bc7ef1b5d9c

As you can see, the ID appear to be easy to find.
Now, you can try the shutdown command:

xm shutdown 0004fb0000060000ff2c2bc7ef1b5d9c

but, from my experience, it's the same thing you just tried to do from the manager interface. Won't work...

In this case, just apply a heavier punch:

xm destroy 0004fb0000060000ff2c2bc7ef1b5d9c

This will power off the domain (!) and, also, will take off from the list of domains. Don't panic! If you try to display the domains:

xm list
Name                               ID   Mem VCPUs      State   Time(s)
0004fb0000060000abb053eabca73f42   5  6147     2     -b---- 906557.4
0004fb0000060000c9fc96601d88f77c   8 32768    16     -b---- 8030521.5
0004fb0000060000f5785dc8a18f8578   28  8195     4     -b---- 1419442.5
Domain-0                           0  3119    16     r----- 7885714.2

the domain is not anymore visible.

Just provide the command:

xm create /OVS/Repositories/0004fb0000030000de61d1/VirtualMachines/0004fb0000060000ff2c2bc7ef1b5d9c/vm.cfg


and your machine will start properly. If not, let me know :)

miercuri, 13 noiembrie 2013

ORA-02069: global_names parameter must be set to TRUE for this operation

Sometime, this error message occurs somehow without any reasonable meaning.

Example:

Insert into table@dblink select * from view;

ORA-02069: global_names parameter must be set to TRUE for this operation

Apparently, there is no reason to panic, you have to set that parameter appropriately and everything is working again. I don't care why, but when i did that:

alter session set global_names=true
Insert into table@dblink select * from view;

[Error] Execution (9: 28): ORA-02085: database link dblink.domain connects to XE

What can i do? The sid is correct, the global name of the database is:

select * from global_name;

GLOBAL_NAME
-----------
XE

Well, the answer is inside of that view. Some objects suitable to be called by views cannot be "smuggled" through the dblink and executed among of a normal insert in the target database.
My workaround was:

create table_temp as select * from view;
insert into table@dblink select * from table_temp;

Now, the records are static, no computing is necesary, and the insert command will behave normally.