Upgrade your JDBC and JDK before Upgrade your Database to 12c Version!

Ok, now it’s everyone upgrading to 12c, right? Thanks God, this version was released in 2013!

But there is some things to be aware when planning an upgrade, specially regarding old applications and legacy. But pay attention! Not all of the requirements are necessary inside database. It’s the case os JDBC version requirement.

The database 12c documentation explicit mentions that JDBC versions 11.1.x and below are not supported anymore. It doesn’t mean that they don’t work, it’s only unsupported and you’ll have no assistance from MOS if you need. It’s better to avoid, right?

Anyway, if you check the JDBC support matrix, if you are in version 11.2 or below you are not supported since August/2015. So the Database 12c is helping you, that don’t have patching policy, to keep on right way. Thanks to Database 12c!

If this is your situation, I highly recommend you to upgrade the directly to JDBC version 7, the last available by now. See JDBC matrix version as:

captura-de-tela-2016-10-22-as-16-59-57

But test! Test in you dev/test/QA environments before upgrading in Production environment!

Why? Because JDBC also have his compatibility matrix. JDBC 7, for example, demands your JDK to be at least in version 7 (released in 2011!). So, it’s needed to be at least in JDK version 6, as you can see below.

captura-de-tela-2016-10-22-as-16-37-18(Click in the image to access the link)

OK doke?

Some interesting links for you:
Verifying a JDBC Client Installation
What are the various supported Oracle database version vs JDBC compliant versions vs JDK version supported?
Checking the Oracle JDBC Driver Version on a Weblogic Server (by Cristóbal Soto)

Matheus.

PSUs for Databases 10.2.0.4 and above

Hi all!
I’m researching about and decided to share the list of all Oracle Patch Set Updates (PSU) for Databases 10.2.0.4 and above, until now.
It’s always good to know the last PSU for every version to better fit on our patching policy.

Note: To understand database version numbers: https://docs.oracle.com/cd/B28359_01/server.111/b28310/dba004.htm

I expect it be useful for you too!

Patches for 12.1.0.2
Patch 21359755 – DATABASE PATCH SET UPDATE 12.1.0.2.5
Patch 21523234 – GRID INFRASTRUCTURE PATCH SET UPDATE 12.1.0.2.5 (OCT2015)
Patch 20831110 – DATABASE PATCH SET UPDATE 12.1.0.2.4 (INCLUDES CPUJUL2015)
Patch 20996835 – GRID INFRASTRUCTURE PATCH SET UPDATE 12.1.0.2.4 (JUL2015)
Patch 20299023 – DATABASE PATCH SET UPDATE 12.1.0.2.3 (APR2015)
Patch 20485724 – GRID INFRASTRUCTURE PATCH SET UPDATE 12.1.0.2.3 (APR2015)
Patch 19769480 – DATABASE PATCH SET UPDATE 12.1.0.2.2 (JAN2015)
Patch 19954978 – GRID INFRASTRUCTURE PATCH SET UPDATE 12.1.0.2.2 (JAN2015)
Patch 19303936 – DATABASE PATCH SET UPDATE 12.1.0.2.1 (OCT2014)
Patch 19392646 – GRID INFRASTRUCTURE PATCH SET UPDATE 12.1.0.2.1 (OCT2014)

Patches for 12.1.0.1
Patch 21352619 – DATABASE PATCH SET UPDATE 12.1.0.1.9
Patch 21551666 – GRID INFRASTRUCTURE PSU 12.1.0.1.9 (OCT2015 – INCLUDES DB PSU 12.1.0.1.9)
Patch 20831107 – DATABASE PATCH SET UPDATE 12.1.0.1.8 (INCLUDES CPUJUL2015)
Patch 20996901 – GRID INFRASTRUCTURE PATCH SET UPDATE 12.1.0.1.8 (JUL2015)
Patch 20299016 – DATABASE PATCH SET UPDATE 12.1.0.1.7
Patch 20485762 – GRID INFRASTRUCTURE PATCH SET UPDATE 12.1.0.1.7 (APR2015)
Patch 19769486 – DATABASE PATCH SET UPDATE 12.1.0.1.6
Patch 19971324 – GRID INFRASTRUCTURE PATCH SET UPDATE 12.1.0.1.6 (JAN2015)
Patch 19121550 – DATABASE PATCH SET UPDATE 12.1.0.1.5
Patch 19392372 – GRID INFRASTRUCTURE PATCH SET UPDATE 12.1.0.1.5 (OCT2014)
Patch 18522516 – DATABASE PATCH SET UPDATE 12.1.0.1.4
Patch 18705901 – GRID INFRASTRUCTURE SYSTEM PATCH 12.1.0.1.4 (Exadata)
Patch 18705972 – GRID INFRASTRUCTURE SYSTEM PATCH 12.1.0.1.4
Patch 18031528 – DATABASE PATCH SET UPDATE 12.1.0.1.3
Patch 18139660 – GRID INFRASTRUCTURE SYSTEM PATCH 12.1.0.1.3 (Exadata)
Patch 18413105 – GRID INFRASTRUCTURE SYSTEM PATCH 12.1.0.1.3
Patch 17552800 – DATABASE PATCH SET UPDATE 12.1.0.1.2
Patch 17735306 – GRID INFRASTRUCTURE SYSTEM PATCH 12.1.0.1.2
Patch 17027533 – DATABASE PATCH SET UPDATE 12.1.0.1.1
Patch 17272829 – GRID INFRASTRUCTURE PSU 12.1.0.1.1

