Oracle News

Tuesday, April 22, 2014

RMAN-06457 UNTIL SCN is ahead of last SCN in archived logs

#!/bin/ksh

export ORACLE_SID=OIDTEST

rman msglog restore_OIDTEST.log append<< EOF
connect target sys/@OID
connect auxiliary /
run
{
allocate auxiliary channel ch01 type disk;
allocate auxiliary channel ch02 type disk;
allocate auxiliary channel ch03 type disk;
allocate auxiliary channel ch04 type disk;
set until time "to_date('06-AUG-2012 10:00:00','DD-MON-YYYY HH24:MI:SS')";
duplicate target database to OIDTEST;
}
exit
EOF

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 08/07/2012 11:12:13
RMAN-06457: UNTIL SCN (488979215) is ahead of last SCN in archived logs (486144524)

When I looked at the SCN's they all still reflecting the old chnages/date and my restore is trying to go beyond these SCN's.

SQL> select thread#, status, enabled, checkpoint_time, checkpoint_change# from v$thread;

   THREAD# STATUS ENABLED CHECKPOIN CHECKPOINT_CHANGE#
---------- ------ -------- --------- ------------------
         1 OPEN   PUBLIC   03-AUG-12          486144524
         2 OPEN   PUBLIC   05-AUG-12          488215686
         3 OPEN   PUBLIC   04-AUG-12          486909043

Do a check point.

SQL> alter system checkpoint;

System altered.

SQL> select thread#, status, enabled, checkpoint_time, checkpoint_change# from v$thread;

   THREAD# STATUS ENABLED CHECKPOIN CHECKPOINT_CHANGE#
---------- ------ -------- --------- ------------------
         1 OPEN   PUBLIC   07-AUG-12          490100101
         2 OPEN   PUBLIC   07-AUG-12          490100101
         3 OPEN   PUBLIC   07-AUG-12          490100100

Now check what you have in the v$log. If they still reflect the old Change#'s then switch logfiles until all the threads are changed.

SQL> alter system switch logfile;

System altered.

SQL> alter system switch logfile;

System altered.

SQL> alter system switch logfile;

System altered.

SQL> alter system switch logfile;

System altered.

SQL> alter system switch logfile;

System altered.

SQL> alter system switch logfile;

System altered.

SQL> alter system switch logfile;

System altered.

SQL> alter system switch logfile;

System altered.

SQL> alter system switch logfile;

System altered.

SQL>

Restart the duplication process..happy duplicating..

DG database recovery

1.Backup ---
rman target /

run {
allocate channel c1 type disk;
allocate channel c2 type disk;
allocate channel c3 type disk;
allocate channel c4 type disk;
backup as compressed backupset archivelog from time "to_date('21.04.2014 21:00:00','DD.MM.YYYY HH24:Mi:SS')" until time "to_date('21.04.2014 22:13:14','DD.MM.YYYY HH24:Mi:SS')" format '/home/lingesan/arch_%U';
}

2.Copy the backup pieces and new standby controlfile to DG

3.Restore ----
run
{
catalog start with '/home/lingesan';
allocate channel c1 type disk ;
restore archivelog from time "to_date('21.04.2014 21:00:00','DD.MM.YYYY HH24:Mi:SS')" until time "to_date('21.04.2014 22:13:14','DD.MM.YYYY HH24:Mi:SS')";
}

ORA-01586 ORA-39701 database must be mounted EXCLUSIVE and not open for this operation

Dropping the database :

Mount the database in restrict mode:
SQL> startup mount restrict;
ORACLE instance started.

Database mounted.

SQL> select instance_name from v$instance;

INSTANCE_NAME
----------------
dbm1

SQL> drop database;

Database dropped.

What if you get the below error:

SQL> startup mount restrict;
ORACLE instance started.

Database mounted.
SQL> drop database;
drop database
*
ERROR at line 1:
ORA-01586: database must be mounted EXCLUSIVE and not open for this operation

Even the startup upgrade will fail:

SQL> startup upgrade
ORACLE instance started.

Total System Global Area 3206836224 bytes
Fixed Size                  2232640 bytes
Variable Size             704646848 bytes
Database Buffers         2348810240 bytes
Redo Buffers              151146496 bytes
Database mounted.
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-39701: database must be mounted EXCLUSIVE for UPGRADE or DOWNGRADE
Process ID: 46501
Session ID: 652 Serial number: 3

