Friday, October 25, 2013

RMAN QUERY TO FIND BACKUP DETAILS


 RMAN  VIEWS (WHEN NO RECOVERY CATALOG AVAILABLE) . i have provide the example as per 11gR2. 

To Display the backup details of the database (Full, Incremental & Archive log backup), when the DB is not connect with the recover catalog.

SQL> select session_key,
       input_type,
       status,
       to_char(start_time,'yyyy-mm-dd hh24:mi') start_time,
       to_char(end_time,'yyyy-mm-dd hh24:mi')   end_time,
       output_bytes_display,
       time_taken_display
from v$rman_backup_job_details
order by session_key asc;

Below query will display the backup piece that hold the backup of archive log, datafile in the DISK or TAPE Drive.

Query to see Backed Up Archive Logs in the database

SQL> select recid,set_stamp,sequence#,first_change#,next_change#
                 from  v$backup_redolog;

Query against the V$BACKUP_PIECE view to find backup details of a particular archive log 

  SQL>            select r.sequence#, p.handle from v$backup_piece p, v$backup_redolog r
            where r.set_stamp = p.set_stamp and r.set_count = p.set_count
              and r.sequence# = 63

Note: 63 is the sequence number.
Query against the V$BACKUP_PIECE view to find backup details of a particular datafiles

SQL> select d.file#, p.handle    from v$backup_piece p, v$backup_datafile d  where d.set_stamp = p.set_stamp  and d.set_count = p.set_count and d.file# = 3

Note: 3 is the datafile number.


SQL>  select table_name from dict where table_name like 'V$%RMAN%';

TABLE_NAME
------------------------------
V$RMAN_BACKUP_JOB_DETAILS
V$RMAN_BACKUP_SUBJOB_DETAILS
V$RMAN_BACKUP_TYPE
V$RMAN_COMPRESSION_ALGORITHM
V$RMAN_CONFIGURATION
V$RMAN_ENCRYPTION_ALGORITHMS
V$RMAN_OUTPUT
V$RMAN_STATUS

8 rows selected.

V$RMAN_BACKUP_JOB_DETAILS è displays details about backup jobs.

V$RMAN_BACKUP_SUBJOB_DETAILS è  merges similar operations within an RMAN session into a single row. For example, if there are four BACKUP DATAFILE <n> commands, three RECOVERY COPY OF DATAFILE commands, and one BACKUP RECOVERY AREA command, this view will contain three rows - one each for BACKUP, ROLLFORWARD, and COPY_DISK_TO_TAPE operation.

V$RMAN_BACKUP_TYPEè displays information about RMAN backup types.
SQL> select * from V$RMAN_BACKUP_TYPE;

    WEIGHT INPUT_TYPE
---------- -------------
         1 BACKUPSET
         2 SPFILE
         3 CONTROLFILE
         4 ARCHIVELOG
         5 DATAFILE INCR
         6 DATAFILE FULL
         7 DB INCR
         8 RECVR AREA
         9 DB FULL

V$RMAN_COMPRESSION_ALGORITHM è provides descriptions of supported compression algorithms. It is used by the RMAN client.

V$RMAN_CONFIGURATION è Information about RMAN persistent configuration settings.

V$RMAN_ENCRYPTION_ALGORITHMS è displays supported encryption algorithms. It is used by the RMAN client to validate user-requested algorithms. This view will list AES128, AES192, and AES256 encryption algorithms for the current release. The default algorithm is AES128.

V$RMAN_OUTPUT è  displays messages reported by RMAN. This is an in-memory view and is not recorded in the controlfile. The view can hold 32768 rows.

V$RMAN_STATUS è displays the finished and on-going RMAN jobs. For on-going jobs, this view displays progress and status. The jobs which are in progress are stored only in memory while the finished jobs are stored in the controlfile

Sunday, August 11, 2013

10g Transportable tablespaces

PURPOSE
-------
Use transportable tablespace in 10G database to move tablespaces between different Operating Systems.


SCOPE & APPLICATION
-------------------
With previous releases of the Oracle Database, you could not transport a tablespace to a target database if a tablespace with the same name already existed in the target database. 
With Oracle Database 10G, you can simply rename the tablespace in the target database to some other name before the transport.