Patches for 11.2.0.4
Patch 21352635 – DATABASE PATCH SET UPDATE 11.2.0.4.8 (INCLUDES CPUOCT2015)
Patch 21523375 – GRID INFRASTRUCTURE PATCH SET UPDATE 11.2.0.4.8 (OCT2015)
Patch 20760982 – DATABASE PATCH SET UPDATE 11.2.0.4.7 (INCLUDES CPUJUL2015)
Patch 20996923 – GRID INFRASTRUCTURE PATCH SET UPDATE 11.2.0.4.7 (JUL2015)
Patch 20299013 – DATABASE PATCH SET UPDATE 11.2.0.4.6 (INCLUDES CPUAPR2015)
Patch 20485808 – GRID INFRASTRUCTURE PATCH SET UPDATE 11.2.0.4.6 (APR2015)
Patch 19769489 – DATABASE PATCH SET UPDATE 11.2.0.4.5 (INCLUDES CPUJAN2015)
Patch 19955028 – GRID INFRASTRUCTURE PATCH SET UPDATE 11.2.0.4.5 (JAN2015)
Patch 19121551 – DATABASE PATCH SET UPDATE 11.2.0.4.4 (INCLUDES CPUOCT2014)
Patch 19380115 – GRID INFRASTRUCTURE SYSTEM PATCH 11.2.0.4.4
Patch 18522509 – DATABASE PATCH SET UPDATE 11.2.0.4.3 (INCLUDES CPUJUL2014)
Patch 18706472 – GRID INFRASTRUCTURE SYSTEM PATCH 11.2.0.4.3
Patch 18031668 – DATABASE PATCH SET UPDATE 11.2.0.4.2 (INCLUDES CPUAPR2014)
Patch 18139609 – GRID INFRASTRUCTURE SYSTEM PATCH 11.2.0.4.2
Patch 17478514 – DATABASE PATCH SET UPDATE 11.2.0.4.1 (INCLUDES CPUJAN2014)