Then mostly likely you are destroying a RAC database and you need to change the cluster_database=FALSE.

SQL> alter system set cluster_database=FALSE scope=spfile;

System altered.

SQL> startup mount restrict;
ORACLE instance started.

Redo Buffers              151146496 bytes
Database mounted.

SQL> select instance_name from v$instance;

INSTANCE_NAME
----------------
dbm1

SQL> drop database;

Database dropped.

Wednesday, June 19, 2013

Direct NFS

You can get info from the following views:
– View servers accessed using Direct NFS
select * from v$dnfs_servers;
– View files currently open using Direct NFS
select * from v$dnfs_files;
– View open network paths or channels to servers for which Direct NFS is providing files
select * from v$dnfs_channels;
– View performance statistics for Direct NFS
select * from v$dnfs_stats;
Also you will see in the alert log on startup:
Oracle instance running with ODM: Oracle Direct NFS ODM Library Version 2.0
Disable DNFS
Shutdown DB
On all hosts:
cd $ORACLE_HOME/lib
mv libodm11.so_bak libodm11.so
Restart Instance
For Completeness, to enable:
Enable DFNS
Shutdown DB
On all hosts:
cd $ORACLE_HOME/lib
mv libodm11.so libodm11.so_bak
ln –s libnfsodm11.so libodm11.so
Restart Instance
Useful SQL
– View servers accessed using Direct NFS
select * from v$dnfs_servers;
– View files currently open using Direct NFS
select * from v$dnfs_files;
– View open network paths or channels to servers for which Direct NFS is providing files
select * from v$dnfs_channels;
– View performance statistics for Direct NFS
select * from v$dnfs_stats;

Known Issue
Getting the following message in alert log and instance not starting:
Direct NFS: please check that oradism is setuid
To correct, the following permissions are needed on:
ls -la $ORACLE_HOME/bin/oradism
-rwsr-x— 1 root oinstall 72416 Sep 11 2008 /u01/app/oracle/product/11.1/db/bin/oradism
If NOT this, shutdown DB and change permission as follows:
sudo su
cd /u01/app/oracle/product/11.1/db/bin
chmod 750 oradism
chmod u+s oradism
Restart instance

Monday, June 17, 2013

Changing Database Character Set (Oracle 11g)

February 14, 2013

1. Install csscan Utility

The first step is to install the csscan utility in the database. Follow note 745809.1 for this. Please run the following script in database:

SQL> @?/rdbms/admin/csminst.sql

This script will create the CSMIG user account in the database and the script creates the user and assigns a default tablespace of SYSTEM. A number of CSM$ tables are created in the CSMIG schema.

2. Running the csscan utility

The csscan will do a full table scan of all the tables in the database and this could cause a performance impact. So run the csscan at an appropriate time period.

$ export LD_LIBRARY_PATH=$ORACLE_HOME/lib $ csscan \”sys/xxxxx as sysdba\” FULL=Y FROMCHAR=AL32UTF8 TOCHAR=WE8MSWIN1252 LOG=win1252 CAPTURE=Y ARRAY=1000000 PROCESS=2

csscan will produce three files with the . err, .txt and .out extensions and the name of each will depend on the value used for the LOG parameter.

The .out file is basically a log of all the scan activity performed .
The .txt file is the most important file as it has the Database Scan Summary Report
The .err file will list all the ‘exception’ rows – rows with lossy data or truncated data or convertible data.

The Conversion Summary section

The Conversion Summary section of the .txt file is the most important section of the Scan Summary Report and has 4 columns showing the possible status of the data

Changeless: All the characters use the same codepoints in the new characterset as compared to the old characterset and no action needs to be taken. The csalter or ALTER DATABASE CHARACTERSET command will handle that for us.
Convertible: The data is valid, but the characters will change to a different code point in the new characterset. In this case for any application data reported as convertible, we need to export the data, truncate the tables or delete the data, change the characterset using csalter or ALTER DATABASE and then import after characterset has been changed.
Truncation: In case of going from a single byte characterset to a multiple byte characterset, the data will grow and we will need to increase the column size in this case. In this case, the .err file will tell us by how much the data is going to grow post conversion and we need to accordingly modify the column sizes of the affected tables.
Lossy: If we see data in the Lossy column, then it means that the either the data is not a valid code point for the current characterset, or the proposed target characterset does not define that data. If we see data listed as lossy, we CANNOT use Export/Import to change characterset, but need to use either ALTER DATABASE CHARACTERSET command for 8i and 9i and csalter for 10g and upwards.