Special Considerations:
Before issuing this command, make sure the compatibility level is set to at least 10.0.0.
If any datafile in the tablespace is offline or if the entire tablespace is offline, then the tablespace cannot be renamed.
Renaming a tablespace does not change its tablespace identifier. If the tablespace is READ ONLY, then this command does
not update datafile headers. You  get a message in the alert log indicating the datafile headers are not updated.  These
headers can only be changed if the tablespace is put back in READ WRITE mode, if ever possible.  If the tablespace is
an undo tablespace, and it is the tablespace specified by the initialization parameter UNDO_TABLESPACE in any
instances, then they are changed to reflect the new name. These changes affect both memory and SPFILE.  All
these changes are logged in the alert log file.  If SPFILE is not being used, then a specific message is added
to the alert log file advising DBAs to manually change the corresponding initialization parameter file.

Note: Users with ALTER TABLESPACE privilege are able to use this feature.  It is not possible to rename the SYSTEM or SYSAUX tablespaces.


TRANSPORTABLE TABLESPACE BETWEEN DIFFERENT Operating Systems
-------------------------------------------------------------

1. Set the tablespace to READ ONLY
   -------------------------------
SQL> alter tablespace TRANSPORTABLE_TESTE read only;

Tablespace altered.

2. Export metadata
   ---------------
      WINDOWS - exp userid=sys as sysdba transport_tablespace=y tablespaces=TRANSPORTABLE_TESTE file=ts.dmp log=exp_ts.log statistics=none

Export: Release 10.1.0.2.0 - Production on Qui Out 28 00:16:11 2004

Copyright (c) 1982, 2004, Oracle.  All rights reserved.

Conectado a: Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - Production With the Partitioning, OLAP and Data Mining options
Exportação executada no conjunto de caracteres de WE8MSWIN1252  e no conjunto de caracteres de AL16UTF16 NCHAR
OBS: dados (linhas) da tabela não serão exportados
Prestes a exportar metadados de tablespace transportavel...
Para tablespace TRANSPORTABLE_TESTE ...
. exportando definições de cluster
. exportando definições de tabela
. exportando restrições referenciais de integridade
. exportando gatilhos
. exportação final de metadados de tablespace transportavel
Exportação encerrada com sucesso, sem advertências.


3. Check the endianness of the target database
  
For check platform do the following:

SQL> select * from v$transportable_platform;

PLATFORM_ID   PLATFORM_NAME                                              ENDIAN_FORMAT
-----------   --------------------------------------------------------   --------------
          1   Solaris[tm] OE (32-bit)                                    Big
          2   Solaris[tm] OE (64-bit)                                    Big
          7   Microsoft Windows IA (32-bit)                              Little
         10   Linux IA (32-bit)                                          Little
          6   AIX-Based Systems (64-bit)                                 Big
          3   HP-UX (64-bit)                                             Big
          5   HP Tru64 UNIX                                              Little
          4   HP-UX IA (64-bit)                                          Big
         11   Linux IA (64-bit)                                          Little
         15   HP Open VMS                                                Little
          8   Microsoft Windows IA (64-bit)                              Little
          9   IBM zSeries Based Linux                                    Big
         13   Linux 64-bit for AMD                                       Little
         16   Apple Mac OS                                               Big
         12   Microsoft Windows 64-bit for AMD                           Little

15 linhas selecionadas.

      The source platform is Microsoft Windows IA (32-bit): endianness Little
      The target platform is HP-UX (64-bit)               : endianness Big

    You have to convert the files :
    --> locally before the import step so that the files are endian compatible:

    <Windows> rman target=/

Recovery Manager: Release 10.1.0.2.0 - Production
Copyright (c) 1995, 2004, Oracle.  All rights reserved.
conectado ao banco de dados de destino: ORCL (DBID=1068469100)

RMAN> convert tablespace 'TRANSPORTABLE_TESTE' to platform="HP-UX (64-bit)" db_file_name_convert='D:\ORACLE\SERVER10G\ORCL\TRANSPORTABLE_TESTE.ORA', 'D:\TRANSPORTABLE_TESTE01.dbf';

Iniciando backup em 28/10/04
usar o arquivo de controle do banco de dados de destino em vez do catalogo de recuperação
canal alocado: ORA_DISK_1
canal ORA_DISK_1: sid=148 devtype=DISK
canal ORA_DISK_1: iniciando conversao de arquivo de dados
fno=00006 name=D:\ORACLE\SERVER10G\ORCL\TRANSPORTABLE_TESTE.ORA do arquivo de dados de entrada arquivo de dados convertido=D:\TRANSPORTABLE_TESTE01.DBF
canal ORA_DISK_1: conversao de arquivo de dados concluida, tempo decorrido: 00:00:03
Finalizado backup em 28/10/04