Patches for 11.2.0.3
Patch 20760997 – DATABASE PATCH SET UPDATE 11.2.0.3.15 (INCLUDES CPUJUL2015)
Patch 20996944 – GRID INFRASTRUCTURE PATCH SET UPDATE 11.2.0.3.15 (JUL2015)
Patch 20299017 – DATABASE PATCH SET UPDATE 11.2.0.3.14 (INCLUDES CPUAPR2015)
Patch 20485830 – GRID INFRASTRUCTURE PATCH SET UPDATE 11.2.0.3.14 (APR2015)
Patch 19769496 – DATABASE PATCH SET UPDATE 11.2.0.3.13 (INCLUDES CPUJAN2015)
Patch 19971343 – GRID INFRASTRUCTURE PSU 11.2.0.3.13 (JAN2015)
Patch 19121548 – DATABASE PATCH SET UPDATE 11.2.0.3.12 (INCLUDES CPUOCT2014)
Patch 19440385 – GRID INFRASTRUCTURE PSU 11.2.0.3.12 (INCLUDES DB PSU 11.2.0.3.12)
Patch 18522512 – DATABASE PATCH SET UPDATE 11.2.0.3.11 (INCLUDES CPUJUL2014)
Patch 18706488 – GRID INFRASTRUCTURE PSU 11.2.0.3.11 (INCLUDES DB PSU 11.2.0.3.11)
Patch 18031683 – DATABASE PATCH SET UPDATE 11.2.0.3.10
Patch 18139678 – GRID INFRASTRUCTURE PSU 11.2.0.3.10 (INCLUDES DB PSU 11.2.0.3.10)
Patch 17540582 – DATABASE PATCH SET UPDATE 11.2.0.3.9 (INCLUDES CPUJAN2014)
Patch 17735354 – GRID INFRASTRUCTURE PSU 11.2.0.3.9 (INCLUDES DB PSU 11.2.0.3.9)
Patch 16902043 – DATABASE PATCH SET UPDATE 11.2.0.3.8 (INCLUDES CPUOCT2013)
Patch 17272731 – GRID INFRASTRUCTURE PSU 11.2.0.3.8 (INCLUDES DB PSU 11.2.0.3.8)
Patch 16619892 – DATABASE PATCH SET UPDATE 11.2.0.3.7 (INCLUDES CPUJUL2013)
Patch 16742216 – GRID INFRASTRUCTURE PSU 11.2.0.3.7 (INCLUDES DB PSU 11.2.0.3.7)
Patch 16056266 – DATABASE PATCH SET UPDATE 11.2.0.3.6 (INCLUDES CPUAPR2013)
Patch 16083653 – GRID INFRASTRUCTURE PSU 11.2.0.3.6 (INCLUDES DB PSU 11.2.0.3.6)
Patch 14727310 – DATABASE PATCH SET UPDATE 11.2.0.3.5 (INCLUDES CPUJAN2013)
Patch 14727347 – GRID INFRASTRUCTURE PSU 11.2.0.3.5 (INCLUDES DB PSU 11.2.0.3.5)
Patch 14275605 – DATABASE PATCH SET UPDATE 11.2.0.3.4 (INCLUDES CPUOCT2012)
Patch 14275572 – GRID INFRASTRUCTURE PSU 11.2.0.3.4 (INCLUDES DB PSU 11.2.0.3.4)
Patch 13923374 – DATABASE PATCH SET UPDATE 11.2.0.3.3 (INCLUDES CPU JUL2012)
Patch 13919095 – GRID INFRASTRUCTURE PSU 11.2.0.3.3 (INCLUDES DB PSU 11.2.0.3.3)
Patch 13696216 – DATABASE PATCH SET UPDATE 11.2.0.3.2 (INCLUDES CPU APR2012)
Patch 13696251 – GRID INFRASTRUCTURE PSU 11.2.0.3.2 (INCLUDES DB PSU 11.2.0.3.2)
Patch 13343438 – DATABASE PATCH SET UPDATE 11.2.0.3.1 (INCLUDES CPU JAN2012)

Patches for 11.2.0.2
Patch 17082367 – DATABASE PATCH SET UPDATE 11.2.0.2.12 (INCLUDES CPUOCT2013)
Patch 17272753 – GRID INFRASTRUCTURE PSU 11.2.0.2.12 (INCLUDES DB PSU 11.2.0.2.12)
Patch 16619893 – DATABASE PATCH SET UPDATE 11.2.0.2.11 (INCLUDES CPUJUL2013)
Patch 16742320 – GRID INFRASTRUCTURE PSU 11.2.0.2.11 (INCLUDES DB PSU 11.2.0.2.11)
Patch 16056267 – DATABASE PATCH SET UPDATE 11.2.0.2.10 (INCLUDES CPUAPR2013)
Patch 16166868 – GRID INFRASTRUCTURE PSU 11.2.0.2.10 (INCLUDES DB PSU 11.2.0.2.10)
Patch 14727315 – DATABASE PATCH SET UPDATE 11.2.0.2.9 (INCLUDES CPUJAN2013)
Patch 14841385 – GRID INFRASTRUCTURE PSU 11.2.0.2.9 (INCLUDES DB PSU 11.2.0.2.9)
Patch 14275621 – DATABASE PATCH SET UPDATE 11.2.0.2.8 (INCLUDES CPUOCT2012)
Patch 14390437 – GRID INFRASTRUCTURE PSU 11.2.0.2.8 (INCLUDES DB PSU 11.2.0.2.8)
Patch 13923804 – DATABASE PATCH SET UPDATE 11.2.0.2.7 (INCLUDES CPU JUL2012)
Patch 14192201 – GRID INFRASTRUCTURE PSU 11.2.0.2.7 (INCLUDES DB PSU 11.2.0.2.7)
Patch 13696224 – DATABASE PATCH SET UPDATE 11.2.0.2.6 (INCLUDES CPU APR2012)
Patch 13696242 – GRID INFRASTRUCTURE PSU 11.2.0.2.6 (INCLUDES DB PSU 11.2.0.2.6)
Patch 13343424 – DATABASE PATCH SET UPDATE 11.2.0.2.5 (INCLUDES CPU JAN2012)
Patch 12827726 – DATABASE PSU 11.2.0.2.4 (INCLUDES CPUOCT2011)
Patch 12419331 – DATABASE PSU 11.2.0.2.3 (INCLUDES CPUJUL2011)
Patch 11724916 – DATABASE PSU 11.2.0.2.2 (INCLUDES CPUAPR2011)
Patch 10248523 – DATABASE PSU 11.2.0.2.1 (Patch)