[Application Data Conversion Summary]
 
Datatype                    Changeless      Convertible       Truncation            Lossy
--------------------- ---------------- ---------------- ---------------- ----------------
VARCHAR2                10,538,740,813                0                0                0
CHAR                       922,484,552                0                0                0
LONG                            34,823                0                0                0
CLOB                        76,562,599                0                0                0
VARRAY                               0                0                0                0
--------------------- ---------------- ---------------- ---------------- ----------------
Total                   11,537,822,787                0                0                0

3. Performing the actual characterset conversion.

Shutdown and startup the database in restricted mode. Run the csalter.plb which will prompt us to enter a confirmation.

Successful Execution:

SQL> @?/rdbms/admin/csalter.plb
0 rows created.
Function created.
Function created.
Procedure created.
This script will update the content of the Oracle Data Dictionary.
Please ensure you have a full backup before initiating this procedure.
Would you like to proceed (Y/N)?Y
old 6: if (UPPER(‘&conf’) <> ‘Y’) then
new 6: if (UPPER(‘Y’) <> ‘Y’) then
Checking data validity…
begin converting system objects
20 rows in table SYS.WRI$_DBU_HWM_METADATA are converted
737 rows in table SYS.WRH$_SQLTEXT are converted
167 rows in table SYS.WRI$_DBU_FEATURE_METADATA are converted
121 rows in table SYS.WRI$_DBU_FEATURE_USAGE are converted
21134 rows in table SYS.WRH$_SQL_PLAN are converted
1 row in table SYS.RULE$ is converted
34 rows in table SYS.WRI$_ADV_OBJECTS are converted
178 rows in table SYS.METASTYLESHEET are converted
4971 rows in table SYS.SCHEDULER$_EVENT_LOG are converted
5 rows in table SYS.WRI$_ADV_DIRECTIVE_META are converted
27 rows in table SYS.WRI$_REPT_FILES are converted
PL/SQL procedure successfully completed.
Alter the database character set…
CSALTER operation completed, please restart database
PL/SQL procedure successfully completed.
0 rows deleted.
Function dropped.
Function dropped.
Procedure dropped.

Failed Execution

This fails to perform the characterset Conversion.

4. Alternative Method

Shutdown the database and start it in restricted mode.

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup restrict
ORACLE instance started.

Total System Global Area 5277921280 bytes
Fixed Size                  2213096 bytes
Variable Size            3556772632 bytes
Database Buffers         1677721600 bytes
Redo Buffers               41213952 bytes
Database mounted.
Database opened.

Perform the character set conversion:

SQL> select name from v$database;
NAME
———
DEV

SQL> ALTER DATABASE CHARACTER SET INTERNAL_USE WE8MSWIN1252 ;
Database altered.

SQL> select value from NLS_DATABASE_PARAMETERS where parameter=’NLS_CHARACTERSET’;
VALUE
—————————————-
WE8MSWIN1252

SQL>
SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.
SQL> startup
ORACLE instance started.

Total System Global Area 5277921280 bytes
Fixed Size                  2213096 bytes
Variable Size            3556772632 bytes
Database Buffers         1677721600 bytes
Redo Buffers               41213952 bytes
Database mounted.
Database opened.
SQL> select value from NLS_DATABASE_PARAMETERS where parameter=’NLS_CHARACTERSET’;

VALUE
—————————————-
WE8MSWIN1252

SQL> exit

5. Run the following commands

SQL>@$ORACLE_HOME/rdbms/admin/catalog
SQL>@$ORACLE_HOME/rdbms/admin/catproc
Reload the datapump utility by executing the below scripts: SQL>@$ORACLE_HOME/rdbms/admin/catmet2.sql SQL>@$ORACLE_HOME/rdbms/admin/utlrp.sql

Sunday, October 7, 2012

