luni, 28 iulie 2014

How to overcome "ORA-01610: recovery using the BACKUP CONTROLFILE option must be done"

SQL> startup mount
ORACLE instance started.

SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done

This problem can appear after a loss of the controlfile (and will assume you don't have any backup) or if you mess with point-in-time recovery.

SQL> recover database using BACKUP CONTROLFILE;

-this command will lead to some interaction about what file (controlfile backup) the instance should use in order to recover.
I will assume that you can't provide any file an the problem persists.

Now take a backup of the current controlfile:\

SQL> alter database backup controlfile to '/home/oracle/back.ctl';

Create a trace of the current controlfile:

SQL> alter database backup controlfile to trace as '/home/oracle/trace.sql';

Bounce the instance to the nomount state:

SQL>shutdown immediate;
SQL>startup nomount;

Now copy the following command from the trace file:

  GROUP 1 '/opt/oracle/oradata/pidb/redo01.log'  SIZE 50M BLOCKSIZE 512,
  GROUP 2 '/opt/oracle/oradata/pidb/redo02.log'  SIZE 50M BLOCKSIZE 512,
  GROUP 3 '/opt/oracle/oradata/pidb/redo03.log'  SIZE 50M BLOCKSIZE 512

and issue it through sqlplus command line.

You can easily observe that the TEMP datafiles are not the, and after:

SQL>alter database open;

you cannot do everything you want, because of the emptiness of TEMP tablespace.
So, create a temporary datafile:

SQL>alter tablespace TEMP add tempfile '/opt/oracle/oradata/pidb/tempo2.dbf' size 1024m autoextend on;

and everything will work fine.
Be aware, if the database is after an incomplete recovery, you should replace the NORESETLOGS word with RESETLOGS, within the create controlfile command, and the further command will be

SQL> alter database open resetlogs;

All done! Enjoy!

marți, 15 iulie 2014

Some Glassfish issues: instalation, stuff.....

In order to have the Glassfish server working, you must install JDK 1.7xxxxx.
So, download from here the jdk kit.
Then, download from here the glassfish server. I preffer the linux version.
Now, let's assume that you have the jdk folder under /usr/java and glassfish4 folder under /opt.
Make an environment script:
export JAVA_HOME=/usr/java/jdk1.7.0_60/bin
export PATH=$JAVA_HOME/bin:/opt/glassfish4/bin:$PATH

and run the script.
All you have to do now is to start the domain:
/opt/glassfish4/bin/asadmin start-domain
Let's study some problems that can appear:
• Exception in thread "main" java.lang.UnsupportedClassVersionError: org/glassfish/admin/cli/AsadminMain : Unsupported major.minor version 51.0
the problem is java executable is another version, lower one. Make a symbolic link:
 rm /usr/bin/java
 ln -s /usr/java/jdk1.7.0_60/bin/java /usr/bin/java ws1: ws1: Temporary failure in name resolution
your /etc/hosts file is wrong.
There is a process already using the admin port 4848 -- it probably is another instance of a GlassFish server.
Could be the same problem as above, the file /etc/hosts should resolve the ip properly, or can be a problem with that port. The netstat will help:
netstat -natp
if you'll receive something like this:
tcp   0  0 :::4848       :::*            LISTEN      7943/java
just kill that process, if it is not a wanted process for you:
ps -ef | grep java
root      7943     1 15 11:12 pts/1    00:00:38 /usr/java/jdk1.7.0_60/bin/java  .....................
kill -9 7943
and that's all.
Now, you should see this:
/opt/glassfish4/bin/asadmin start-domain
Waiting for domain1 to start .......
Successfully started the domain : domain1
domain  Location: /opt/glassfish4/glassfish/domains/domain1
Log File: /opt/glassfish4/glassfish/domains/domain1/logs/server.log
Admin Port: 4848
Command start-domain executed successfully.
Open in a browser
http:<your hostname or ip>:4848
Now, you can experience the following error:

Secure Admin must be enabled to access the DAS remotely

First, you have to change the admin password, otherwise the secure mode cannot be enabled.

/opt/glassfish4/bin/asadmin change-admin-password

the old password is blank (or adminadmin, or admin, ...). As far as i know, is blank.

After the password is changed:




and now everything should be fine.
The admin console has to be there.

Now, let's create a jdbc connection pool:

copy the ojdbc6.jar from here and put it here:


then restart the domain:

> create-jdbc-connection-pool --restype javax.sql.DataSource --datasourceclassname oracle.jdbc.pool.OracleDataSource --property "user=hr:password=hr: url=jdbc\\:oracle\\:thin\\:@ws1\\:1521\\:ws1" ws1pool

where we assume that hr/hr is the user credentials, ws1 is the hostname, 1521 the listener port and ws1 the service name.

Now go to the admin console, jdbc connection pools, click on the new connection pool name, and then ping it. You should receive the message "ping succeeded".

marți, 8 iulie 2014

How to reset root password under LINUX

You will find this tutorial on hundreds of places over the web, but it's never too much for a useful thing to be found on how many places can be posible.

1. Start the computer.
2. Soon after the BIOS messages, pres ESC and you'll have the GRUB menu displayed.
3. Press <E> and in the following menu, use the arrows to choose the second line, usually, the one with kernel = ....
4. Press <E> again and begin to edit the line, by adding the word "single" at the end (keep in mind you can use the word "1". Just that, the "1" character).
5. ESC to go back
6. Press <B> to boot the kernel.

The booting process will end in single user mode, with root prompt (sh#).
Now you can change the password easily, like you would be logged as root.

sh# passwd

etc etc


vineri, 4 iulie 2014

Different time between connected through listener and connected locally. RAC Infrastructure 11gR2

I don't know if the problem arises with the 11gR2 or was there, under the previous releases. If you experience this problem with no matter which previous release, i suppose the workaround is ok.
The issue is below one:

sqlplus sys@tnsname as sysdba
SQL>  select systimestamp from dual;
04-JUL-14 AM +03:00

sqlplus / as sysdba

SQL>  select systimestamp from dual;
04-JUL-14 AM +03:00

Unfortunately, all the OLTP applications you will use to populate your database will work through listener, and having a wrong timestamp reference can be very annoying for the users.

Briefly, the workaround:

connect as root and:

1. change the TZ variable. In order to make this permanent, after every single machine startup, you have to put a script under the  /etc/profile.d   folder (doesn't matter the name of the script, make it  and will run).

export TZ=Europe/Bucharest  (of course, you will provide the desired timezone)

2.  edit the $ORACLE_HOME/crs/install/s_crsconfig_name-of-your-instance_env.txt    where the ORACLE_HOME is the GRID_HOME

change the line


I don't know why, whatever you set, conercning the system timezone or database timezone, here you will find, by default, America/NewYork.

Now, connect as oracle user and edit the below files:


and add the line


Again, be aware of your correct data.

By some people, now you have just to bounce the listener or the ohasd services.

/etc/init.d/ohasd stop
/etc/init.d/ohasd start

For me, didn't work. I restarted all the operating systems of all the instances in order to achieve the purpose.