Patches for 11.2.0.1
Patch 12419378 – DATABASE PSU 11.2.0.1.6 (INCLUDES CPUJUL2011)
Patch 11724930 – DATABASE PSU 11.2.0.1.5 (INCLUDES CPUAPR2011)
Patch 10248516 – DATABASE PSU 11.2.0.1.4 (INCLUDES CPUJAN2011)
Patch 9952216 – DATABASE PSU 11.2.0.1.3 (INCLUDES CPUOCT2010)
Patch 9655006 – GI PSU 11.2.0.1.2 (INCLUDES DATABASE PSU 11.2.0.1.2)
Patch 9654983 – DATABASE PSU 11.2.0.1.2 (INCLUDES CPUJUL2010)
Patch 9352237 – DATABASE PSU 11.2.0.1.1 (Patch)

Patches for 11.1.0.7
Patch 20761024 – DATABASE PATCH SET UPDATE 11.1.0.7.24 (INCLUDES CPUJUL2015)
Patch 20299012 – DATABASE PATCH SET UPDATE 11.1.0.7.23 (INCLUDES CPUAPR2015)
Patch 19769499 – DATABASE PATCH SET UPDATE 11.1.0.7.22 (INCLUDES CPUJAN2015)
Patch 19152553 – DATABASE PATCH SET UPDATE 11.1.0.7.21 (INCLUDES CPUOCT2014)
Patch 18522513 – DATABASE PATCH SET UPDATE 11.1.0.7.20 (INCLUDES CPUJUL2014)
Patch 18031726 – DATABASE PATCH SET UPDATE 11.1.0.7.19 (INCLUDES CPUAPR2014)
Patch 17465583 – DATABASE PATCH SET UPDATE 11.1.0.7.18 (INCLUDES CPUJAN2014)
Patch 17082366 – DATABASE PATCH SET UPDATE 11.1.0.7.17 (INCLUDES CPUOCT2013)
Patch 16619896 – DATABASE PATCH SET UPDATE 11.1.0.7.16 (INCLUDES CPUJUL2013)
Patch 16056268 – DATABASE PATCH SET UPDATE 11.1.0.7.15 (INCLUDES CPUAPR2013)
Patch 14739378 – DATABASE PATCH SET UPDATE 11.1.0.7.14 (INCLUDES CPUJAN2013)
Patch 14275623 – DATABASE PATCH SET UPDATE 11.1.0.7.13 (INCLUDES CPUOCT2012)
Patch 13923474 – DATABASE PATCH SET UPDATE 11.1.0.7.12 (INCLUDES CPU JUL2012)
Patch 13621679 – DATABASE PATCH SET UPDATE 11.1.0.7.11 (INCLUDES CPU APR2012)
Patch 13343461 – DATABASE PATCH SET UPDATE 11.1.0.7.10 (INCLUDES CPU JAN2012)
Patch 12827740 – DATABASE PSU 11.1.0.7.9 (INCLUDES CPUOCT2011)
Patch 12419384 – DATABASE PSU 11.1.0.7.8 (INCLUDES CPUJUL2011)
Patch 11724953 – TRACKING BUG FOR 11.1.0.7.7 CRS PSU
Patch 11724936 – DATABASE PSU 11.1.0.7.7 (INCLUDES CPUAPR2011)
Patch 10248531 – DATABASE PSU 11.1.0.7.6 (INCLUDES CPUJAN2011)
Patch 9952228 – DATABASE PSU 11.1.0.7.5 (INCLUDES CPUOCT2010)
Patch 9654987 – DATABASE PSU 11.1.0.7.4 (INCLUDES CPUJUL2010)
Patch 9352179 – DATABASE PSU 11.1.0.7.3 (INCLUDES CPUAPR2010)
Patch 9209238 – DATABASE PSU 11.1.0.7.2 (INCLUDES CPUJAN2010)
Patch 8833297 – DATABASE PSU 11.1.0.7.1 (INCLUDES CPUOCT2009)

