Sunday, August 5, 2018

Summary of ASM Disk Group Attributes


ASM Disk group attributes are parameters that are bound to a disk group, these attributes can be set when a disk group is created or altered.

Here is the list of attributes:

ACCESS_CONTROL.ENABLED
ACCESS_CONTROL.UMASK
AU_SIZE
CELL.SMART_SCAN_CAPABLE
CELL.SPARSE_DG
COMPATIBLE.ASM
COMPATIBLE.RDBMS
COMPATIBLE.ADVM
CONTENT.CHECK
CONTENT.TYPE
DISK_REPAIR_TIME
FAILGROUP_REPAIR_TIME
IDP.BOUNDARY and IDP.TYPE
PHYS_META_REPLICATED
SECTOR_SIZE
STORAGE.TYPE
THIN_PROVISIONED

Lets see an example:

oragrid@irafmdr01:~$ asmcmd lsattr -G DATA_USG -l
Name                        Value
access_control.enabled      FALSE
access_control.umask        066
appliance._partnering_type  EXADATA FIXED
appliance.mode              TRUE
au_size                     4194304
cell.smart_scan_capable     TRUE
cell.sparse_dg              allnonsparse
compatible.asm              12.1.0.2.0
compatible.rdbms            11.2.0.4.0
content.check               FALSE
content.type                data
disk_repair_time            3.6h
failgroup_repair_time       24.0h
idp.boundary                auto
idp.type                    dynamic
logical_sector_size         512
phys_meta_replicated        true
sector_size                 512
thin_provisioned            FALSE
oragrid@irafmdr01:~$

If you want to check from SQL then use the below SQL.

SQL> SELECT dg.name as diskgroup, SUBSTR(a.name,1,20) as name,
     SUBSTR(a.value,1,25) AS value FROM V$ASM_DISKGROUP dg, V$ASM_ATTRIBUTE a
     WHERE dg.group_number = a.group_number
     and a.name like '%smart%';  2    3    4

DISKGROUP                      NAME                     VALUE
------------------------------ ------------------------ ------------------------
DATA_DG1                       cell.smart_scan_capable  TRUE
DBFS_DG1                       cell.smart_scan_capable  TRUE
RECO_DG1                       cell.smart_scan_capable  TRUE

Cluster name


Sometime we might need to check our cluster name in our RAC, lets see how to check it.

login to server using grid user and go to $ORA_CRS_HOME/bin or in some servers we might have set ORA_CRS_HOME as ORACLE_HOME where cluster binaries were installed.

Which ever applicable to your environment switch it.

oragrid@vsc02zdbadm020102:cd $ORA_CRS_HOME/bin

Now simply type ./cemutlo and entry to see the available options.

oragrid@vsc02zdbadm020102:/u01/app/12.1.0.2/grid/bin$ ./cemutlo
Usage: ./cemutlo.bin [-n] [-w]
        where:
        -n prints the cluster name
        -w prints the clusterware version in the following format:
                 <major_version>:<minor_version>:<vendor_info>
oragrid@vsc02zdbadm020102:/u01/app/12.1.0.2/grid/bin$

As we need to know only the cluster name use ./cemutlo -n to see what's our cluster name.

oragrid@vsc02zdbadm020102:/u01/app/12.1.0.2/grid/bin$ ./cemutlo -n
tab-clu5
oragrid@vsc02zdbadm020102:/u01/app/12.1.0.2/grid/bin$

Conclusion:  Here is our cluster name "tab-clu5" by default cluster name is "crs".


Thursday, July 19, 2018

Recovery was unable to create the file

Error

WARNING: File being created with same name as in Primary
Existing file may be overwritten
Errors in file /ccbs/appl/oracle/orabase/diag/rdbms/prodtabs/TABS1/trace/TABS1_pr00_4213.trc:
ORA-01119: error in creating database file '+DATA_DG1/tabsdr/u14/prodtabs/tabsxl01_f09.dbf'
ORA-17502: ksfdcre:4 Failed to create file +DATA_DG1/tabsdr/u14/prodtabs/tabsxl01_f09.dbf
ORA-15001: diskgroup "DATA_DG1" does not exist or is not mounted
ORA-15077: could not locate ASM instance serving a required diskgroup
File #308 added to control file as 'UNNAMED00308'.
Originally created as:
'+DATA_DG1/tabsdr/u14/prodtabs/tabsxl01_f09.dbf'
Recovery was unable to create the file as:
'+DATA_DG1/tabsdr/u14/prodtabs/tabsxl01_f09.dbf'
MRP0: Background Media Recovery terminated with error 1274
Errors in file /ccbs/appl/oracle/orabase/diag/rdbms/prodtabs/TABS1/trace/TABS1_pr00_4213.trc:
ORA-01274: cannot add datafile '+DATA_DG1/tabsdr/u14/prodtabs/tabsxl01_f09.dbf' - file could not be created
Tue Jun 12 11:03:40 2018
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Recovery stopped due to failure in applying recovery marker (opcode 17.30).

