RMAN real usage of MAXSETSIZE, MAXPIECESIZE, FILESPERSET, SECTION SIZE, MAXOPENFILES

http://www.dbarj.com.br/en/2015/02/rman-real-usage-maxsetsize-maxpiecesize-filesperset-section-size-maxopenfiles/

http://oracleinaction.com/tune-rman-i/

You are trying to install the 64-bit Cell rpm but a 32-bit JDK is installed. You should remove the 32-bit JDK rpm and use the cell binary to install the 64-bit JDK and the 64 bit CELL

Some Work Arround and fix this issue.

Below the error When I'm installing the cell rpm > After extracting cell.bin > install jdk > install cell but getting below error.


***************************************************************************************

[root@storagecell mnt]# rpm -ivh cell-11.2.3.2.1_LINUX.X64_130109-1.x86_64.rpm
Preparing...                ########################################### [100%]
You are trying to install the 64-bit Cell rpm but a 32-bit JDK is installed. You should remove the 32-bit JDK rpm and use the cell binary to install the 64-bit JDK and the 64 bit CELL
error: %pre(cell-11.2.3.2.1_LINUX.X64_130109-1.x86_64) scriptlet failed, exit status 4
error:   install: %pre scriptlet failed (2), skipping cell-11.2.3.2.1_LINUX.X64_130109-1

***************************************************************************************

[root@storagecell ~]# rpm -qa | grep jdk
jdk-1.5.0_15-fcs.x86_64
java-1.6.0-openjdk-devel-1.6.0.0-1.39.1.9.7.el6
java-1.6.0-openjdk-1.6.0.0-1.39.1.9.7.el6

***************************************************************************************
-----------
Solution:
-----------

RH6 “rpm -q” gives output with a different format from RH5.
That produces an error when pre script checks the installed rpm.

.rpmmacros in your home should fix the problem.

Creat .rpmmacro @ root home and change the query format.

[root@storagecell ~]# vim .rpmmacros

[root@storagecell ~]# rpm -qa | grep jdk
jdk-1.5.0_15-fcs
java-1.6.0-openjdk-devel-1.6.0.0-1.39.1.9.7.el6
java-1.6.0-openjdk-1.6.0.0-1.39.1.9.7.el6


[root@stocell1 ~]# cat .rpmmacros
%_query_all_fmt %%{name}-%%{version}-%%{release}



[root@storagecell mnt]# rpm -ivh cell-11.2.3.2.1_LINUX.X64_130109-1.x86_64.rpm
Preparing...                ########################################### [100%]
Pre Installation steps in progress ...
ping: unknown host storagecell.localdomain
Check hostname setting. Cannot install cell
error: %pre(cell-11.2.3.2.1_LINUX.X64_130109-1.x86_64) scriptlet failed, exit status 5
error:   install: %pre scriptlet failed (2), skipping cell-11.2.3.2.1_LINUX.X64_130109-1

[root@storagecell mnt]# vim /etc/hosts

[root@storagecell mnt]# cat /etc/hosts
127.0.0.1   storagecell storagecell.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6

[root@storagecell mnt]# rpm -ivh cell-11.2.3.2.1_LINUX.X64_130109-1.x86_64.rpm
Preparing...                ########################################### [100%]
Pre Installation steps in progress ...
   1:cell                   ########################################### [100%]
Post Installation steps in progress ...
Set cellusers group for /opt/oracle/cell11.2.3.2.1_LINUX.X64_130109/cellsrv/deploy/log directory
Set 775 permissions for /opt/oracle/cell11.2.3.2.1_LINUX.X64_130109/cellsrv/deploy/log directory
/
/
Installation SUCCESSFUL.
Starting RS and MS... as user celladmin
Done. Please Login as user celladmin and create cell to startup CELLSRV to complete cell configuration.
WARNING: Using the current shell as root to restart cell services.
Restart the cell services using a new shell.

[root@storagecell mnt]#

RECOVER ORACLE DATAFILES WITH NO DOWNTIME

What will happen if dbf file accidentally deleted when database is still open and how to recover it?

And Lots of time interviewer asking this question (So first method is here and 2nd method is restore RMAN backup). Anyways come to the point and here we go.....

On Unix/Linux, when a file is deleted, but a process still has the file open, the file is still there in the filesystem, and only the inode is removed.
But the process can continue to use its file handle, and the file can also be accessible under /proc/<pid>/fd .

In the following example, we use that behavior to recover a lost datafile after is has been dropped from the os (with rm) but the datafile is still open by the background processes.

First, we create a tablespace, and populate a table in it.

----------------------------

Create a tablespace: 

----------------------------