Patches for 10.2.0.5
Patch 16619894 – DATABASE PATCH SET UPDATE 10.2.0.5.12 (INCLUDES CPUJUL2013)
Patch 16056270 – DATABASE PATCH SET UPDATE 10.2.0.5.11 (INCLUDES CPUAPR2013)
Patch 14727319 – DATABASE PATCH SET UPDATE 10.2.0.5.10 (INCLUDES CPUJAN2013)
Patch 14275629 – DATABASE PATCH SET UPDATE 10.2.0.5.9 (INCLUDES CPUOCT2012)
Patch 13923855 – DATABASE PATCH SET UPDATE 10.2.0.5.8 (INCLUDES CPU JUL2012)
Patch 13632743 – DATABASE PATCH SET UPDATE 10.2.0.5.7 (INCLUDES CPU APR2012)
Patch 13343471 – DATABASE PATCH SET UPDATE 10.2.0.5.6 (INCLUDES CPU JAN2012)
Patch 12827745 – DATABASE PSU 10.2.0.5.5 (INCLUDES CPUOCT2011)
Patch 12419392 – DATABASE PSU 10.2.0.5.4 (INCLUDES CPUJUL2011)
Patch 11724962 – DATABASE PSU 10.2.0.5.3 (INCLUDES CPUAPR2011)
Patch 9952245 – TRACKING BUG FOR 10.2.0.5.2 CRS PSU
Patch 10248542 – DATABASE PSU 10.2.0.5.2 (INCLUDES CPUJAN2011)
Patch 9952230 – DATABASE PSU 10.2.0.5.1 (INCLUDES CPUOCT2010)

Patches for 10.2.0.4
Patch 16619897 – DATABASE PSU 10.2.0.4.17 (REQUIRES PRE-REQUISITE 10.2.0.4.4|INCLUDES CPUJUL2013)
Patch 16056269 – DATABASE PSU 10.2.0.4.16 (REQUIRES PRE-REQUISITE 10.2.0.4.4|INCLUDES CPUAPR2013)
Patch 14736542 – DATABASE PSU 10.2.0.4.15 (REQUIRES PRE-REQUISITE 10.2.0.4.4|INCLUDES CPUJAN2013)
Patch 14275630 – DATABASE PSU 10.2.0.4.14 (REQUIRES PRE-REQUISITE 10.2.0.4.4|INCLUDES CPUOCT2012)
Patch 13923851 – DATABASE PSU 10.2.0.4.13 (REQUIRES PRE-REQUISITE 10.2.0.4.4|INCLUDES CPUJUL2012)
Patch 12879933 – DATABASE PSU 10.2.0.4.12 (REQUIRES PRE-REQUISITE 10.2.0.4.4|INCLUDES CPUAPR2012)
Patch 12879929 – DATABASE PATCH SET UPDATE 10.2.0.4.11 (PRE-REQ 10.2.0.4.4|INCLUDES CPUJAN2012)
Patch 12827778 – DATABASE PSU 10.2.0.4.10 (REQUIRES PRE-REQUISITE 10.2.0.4.4|INCLUDES CPUOCT2011)
Patch 12419397 – DATABASE PSU 10.2.0.4.9 (REQUIRES PRE-REQUISITE 10.2.0.4.4|INCLUDES CPUJUL2011)
Patch 11724977 – DATABASE PSU 10.2.0.4.8 (REQUIRES PRE-REQUISITE 10.2.0.4.4|INCLUDES CPUAPR2011)
Patch 10248636 – DATABASE PSU 10.2.0.4.7 (REQUIRES PRE-REQUISITE 10.2.0.4.4|INCLUDES CPUJAN2011)
Patch 9952234 – DATABASE PSU 10.2.0.4.6 (REQUIRES PRE-REQUISITE 10.2.0.4.4|INCLUDES CPUOCT2010)
Patch 9654991 – DATABASE PSU 10.2.0.4.5 (REQUIRES PRE-REQUISITE 10.2.0.4.4|INCLUDES CPUJUL2010)
Patch 9294403 – TRACKING BUG FOR THE 10.2.0.4.4 CRS PSU
Patch 9352164 – DATABASE PSU 10.2.0.4.4 (INCLUDES CPUAPR2010)
Patch 9119284 – DATABASE PSU 10.2.0.4.3 (INCLUDES CPUJAN2010)
Patch 8833280 – DATABASE PSU 10.2.0.4.2 (INCLUDES CPUOCT2009)
Patch 8576156 – DATABASE PSU 10.2.0.4.1 (INCLUDES CPUJUL2009)