adlnktools.sh. Fails with return code = .46 (/usr/lib/libXtst.so.6: undefined reference to `__stack_chk_fail@GLIBC_2.4)

Recently i got a issue when Application Relinking is going on. here is the issue description in detail.

Error Message: Error while running adlnktools.sh. return code = .46
bash-3.2$ sh adlnktools.sh
adlnktools.sh started
Log file located at /test/mtlog/test_redhat39/logs/ora/10.1.2/install/make_03231238.log

Error while running adlnktools.sh.
return code = .46
Please check logfile located at /test/mtlog/test_redhat39/logs/ora/10.1.2/install/make_03231238.log

Logfile Error :
==================
/usr/lib/libXtst.so.6: undefined reference to `__stack_chk_fail@GLIBC_2.4′
/usr/lib/libXtst.so.6: undefined reference to `__fprintf_chk@GLIBC_2.3.4′
/usr/lib/libXtst.so.6: undefined reference to `__sprintf_chk@GLIBC_2.3.4′
collect2: ld returned 1 exit status
make: *** [rwrun] Error 1
Failed linking target proxy_install runm_install server_install cgi_install cli_install conv_install qv_install on Tue Dec 23
Solution Offerd:
===================
Login as root
cd /usr/lib
rm libXtst.so.6
ln -s /usr/X11R6/lib/libXtst.so.6.1 /usr/lib/libXtst.so.6
Prior
——–
lrwxrwxrwx 1 root root 16 Jan 15 17:59 libXtst.so.6 -> libXtst.so.6.1.0
Now
———
lrwxrwxrwx 1 root root 29 Jan 19:44 libXtst.so.6 -> /usr/X11R6/lib/libXtst.so.6.1
This Resolved the issue. Relink has been Done after this.
Ref Note: Oracle Forms Upgrade to 10.1.2.3 fails with error /usr/lib/libXtst.so.6: undefined reference (Doc ID 1120527.1)
Happy Troubleshooting.

Monday, July 23, 2012

Patchset and PSU and CPU

Based on my experiences with 11gR2, looks like PSU is the way to go. For example we applied PSU3 to resolve mutex issues since there was no one-off fix w/o the PSU route. I also thought that PSUs were more flexible than I initially assumed because when we encountered another bug(10190759), the bug fix was available only for 11.2.0.2 (w/o PSU 3). Oracle still recommended applying this patch to 11.2.0.2.3(with PSU3) and it worked.

Patch sets and PSU

PSU’s(Patch set updates) are patch sets but with some major differences with respect to regular patch sets.

PSUs are generally low risk and do not contain fixes to bugs that require configuration changes or impact database components like optimizer. To achieve this low risk behavior, Each PSU is limited from 25 to 100 new bug fixes. PSU’s are also well tested by Oracle compared to one off patches.

PSUs are referenced by their 5th place in the Oracle version numbers which makes it easier to track ( (e.g. 10.2.0.3.1) and will not change the version of oracle binaries (like sqlplus, exp/imp etc.) As of now (10.2, 11,2) , the best way to determine the PSU version installed is to use opatch utility using the command below

opatch lsinv -bugs_fixed | grep -i PSU

From the database , you can execute the following query(Assuming that catbundle.sql was executed when PSU was installed). The last 2 columns will provide information about the PSU.

select substr(action_time,1,30) action_time, substr(id,1,10) id, substr(action,1,10) action,substr(version,1,8) version,
substr(BUNDLE_SERIES,1,6) bundle, substr(comments,1,20) comments from registry$history;

In summary PSU’s contain fix for bugs that cause

Instance crash
Wrong results
Data Corruption

PSU’s do not contain fix for bugs that may result in

Dictionary changes
Major Algorithm changes
Architectural changes
Optimizer plan changes

Regular patch sets on other hand include major bug fixes and most of the time requires re-certification. The importance of PSU is diminished once a regular patch set is released for a given version as they tend to be more security related fixes as CPU is part of PSU

PSU and CPU

PSUs contain CPU’s and are released every quarter (like CPU’s) ; In other words Critical Patch Update (CPU) is a subset of the Patch Set Update (PSU). CPU’s are built on the base Patch Set version (e.g. 10.2.0.3) whereas PSU are built on the base of the previous PSU (e.g. 10.2.0.3.1)

A PSU can always be applied over any CPU where as applying a CPU over a PSU will roll back the PSU (at least for now). Therefore it is easy to go from CPUs to PSUs and hard to go back to CPUs from PSUs.