Cause

Our DR was prepared from filesystem to ASM, after switchover standby_file_management was set to 'AUTO' but DB_FILE_NAME_CONVERT wasn't (missed).

So, when we added datafile in new primary database as '+DATA_DG1/tabsdr/u14/prodtabs/tabsxl01_f09.dbf' it tries to create this file on Standby using the same path as of primary database, as this path is not exist it got failed.

Solution

Frist of all there are many ways to fix, what i followed is as below.

1. Stop recovery
recover managed standby database cancel;
2. Shutdown database
3. Update pfile with all subsequent location of datafiles in DB_FILE_NAME_CONVERT and LOG_FILE_NAME_CONVERT
4. Create spfile from pfile
5. Start database in standby mode.
6. Start recovery
Alter database recover managed standby database  using current logfile disconnect;

By the time i checked the system and applied all these changes huge archive gap generated and archive logs were deleted from production server too.

Now i have to sync DR from incremental bacukp from the SCN from which logs were missing.

To avoid this i used another way.

7. Restore archive logs of primary datatabase directly to standby database server.
8. No need to register archive logs with database, database will read from the location where i'm doing restore.



Wednesday, July 11, 2018

OAV-46599: internal error

Error

While deleting target from Audit vault i got an error.




Cause

Java framework was not running.


Solution


Start Java framework and retry delete.


Sunday, July 8, 2018

Changing database name using NID


1. Shutdown your database.
2. Start it in mount stage.
3. Run nid to apply changes.
4. After successful completion start database with resetlogs.

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

Total System Global Area 3206836224 bytes
Fixed Size                  2257520 bytes
Variable Size            1778388368 bytes
Database Buffers         1409286144 bytes
Redo Buffers               16904192 bytes
Database mounted.
SQL> Disconnected from Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
bash-3.2$
bash-3.2$ nid TARGET=SYS/xxxxxxx DBNAME=UAT

DBNEWID: Release 11.2.0.4.0 - Production on

Copyright (c) 1982, 2011, Oracle and/or its affiliates.  All rights reserved.

Connected to database PROD (DBID=337679511)

Connected to server version 11.2.0

Control Files in database:
    /DB/app/oracle/oradata/UAT/control01.ctl
    /DB/app/oracle/oradata/UAT/control02.ctl

Changing database ID from 337679511 to 3686432641
Changing database name from PROD to UAT
    Control File /DB/app/oracle/oradata/UAT/control01.ctl - modified
    Control File /DB/app/oracle/oradata/UAT/control02.ctl - modified
    Datafile /DB/app/oracle/oradata/UAT/system.294.87146925 - dbid changed, wrote new name
    Datafile /DB/app/oracle/oradata/UAT/sysaux.267.87146925 - dbid changed, wrote new name
    Datafile /DB/app/oracle/oradata/UAT/undotbs1.270.87146925 - dbid changed, wrote new name
    Datafile /DB/app/oracle/oradata/UAT/users.269.87146925 - dbid changed, wrote new name
    Datafile /DB/app/oracle/oradata/UAT/undotbs2.272.87146940 - dbid changed, wrote new name
    Datafile /DB/app/oracle/oradata/UAT/temp.295.87146934 - dbid changed, wrote new name
    Control File /DB/app/oracle/oradata/UAT/control01.ctl - dbid changed, wrote new name
    Control File /DB/app/oracle/oradata/UAT/control02.ctl - dbid changed, wrote new name
    Instance shut down

Database name changed to UAT.
Modify parameter file and generate a new password file before restarting.
Database ID for database UAT changed to 3686432641.
All previous backups and archived redo logs for this database are unusable.
Database has been shutdown, open database with RESETLOGS option.
Succesfully changed database name and ID.
DBNEWID - Completed succesfully.