The converted datafile is staged in /tmp directory until it is copied to the target server.
--> remotely on the target server after having copied them on the server.


4. Move datafiles and export dump file
   -----------------------------------
      C:\> ftp ts.dmp 
           D:\TRANSPORTABLE_TESTE01.dbf


5. Import metadata
   ---------------
      $ imp userid=\'/ as sysdba\' TRANSPORT_TABLESPACE=Y
                                   datafiles=/TMP/TRANSPORTABLE_TESTE01.dbf
                                   file=ts.dmp log=imp_ts.log
  
     
6. Set the tablespace to READ WRITE
   --------------------------------
      SQL> alter tablespace TRANSPORTABLE_TESTE read write;
      Tablespace altered.

Tuesday, June 18, 2013

What is Checksum in Oracle.?

A checksum is a count of the number of bits in a transmission unit that is included with the unit so that the receiver can check to see whether the same number of bits arrived. If the counts match, it's assumed that the complete transmission was received. Both TCP and UDPcommunication layers provide a checksum count and verification as one of their services.

Monday, June 17, 2013

ORA-12514: TNS:listener does not currently know of service requested in connect descriptor / Fatal NI connect error 12514, connecting to /ns main err code: 12564 / TNS-12564: TNS:connection refused

Error like

Fatal NI connect error 12514, connecting to:
 (DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=server1)(PORT=25000)))(CONNECT_DATA=(SERVICE_NAME=DBNAME1)(CID=(PROGRAM=oracle)(HOST=server1)(USER=))))

  VERSION INFORMATION:
        TNS for HPUX: Version 11.2.0.3.0 - Production
        Oracle Bequeath NT Protocol Adapter for HPUX: Version 11.2.0.3.0 - Production
        TCP/IP NT Protocol Adapter for HPUX: Version 11.2.0.3.0 - Production
  Time: 17-JUN-2013 11:08:30
  Tracing not turned on.
  Tns error struct:
    ns main err code: 12564

TNS-12564: TNS:connection refused
    ns secondary err code: 0
    nt main err code: 0
    nt secondary err code: 0
    nt OS err code: 0

Possible Causes :

1.) The listener is down.
2.)The listener received a request to establish a connection to a database or other service. The connect descriptor received by the listener specified a service name for a service (usually a database service) that either has not yet dynamically registered with the listener or has not been statically configured for the listener.
3.)  This may be a temporary condition such as after the listener has started, but before the database instance has registered with the listener.

Solution.:

1.) Check your listner by issueing "lsnrctl status" command. 
Verify if the listener is up and running. 
2.) Verify your alert log and sqlnet.log to see if any errors.
3.) Verify if you have specified SID or SERVICE_NAME in you Global tnsnames.ora file.
Correct it if not set properly.



Wednesday, June 5, 2013

ORA-02391: exceeded simultaneous SESSIONS_PER_USER limit - ORA-02063: preceding line from


This is happening because the User/Schema has made the maximum number of connections allowed. This is governed by the parameter SESSIONS_PER_USER in the user profile. Once the maximum number of connections are made you will hit this error.

You can get the details by executing the following queries :

*****
*****
select profile from dba_users where username ='USER1';

PROFILE
--------------------
DEFAULT

*****
*****
select * from dba_profiles where profile='DEFAULT';

PROFILE                        RESOURCE_NAME                    RESOURCE LIMIT
------------------------------ -------------------------------- -------- ----------------
DEFAULT                        COMPOSITE_LIMIT                  KERNEL   UNLIMITED
DEFAULT                        SESSIONS_PER_USER                KERNEL   50
DEFAULT                        CPU_PER_SESSION                  KERNEL   UNLIMITED
DEFAULT                        CPU_PER_CALL                     KERNEL   UNLIMITED
DEFAULT                        LOGICAL_READS_PER_SESSION        KERNEL   UNLIMITED
DEFAULT                        LOGICAL_READS_PER_CALL           KERNEL   UNLIMITED
DEFAULT                        IDLE_TIME                        KERNEL   UNLIMITED
DEFAULT                        CONNECT_TIME                     KERNEL   UNLIMITED
DEFAULT                        PRIVATE_SGA                      KERNEL   UNLIMITED
DEFAULT                        FAILED_LOGIN_ATTEMPTS            PASSWORD 10
DEFAULT                        PASSWORD_LIFE_TIME               PASSWORD 180
DEFAULT                        PASSWORD_REUSE_TIME              PASSWORD UNLIMITED
DEFAULT                        PASSWORD_REUSE_MAX               PASSWORD UNLIMITED
DEFAULT                        PASSWORD_VERIFY_FUNCTION         PASSWORD NULL
DEFAULT                        PASSWORD_LOCK_TIME               PASSWORD 1
DEFAULT                        PASSWORD_GRACE_TIME              PASSWORD 7