SQL> create tablespace TEST datafile '/u01/app/oracle/oradata/orcl/test01.dbf' size 10M;

Tablespace created.

-------------------------------------

Create a table in tablespace: 

-------------------------------------

SQL> create table ORATAB tablespace TEST as select * from dba_objects;

Table created.

----------------------------------------------

Check that table data is accessible: 

----------------------------------------------

SQL> select count(*) from ORATAB;

  COUNT(*)

----------

     71902

SQL> exit

Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

-----------------------------------------------------------

Then, we remove the datafile from unix CLI.

-----------------------------------------------------------

here is the datafile 

ls -l /u01/app/oracle/oradata/orcl/test_rm.dbf

-rw-r—– 1 oracle dba 10493952 Sep 19 15:21 24 /u01/app/oracle/oradata/orcl/test01.dbf

we ‘accidently’ remove the datafile 

rm /u01/app/oracle/oradata/orcl/test01.dbf

ls -l /u01/app/oracle/oradata/orcl/test01.dbf

ls: /u01/app/oracle/oradata/orcl/test01.dbf: no such file or directory

--------------------------------

Here the datafile is lost.

Now we connect again.

-------------------------------

sqlplus / as sysdba

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

-------------------------------------------------------------------------------------------

Check if table data is accessible & you getting below error some times: 

-------------------------------------------------------------------------------------------

SQL> select count(*) from ORATAB;

select * from ORATAB

*

ERROR at line 1:

ORA-01116: error in opening database file 5

ORA-01110: data file 5: '/u01/app/oracle/oradata/orcl/test01.dbf'

ORA-27041: unable to open file

Linux Error: 2: No such file or directory

Additional information: 3

--------------------------------------------------------------

The datafile is lost and data is not accessible.

--------------------------------------------------------------

--------------------------------------------------------------------------------------------------------------------------

However, the datafile should still have an open file descriptor by an oracle background process

--------------------------------------------------------------------------------------------------------------------------

Check the dbwriter pid: 

ps -edf | grep dbw

[oracle@host01 ~]$ ps -edf | grep dbw

oracle    6350     1  0 13:09 ?        00:00:01 ora_dbw0_orcl

oracle    8237  8212  0 15:20 pts/1    00:00:00 grep dbw

List the deleted file handles for that DBWRITER process.

ls -l /proc/_PID_OF_DBWRITER/fd | grep deleted

or

Check its opened file descriptors for our file: 

[oracle@host01 ~]$ ls -l /proc/6350/fd | grep test

lrwx------ 1 oracle oinstall 64 Sep 19 15:21 24 -> /u01/app/oracle/oradata/orcl/test01.dbf (deleted)

here it is: 

[oracle@host01 ~]$ ls -l /proc/6350/fd/24

lrwx------ 1 oracle oinstall 64 Sep 19 15:21 /proc/6350/fd/24 -> /u01/app/oracle/oradata/orcl/test01.dbf (deleted)

In some other unix, lsof may be needed to map the file descriptor with the deleted file name

first we set a symbolic link so that oracle can see it as it was before the delete:

    ln -s /proc/6350/fd/24 -> /u01/app/oracle/oradata/orcl/test01.dbf

here data is accessible, but that will be lost if dbwriter closes it file handle (i.e if the database is closed)

----------------------------------------------------------------------------------------------------------------------------

However we can now set the tablespace read only so that it is checkpointed, and no writes occurs on it.

----------------------------------------------------------------------------------------------------------------------------

SQL> alter tablespace TEST read only;

Tablespace altered.

Now copy the file safely.

then we drop the symbolic link: 

     rm /u01/app/oracle/oradata/orcl/test01.dbf

     ls -l /u01/app/oracle/oradata/orcl/test01.dbf

     ls: /u01/app/oracle/oradata/orcl/test.dbf: No such file or directory

and we can now copy the file 

    cp -p /proc/6350/fd/24 /u01/app/oracle/oradata/orcl/test01.dbf

    ls -l /u01/app/oracle/oradata/orcl/test01.dbf

-rw-r—– 1 oracle dba 10493952 Sep 19 14:54 /u01/app/oracle/oradata/orcl/test01.dbf

And datafile is now available again.

-----------------------------------------------------------------------

We have it back, lets put the tablespace back in read/write 

------------------------------------------------------------------------

SQL> alter tablespace test_rm read write;

Tablespace altered.

-------------------------------

Check data is still there: 

-------------------------------

SQL> select count(*) from ORATAB;

  COUNT(*)

----------

     71902

This is not to be used like that in production. This is unsupported and may behave differently on different unix/linux or oracle flavours.