Flush DNS on Linux

I began posting about ORA-12514 after database migration involving DNS adjustment.
Then, to make it more clear I wrote about How to Flush DNS Cache.

Now, just a complementar information that can be usefull:

# To invalidade DNS Cache:

ls /var/db/nscd/
group hosts netgroup passwd services
 
nscd --invalidate=hosts  (or -i hosts)

Hugs!

Matheus.

ORA-27302: failure occurred at: sskgpcreates

# Error:

dbsrvr1:/home/oracle>srvctl start database -d mydb
PRCR-1079 : Failed to start resource ora.mydb.db
CRS-5017: The resource action "ora.mydb.db start" encountered the following error:
ORA-27154: post/wait create failed
ORA-27300: OS system dependent operation:semget failed with status: 28
ORA-27301: OS failure message: No space left on device
ORA-27302: failure occurred at: sskgpcreates
. For details refer to "(:CLSN00107:)" in "/grid/product/11.2.0.4/log/dbsrvr2/agent/crsd/oraagent_oracle/oraagent_oracle.log".
CRS-2674: Start of 'ora.mydb.db' on 'dbsrvr2' failed
CRS-2632: There are no more servers to try to place resource 'ora.mydb.db' on that would satisfy its placement policy

Seems the weeror is happening on dbsrvr2, right?
The doc below talks more about the error and the semaphores calculation:
Database Startup Fails with ORA-27300: OS system dependent operation:semget failed with status: 28 (Doc ID 949468.1)

Let’s make an adjust here:

[root@dbsrvr2 ~]# cat /etc/sysctl.conf |grep sem
kernel.sem = 250 32000 100 142
[root@dbsrvr2 ~]# vi /etc/sysctl.conf
[root@dbsrvr2 ~]# cat /etc/sysctl.conf |grep sem
kernel.sem = 250 32000 100 256
[root@dbsrvr2 ~]# sysctl -p

And try again:

dbsrvr1:/home/oracle>srvctl start database -d mydb
dbsrvr1:/home/oracle>

Well done! 😀

Matheus.

Database Migration/Move with RMAN: Are you sure nothing is missing?

Forced by the destiny to make a migration using backup/restore (with a little downtime), how to be sure nothing will be lost during the migration?
Here is a way: Create your own data just before migrating. 🙂

Seems like a kludge and it is.. haha.. But it works. Take a look:

# Original Database

SQL> shu immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup restrict;
ORACLE instance started.
Total System Global Area 2689060864 bytes
Fixed Size 2229520 bytes
Variable Size 1996491504 bytes
Database Buffers 671088640 bytes
Redo Buffers 19251200 bytes
Database mounted.
Database opened.
SQL> create table matheus_boesing.migration (text varchar2(10));
Table created.
SQL> insert into matheus_boesing.migration values ('well done!');
1 row created.
SQL> commit;
Commit complete.
SQL> alter system switch logfile;
System altered.
SQL> /
System altered.
SQL> /
System altered.
SQL> /
System altered.
SQL> /
System altered.
SQL> /
System altered.
SQL> shu immediate;
SQL> exit;
$ rman target /
connect catalog rman_mydb/password@catalogdb
run { backup archivelog all;}

# Destination Database

$ rman target /
connect catalog rman_mydb/password@catalogdb
run { recover database;}
$ sqlplus / as sysdba
SQL> select count(1), to_char(CHECKPOINT_TIME, 'DD/MM/YYYY HH24:MI:SS') from V$DATAFILE_HEADER t
group by to_char(CHECKPOINT_TIME, 'DD/MM/YYYY HH24:MI:SS') order by 2;
COUNT(1) TO_CHAR(CHECKPOINT_
---------- -------------------
51 27/06/2015 22:15:28
-- All datafiles with synchronized headers...
SQL> alter database open read only; 
-- If needed, you can do more recover, this way...
Database altered.
SQL> select * from matheus_boesing.migration;
TEXT
----------
well done!
-- Means no more recover is needed :)
SQL> shutdown immediate;
SQL> alter database open resetlogs;
Database altered.