Say for example in the above scenario User1 is allowed to make 50 connections only to the database.

We can check how many connections have been made to the database using the following query.

*****
*****
select count(*) from v$session where username='USER1';

 COUNT(*)
---------
        34

The resolution is to change the parameter SESSIONS_PER_USER in the profile attached to user or Identifying if the application is hitting the bug , if so many connections to database is not anticipated.

The profile can be altered using :

Alter profile DEFAULT  limit sessions per user 100;






Hardware Requirements for Oracle RAC Installation

Each system must meet the following minimum hardware requirements:
  • At least 1 GB of physical RAM
  • Swap space equivalent to the multiple of the available RAM, as indicated in the following table:
    Available RAMSwap Space Required
    Between 1 GB and 2 GB1.5 times the size of RAM
    Between 2 GB and 8 GBEqual to the size of RAM
    More than 8 GB.75 times the size of RAM
  • 400 MB of disk space in the /tmp directory
  • 2 GB of disk space for Oracle Clusterware files, in partitions on separate physical disks, assuming standard redundancy (2 Oracle Cluster Registry partitions and 3 voting disks)
  • 650 MB of disk space for the Oracle Clusterware home
  • 5 GB of disk space for the Oracle database software (Oracle base), depending on the installation type and platform
  • 1.2 GB of disk space for a preconfigured database that uses file system storage (optional)
    Additional disk space, either on a file system or in an Automatic Storage Management disk group, is required for the Fast recovery area if you choose to configure automated backups.


    To ensure that each system meets these requirements:
  1. To determine the physical RAM size, enter the following command:
    # /usr/sbin/prtconf | grep "Memory size"
    
    If the size of the physical RAM installed in the system is less than the required size, then you must install more memory before continuing.
  2. To determine the size of the configured swap space, enter the following command:
    # /usr/sbin/swap -s
    
    If necessary, refer to your operating system documentation for information about how to configure additional swap space.
  3. To determine the amount of disk space available in the /tmp directory, enter the following command:
    # df -k /tmp
    
    If there is less than 400 MB of disk space available in the /tmp directory, then complete one of the following steps:
    • Delete unnecessary files from the /tmp directory to meet the disk space requirement.
    • Set the TEMP and TMPDIR environment variables when setting the oracle user's environment (described later).
    • Extend the file system that contains the /tmp directory. If necessary, contact your system administrator for information about extending file systems.
  4. To determine the amount of free disk space on the system, enter the following command:
    # df -k /tmp
    
    The following table shows the approximate disk space requirements for software files for each installation type:
    Installation TypeRequirement for Software Files (GB)
    Enterprise Edition4
    Standard Edition4
    Custom (maximum)4
  5. To determine if the system architecture can run the Oracle software, enter the following command:
    # /bin/isainfo -kv
    
    Note:
    The following is the expected output of this command:
    64-bit SPARC installation:
    64-bit sparcv9 kernel modules
    Ensure that the Oracle software you have is the correct Oracle software for your processor type.
    If the output of this command indicates that your system architecture does not match the system for which the Oracle software you have is written, then you cannot install the software. Obtain the correct software for your system architecture before proceeding further.

Monday, June 3, 2013

Temporary Segments cleanup problem in Oracle / SMON: disabling tx recovery / oracle database shutdown hangs

Recently I had an Issue in which I was supposed to  bounce the database and open in Archive log mode. 
When i was trying to bring the database down , database was hung and was not coming down and was waiting at the following statement for hours.

Mon Jun  3 18:59:02 2013
Job queue slave processes stopped
Mon Jun  3 18:59:05 2013
ALTER DATABASE CLOSE NORMAL
Mon Jun  3 18:59:05 2013
SMON: disabling tx recovery


Later on when i went digging the problem i found out that there were temporary segments in database .  use following query to verify..

Select * from dba_segments where segment_type='TEMPORARY';

OWNER                          SEGMENT_NAME                   SEGMENT_TYPE       TABLESPACE_NAME                     Size in GB
------------------------------ ------------------------------ ------------------ ------------------------------ --------------------
USER1                       792.200737                     TEMPORARY          TBLSPC_ DATA01                          43.857872


SMON was trying to clean up the temporary segemnts for a clean shutdown, but it was just hanging there.