And be Happy! 😀

Matheus.

Sqlplus: Connect without configure TNSNAMES

Okey, you must to know, but is always useful to remmember that… If you don’t want to configure your TNSNAMES, you can connect directly to description of your database. This way:

sqlplus> conn matheus_boesing@(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=mydb.domain.net)(PORT=1531)))(CONNECT_DATA=(service_name=mydb)))
Enter password: ********
Connected.
sqlplus>

Based on this, I made two scripts, to connect with the sid (c.sql) or with the service_name (s.sql) and make my life easier. Here the scripts:

sqlplus>get c
1 DEFINE VHOST = &1.
2 DEFINE VPORT = &2.
3 DEFINE VSID = &3.
4 DEFINE VDESC='(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=&VHOST)(PORT=&VPORT)))(CONNECT_DATA=(SID=&VSID)(server=dedicated)))'
5 disconnect
6 connect matheus_boesing@&&VDESC
7 set linesize 1000
8 set sqlprom '&&VSID> '
9 select instance_name, host_name
10 from v$instance;
11 exec dbms_application_info.SET_MODULE('MATHEUS_BOESING','DBA');
12 alter session set nls_date_format='DD/MM/YYYY HH24:MI:SS';
13 UNDEFINE VDESC
14 UNDEFINE 1
15 UNDEFINE 2
16* UNDEFINE 3
sqlplus>get s
1 DEFINE VHOST = &1.
2 DEFINE VPORT = &2.
3 DEFINE VSID = &3.
4 DEFINE VDESC='(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=&VHOST)(PORT=&VPORT)))(CONNECT_DATA=(SERVICE_NAME=&VSID)(server=dedicated)))'
5 prompt &VDESC
6 disconnect
7 connect matheus_boesing@&&VDESC
8 set linesize 1000
9 set sqlprom '&&VSID> '
10 select instance_name, host_name
11 from v$instance;
12 exec dbms_application_info.SET_MODULE('MATHEUS_BOESING','DBA');
13 alter session set nls_date_format='DD/MM/YYYY HH24:MI:SS';
14 UNDEFINE VDESC
15 UNDEFINE 1
16 UNDEFINE 2
17* UNDEFINE 3
sqlplus>

It can be used like this:

sqlplus>@s mydb.domain.net 1531 mydb
(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=mydb.domain.net)(PORT=1531)))(CONNECT_DATA=(SERVICE_NAME=mydb)(server=dedicated)))
Enter password: ********
Connected.

Ok, but, let’s suppose you are working in a cluster and wants to connect directly to the another instance. I made the script below (ci.sql). It’s not beautiful, but is a lot hopeful:

sqlplus> get ci
1 DEFINE VINT = &1.
2 undefine VHOST
3 undefine VSID
4 VARIABLE VCONN varchar2(100)
5 PRINT ret_val
6 BEGIN
7 SELECT '@c '||host_name||' 1521 '||INSTANCE_NAME
8 INTO :VCONN
9 FROM gv$instance where INSTANCE_NUMBER=&VINT;
10 END;
11 /
12 set head off;
13 spool auxcon.sql
14 prompt set head on;
15 print :VCONN
16 prompt set head on;
17 spool off;
18* @auxcon
sqlplus>

As you see, you inform the inst_id you want to connect. It can be used like:

mydb> @instance
INSTANCE_NAME
------------------------------
mydb_2
mydb> @instances
INST_NUMBER INST_NAME
----------- ---------------------------------------
1 db2srvr2p.grepora.net:mydb_1
2 db1srvr1p.grepora.net:mydb_2
mydb> @ci 1
@c db2srvr2p.grepora.net 1521 mydb_1
Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options
Enter password: ********
Connected.
mydb_1> @instance
INSTANCE_NAME
------------------------------
mydb_1

These scripts use to help me a lot on daily basis, and it’s exclusive.
I couldn’t find anything like this so far. So, I made it. 🙂

Matheus.

Leap Second and Impact for Oracle Database

Don’t know what is this? Oh boy, I suggest you take a look…

It can sound a little crazy, but it’s about an universal time adjustment of atomic time. Something like that. To understand, take a look on:
http://www.meinberg.de/english/info/leap-second.htm
http://en.wikipedia.org/wiki/Coordinated_Universal_Time
http://en.wikipedia.org/wiki/International_Atomic_Time
http://www.britannica.com/EBchecked/topic/136395/Coordinated-Universal-Time
http://www.britannica.com/EBchecked/topic/290686/International-Atomic-Time

20499seconds
Okey doke!
But what about Oracle Database adjustment? Good news: Nothing to do! 😀

In Oracle words: “The Oracle RDBMS needs no patches and has no problem with the leap second changes on OS level.

But, attention!
If your application uses timestamp or sysdate, verify the adjust of the OS Level. If it consists on a “60” second, it can result on “ORA-01852 seen 60 seconds is a illegal value for the date or timestamp dataype.
(Insert leap seconds into a timestamp column fails with ORA-01852 (Doc ID 1553906.1))

Another possibilities is documented on these notes:
NTP leap second event causing Oracle Clusterware node reboot (Doc ID 759143.1)
(Oracle VM and RHEL 4.4 to 6.2): Leap Second Hang – CPU Can Be Seen at 100% (Doc ID 1472421.1)
(OEM on Linux): Enterprise Manager Management Agent or OMS CPU Use Is Excessive near Leap Second Additions on Linux (Doc ID 1472651.1)

So, pay attention! 🙂

Here other Oracle notes that I recommend to take a look:
Leap seconds (extra second in a year) and impact on the Oracle database. (Doc ID 730795.1)
Leap Second Time Adjustment (e.g. on June 30, 2015 at 23:59:59 UTC) and Its Impact on Exadata Database Machine (Doc ID 1986986.1)
How Leap Second Affects The OS Clock on Linux and Oracle VM (Doc ID 1453523.1)
NOTE:1461363.1 – What Leap Second Affects Occur In Tuxedo?
NOTE:1553906.1 – Insert leap seconds into a timestamp column fails with ORA-01852
NOTE:412160.1 – Updated DST Transitions and New Time Zones in Oracle RDBMS and OJVM Time Zone File Patches
NOTE:1453523.1 – How Leap Second Affects The OS Clock on Linux and Oracle VM
NOTE:1019692.1 – Leap Second Handling in Solaris – NTPv3 and NTPv4
NOTE:1444354.1 – Strftime(3c) Does Not Show The Leap Second As 23:59:60
NOTE:1461606.1 – Any Effect of Leap Seconds to MessageQ?

Matheus.

Unplug/Plug PDB between different Clusters

Everyone test, write and show how to move pluggable databases between containers (CBDs) in the same Cluster, but a little more than a few write/show about move pluggable databases between different clusters, with isolated storage. So, let’s do that:

OBS: Just to stay easy to understand, this post is about migration of a Pluggable Database (BACENDB) from a cluster named ORAGRID12C and a Container Database named INFRACDB to the Cluster CLBBGER12, into Container CDBBGER.
(Click on images to get it bigger)

1. Access the container INFRACDB (Cluster GRID12C) and List the PDBs: 1

2. Shutdown BACENDB:
2
(of course it does’n worked with a normal shutdown. I don’t know what I was thinking… haha) 3

3. Unplug BACENDB (PDB) to XML (must be done from Pluggable, as you see…) 4
4. Created an ACFS (180G) to use as “migration area” mounted on “/migration/” in ORAGRID12C cluster:
5

5. Copy Datafiles and Tempfiles for the “/migration” through ASMCMD cp 6

6. ACFS exported and mounted as NFS on destination (CLBBGER12): 7
8

7. Pluggable created (Plugged) on new Cluster (CDBBGER), using “MOVE” FILE_NAME_CONVERT, to send the files to diskgroup +DGCDBBGER:

9

7.1 How it looks like on alert.log?

10

7.2 How about the Datafiles?

11

7.3 Checking database by remote sqlplus:

13

8. Creating the services as needed:

12

9. Dropping Pluggable from INFRACDB:

14

That’s Okey? Of course there is a few other ways to copy the files from an infra to another, like scp rather than mount.nfs, RMAN Copy, or other possibilities…

By the way, one of the restrictions of pluggable migration is to use the same endian format. Buut it’s possible to use RMAN Convert Plataform and convert datafiles to a filesystem, isn’t?
So, I guess it’s not a necessary limitation. Must to test an write another post… haha

About the post, this link helped, but, again, don’t mention about “another” cluster/infra/storage.

Matheus.