I did a sanity check to verify  the temporary segments issue using  following check list

1.)     Checked V$sessions and it doesn't show any sessions for the USER1 schema.
2.)     Checked V$session_longops and it doesn't show any entries.
3.)     Checked  if SMON is disabled for cleanup of temporary segments. There is no event set to value 10 . there is one event which is set to 4
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
event                                string      10499 trace name context forever, level 4


But nothing came out of it.

Later i found out a simple way to do so. 

1.) Shutdown Abort
2.) Startup
3.) Shutdown immediate

Next you start the database in mount state and issue the Alter database Archivelog command and that does the magic.

4.) Startup mount
5.) Alter database archivelog;
6.) alter database open

Further details :

 Metalink Note 1076161.6 
Description
===========
SHUTDOWN NORMAL or SHUTDOWN IMMEDIATE hangs. In the alert.log, you see only
the following:

Shutting down instance (immediate)
License high water mark = 12
Thu Dec  8 18:43:16 1994
alter database  close normal
Thu Dec  8 18:43:17 1994
SMON: disabling tx recovery
SMON: disabling cache recovery
or
     waiting for smon to disable tx recovery

There are no ORA errors or trace files.



Scope & Application
===================
Informational

During a SHUTDOWN IMMEDIATE and SHUTDOWN NORMAL, SMON is cleaning up extents
which are no longer needed and marking them as freed.

Either wait for SMON to clean up the free extents in the database as it
shuts down or perform a SHUTDOWN ABORT to shutdown the instance. A SHUTDOWN
ABORT will not perform a clean shutdown.

Verify that temporary segments are decreasing
---------------------------------------------
To verify that the temporary segments are decreasing have an active session
available in Server Manager or SQLPLUS during the SHUTDOWN IMMEDIATE. Issue the following
query to ensure the database is not hanging, but is actually perform extent
cleanup:

 SVRMGR/SQL> select count(block#) from fet$;
 COUNT(BLOC
 ----------
          7

 SVRMGR/SQL> select count(block#) from uet$;
 COUNT(BLOC
 ----------
        402

After some time has elapsed, reissue the query and see that the values for fet$
have increased while the values or uet$ have decreased:

 SVRMGR/SQL> select count(block#) from fet$;
 COUNT(BLOC
 ----------
         10

 SVRMGR/SQL> select count(block#) from uet$;
 COUNT(BLOC
 ----------
        399

During shutdown the SMON process is cleaning up extents and updating the data
dictionary tables with the marked free extents. As the extents are marked as
freed, they are removed from the table for used extents, UET$ and placed on the
table for free extents, FET$.

How to Avoid creating many Temporary Extents
--------------------------------------------
Once the database has shutdown cleanly, to avoid creating many temporary
extents change the initial and next extent sizes on temporary tablespaces
to a more appropriate size:

 ALTER TABLESPACE  DEFAULT STORAGE (INITIAL M/K NEXT M/K);

Note: If the temporary tablespace is of type TEMPORARY, then this change
will only affect temporary segments created after issuing the above
command. Any existing temporary segments already in the TEMPORARY tablespace
will not be affected till the instance is restarted. On shutdown, existing
temporary segments are dropped. If the TEMPORARY TABLESPACE is of type
PERMANENT, then cleanup is performed by SMON after completion of the process
using it.

Increasing the initial and next extent size will decrease the number of extents
that are allocated to temporary segments. Since there are fewer extents to
deallocate, the database should shutdown more speedily.

Take the following scenario:

A database was subject to large sorts with the following sort parameter in
the "init.ora" file:

      - sort_area_size=1000000

The temporary tablespaces for this database were all created with initial and
next extents sized at 50k and the total database size was about 300mb.

Database sorts will utilize memory as much as possible based on the "init.ora"
parameter "sort_area_size".  Once this memory-based sort area is filled, the
database will utilize the temporary table space associated with the database
user to complete the sort operation.  During a shutdown normal, the database
will attempt to clean up the temporary tablespaces.

If a small extent size is used, then a large number of extents will be created
for a large sort.  The cleanup of the temporary tablespace takes much longer
with a large number of extents.

Note:
=====
You have to do a shutdown abort and then bring the database
back up to run the suggested queries.

For other reasons for slow/hung shutdown see also these notes:

Note 375935.1 - What To Do and Not To Do When 'shutdown immediate' Hangs
Note 428688.1 - Bug 5057695: Shutdown Immediate Very Slow To Close Database.

References:
===========
Note 61997.1 SMON - Temporary Segment Cleanup and Free Space Coalescing