How to Checksum Downloads

As a DBA, in your time, you will need to download files such as Oracle binaries, patches, etc.  As a rule of thumb, you should always checksum you downloads, to ensure they are free of corruption.  In my example, I needed to download:
Patch 25440397: QUARTERLY FULL STACK DOWNLOAD PATCH FOR EXADATA (Apr 2017 – 12.1.0.2)

This is the Quarterly Full Stack Download Patch for Exadata, which is 10 zip files that total 13Gb.  That’s a lot of bytes and although highly unlikely, it’s possible for one of them to become corrupt.  Therefore, to avoid downstream pain, check the downloads’ md5 checksum on your machine.  The Microsoft File Checksum Integrity Verifier (FCIV), can be found here:
How to compute the MD5 or SHA-1 cryptographic hash values for a file

Below shows the downloads’ MD5 checksum using FCIV:

Microsoft Windows [Version 10.0.14393]
(c) 2016 Microsoft Corporation. All rights reserved.

C:\Users\anwarz>C:\Users\anwarz\Downloads\md5\fciv.exe "C:\Users\anwarz\Exadata Patching 2017\p25440397_121020_Linux-x86-64_1of10.zip"
//
// File Checksum Integrity Verifier version 2.05.
//
855c3d128adb7f87eee04d7615f20e2b c:\users\anwarz\exadata patching 2017\p25440397_121020_linux-x86-64_1of10.zip

C:\Users\anwarz>C:\Users\anwarz\Downloads\md5\fciv.exe "C:\Users\anwarz\Exadata Patching 2017\p25440397_121020_Linux-x86-64_2of10.zip"
//
// File Checksum Integrity Verifier version 2.05.
//
93cea0dddd371e148f6cb3e35f9faa6a c:\users\anwarz\exadata patching 2017\p25440397_121020_linux-x86-64_2of10.zip

C:\Users\anwarz>C:\Users\anwarz\Downloads\md5\fciv.exe "C:\Users\anwarz\Exadata Patching 2017\p25440397_121020_Linux-x86-64_3of10.zip"
//
// File Checksum Integrity Verifier version 2.05.
//
22318acb7fa36154f0bb6d02115daba4 c:\users\anwarz\exadata patching 2017\p25440397_121020_linux-x86-64_3of10.zip

C:\Users\anwarz>C:\Users\anwarz\Downloads\md5\fciv.exe "C:\Users\anwarz\Exadata Patching 2017\p25440397_121020_Linux-x86-64_4of10.zip"
//
// File Checksum Integrity Verifier version 2.05.
//
28957a7ac3f2b05625cf3058fc97d981 c:\users\anwarz\exadata patching 2017\p25440397_121020_linux-x86-64_4of10.zip

C:\Users\anwarz>C:\Users\anwarz\Downloads\md5\fciv.exe "C:\Users\anwarz\Exadata Patching 2017\p25440397_121020_Linux-x86-64_5of10.zip"
//
// File Checksum Integrity Verifier version 2.05.
//
a1cdad9db470bb10eb14d85c3240fa64 c:\users\anwarz\exadata patching 2017\p25440397_121020_linux-x86-64_5of10.zip

C:\Users\anwarz>C:\Users\anwarz\Downloads\md5\fciv.exe "C:\Users\anwarz\Exadata Patching 2017\p25440397_121020_Linux-x86-64_6of10.zip"
//
// File Checksum Integrity Verifier version 2.05.
//
f358ebbf9e2fc222795176091939054c c:\users\anwarz\exadata patching 2017\p25440397_121020_linux-x86-64_6of10.zip

C:\Users\anwarz>C:\Users\anwarz\Downloads\md5\fciv.exe "C:\Users\anwarz\Exadata Patching 2017\p25440397_121020_Linux-x86-64_7of10.zip"
//
// File Checksum Integrity Verifier version 2.05.
//
3d20be91084b10fcb6fe3aa045346bf1 c:\users\anwarz\exadata patching 2017\p25440397_121020_linux-x86-64_7of10.zip

C:\Users\anwarz>C:\Users\anwarz\Downloads\md5\fciv.exe "C:\Users\anwarz\Exadata Patching 2017\p25440397_121020_Linux-x86-64_8of10.zip"
//
// File Checksum Integrity Verifier version 2.05.
//
7cebaca222e384957b8e65df0de6e6b1 c:\users\anwarz\exadata patching 2017\p25440397_121020_linux-x86-64_8of10.zip

C:\Users\anwarz>C:\Users\anwarz\Downloads\md5\fciv.exe "C:\Users\anwarz\Exadata Patching 2017\p25440397_121020_Linux-x86-64_9of10.zip"
//
// File Checksum Integrity Verifier version 2.05.
//
5a79f025564427a14ab7adce31d1a8bb c:\users\anwarz\exadata patching 2017\p25440397_121020_linux-x86-64_9of10.zip

C:\Users\anwarz>C:\Users\anwarz\Downloads\md5\fciv.exe "C:\Users\anwarz\Exadata Patching 2017\p25440397_121020_Linux-x86-64_10of10.zip"
//
// File Checksum Integrity Verifier version 2.05.
//
34b8bfe3792fa9dbd0cd13ba61bc5696 c:\users\anwarz\exadata patching 2017\p25440397_121020_linux-x86-64_10of10.zip

C:\Users\anwarz>

The MD5 checksums then can verified with what Oracle Support list under the patch, click ‘Download’, then ‘View Digest Details’:

Patch_MD5

Once checked on your machine and then you transfer to server (assuming you didn’t download directly to server using WGET or something), then check again using md5sum:

[oracle@v1oex1dbadm01 25440397]$ md5sum p25440397_121020_linux-x86-64_1of10.zip
 855c3d128adb7f87eee04d7615f20e2b p25440397_121020_linux-x86-64_1of10.zip
[oracle@v1oex1dbadm01 25440397]$ md5sum p25440397_121020_linux-x86-64_2of10.zip
93cea0dddd371e148f6cb3e35f9faa6a p25440397_121020_linux-x86-64_2of10.zip
[oracle@v1oex1dbadm01 25440397]$ md5sum p25440397_121020_linux-x86-64_3of10.zip
22318acb7fa36154f0bb6d02115daba4 p25440397_121020_linux-x86-64_3of10.zip
[oracle@v1oex1dbadm01 25440397]$ md5sum p25440397_121020_linux-x86-64_4of10.zip
28957a7ac3f2b05625cf3058fc97d981 p25440397_121020_linux-x86-64_4of10.zip
[oracle@v1oex1dbadm01 25440397]$ md5sum p25440397_121020_linux-x86-64_5of10.zip
a1cdad9db470bb10eb14d85c3240fa64 p25440397_121020_linux-x86-64_5of10.zip
[oracle@v1oex1dbadm01 25440397]$ md5sum p25440397_121020_linux-x86-64_6of10.zip
f358ebbf9e2fc222795176091939054c p25440397_121020_linux-x86-64_6of10.zip
[oracle@v1oex1dbadm01 25440397]$ md5sum p25440397_121020_linux-x86-64_7of10.zip
3d20be91084b10fcb6fe3aa045346bf1 p25440397_121020_linux-x86-64_7of10.zip
[oracle@v1oex1dbadm01 25440397]$ md5sum p25440397_121020_linux-x86-64_8of10.zip
7cebaca222e384957b8e65df0de6e6b1 p25440397_121020_linux-x86-64_8of10.zip
[oracle@v1oex1dbadm01 25440397]$ md5sum p25440397_121020_linux-x86-64_9of10.zip
5a79f025564427a14ab7adce31d1a8bb p25440397_121020_linux-x86-64_9of10.zip
[oracle@v1oex1dbadm01 25440397]$ md5sum p25440397_121020_linux-x86-64_10of10.zip
34b8bfe3792fa9dbd0cd13ba61bc5696 p25440397_121020_linux-x86-64_10of10.zip
[oracle@v1oex1dbadm01 25440397]$

Once all checked, you’re free to unzip, knowing you’re free from corruption 🙂

Mined you, that doesn’t guarantee you wouldn’t get corruption from I/O but that would be extremely unlucky and you’ll have bigger problems.

If you found this blog post useful, please like as well as follow me through my various Social Media avenues available on the sidebar and/or subscribe to this oracle blog via WordPress/e-mail.

Thanks

Zed DBA (Zahid Anwar)

How to obtain the Historical Database Total Used and Allocated Size from OEM Repository

From time to time, it’s useful to know the total allocated size of a database at OS level, how much of it has been used and what the maximum total size the database can grow to at OS level, see blog post:
How to obtain the Database Total Used, Allocated and Max Size

However, it’s also goo to know the historical size.  The below query will give you this from the Oracle Enterprise Manager (OEM) repository:

SELECT Database,
Month_Date,
round(sum(decode(metric_column, 'spaceUsed', maximum))/1024/1024, 3) Used_Size_Tb,
round(sum(decode(metric_column, 'spaceAllocated', maximum))/1024/1024, 3) Allocated_Size_Tb
FROM
(
SELECT target_name Database, trunc(rollup_timestamp, 'MONTH') Month_Date, key_value TB, metric_column, round(max(maximum),0) maximum
FROM mgmt$metric_daily
WHERE target_type = 'rac_database'
and metric_name = 'tbspAllocation'
and metric_column in ('spaceAllocated', 'spaceUsed')
and target_name in ('VERS')
GROUP BY target_name, key_value, trunc(rollup_timestamp, 'MONTH'), metric_column
)
GROUP BY Database, Month_Date
ORDER BY Database, Month_Date
/

Output:

DATABASE   MONTH_DAT USED_SIZE_TB ALLOCATED_SIZE_TB
---------- --------- ------------ -----------------
VERS       01-SEP-15        1.198             1.554
VERS       01-OCT-15        1.209             1.652
VERS       01-NOV-15          1.3             1.805
...
VERS       01-MAY-17        6.526             7.226
VERS       01-JUN-17        7.085             8.528
VERS       01-JUL-17        7.136             7.569

23 rows selected.

SQL>

The unit is in Tb, which should be suitable for most, however this can be changed by add/removing division of 1024.

If you found this blog post useful, please like as well as follow me through my various Social Media avenues available on the sidebar and/or subscribe to this oracle blog via WordPress/e-mail.

Thanks

Zed DBA (Zahid Anwar)

How to obtain the Database Total Used, Allocated and Max Size

From time to time, it’s useful to know the total allocated size of a database at OS level, how much of it has been used and what the maximum total size the database can grow to at OS level.

The below query will give you this:

SELECT round(sum(used_ts_size)/1024/1024, 2) total_used_db_size_tb,
 round(sum(curr_ts_size)/1024/1024, 2) total_current_db_size_tb,
 round(sum(max_ts_size)/1024/1024, 2) total_max_allocated_db_size_tb
FROM
(SELECT df.tablespace_name, (df.bytes - sum(fs.bytes)) / (1024 * 1024) used_ts_size,
df.bytes / (1024 * 1024) curr_ts_size,
df.maxbytes / (1024 * 1024) max_ts_size
FROM dba_free_space fs,
 (select tablespace_name,
 sum(bytes) bytes,
 sum(decode(maxbytes, 0, bytes, maxbytes)) maxbytes
 from dba_data_files
 group by tablespace_name) df
WHERE fs.tablespace_name (+) = df.tablespace_name
GROUP BY df.tablespace_name,df.bytes,df.maxbytes);

Output:

SQL> SELECT round(sum(used_ts_size)/1024/1024, 2) total_used_db_size_tb,
 2 round(sum(curr_ts_size)/1024/1024, 2) total_current_db_size_tb,
 3 round(sum(max_ts_size)/1024/1024, 2) total_max_allocated_db_size_tb
 4 FROM
 5 (SELECT df.tablespace_name, (df.bytes - sum(fs.bytes)) / (1024 * 1024) used_ts_size,
 6 df.bytes / (1024 * 1024) curr_ts_size,
 7 df.maxbytes / (1024 * 1024) max_ts_size
 8 FROM dba_free_space fs,
 9 (select tablespace_name,
 10 sum(bytes) bytes,
 11 sum(decode(maxbytes, 0, bytes, maxbytes)) maxbytes
 12 from dba_data_files
 13 group by tablespace_name) df
 14 WHERE fs.tablespace_name (+) = df.tablespace_name
 15 GROUP BY df.tablespace_name,df.bytes,df.maxbytes);

TOTAL_USED_DB_SIZE_TB TOTAL_CURRENT_DB_SIZE_TB TOTAL_MAX_ALLOCATED_DB_SIZE_TB
--------------------- ------------------------ ------------------------------
                 7.15                     7.36                           9.04

SQL>

The unit is in Tb, which should be suitable for most, however this can be changed by add/removing division of 1024.

Related Post:
How to obtain the Historical Database Total Used and Allocated Size from OEM Repository

If you found this blog post useful, please like as well as follow me through my various Social Media avenues available on the sidebar and/or subscribe to this oracle blog via WordPress/e-mail.

Thanks

Zed DBA (Zahid Anwar)

KBHS-00600: Internal Error, Arguments [1] [kbhshtCreateDataBucket] Error During Backup To Oracle Cloud

When setting up Oracle Cloud Backup Service for first time and the Oracle Database Cloud Backup Module has been installed successfully using:
Installing the Oracle Database Cloud Backup Module

Your RMAN session will hang and eventually give the following error:

Starting backup at 2017/08/10 12:56:58 
current log archived 
RMAN-00571: =========================================================== 
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== 
RMAN-00571: =========================================================== 
RMAN-03002: failure of backup plus archivelog command at 08/10/2017 16:20:05 
ORA-19554: error allocating device, device type: SBT_TAPE, device name: 
ORA-27023: skgfqsbi: media manager protocol error 
ORA-19511: non RMAN, but media manager or vendor specific failure, error text: 
KBHS-00600: internal error, arguments [1] [kbhshtCreateDataBucket] [] [] []

If the replication policy has not been set for this account, as explained in the MOS Note:
KBHS-00600: Internal Error, Arguments [1] [kbhshtCreateDataBucket] Error During Backup To Cloud (Doc ID 2232778.1)

Details of the replication policy can be found in the following documentation:
Selecting a Replication Policy for Your Service Instance

“Policies that have no georeplication:

These policies specify only the primary data center (DC) that hosts your service instance.

All read and write requests go to the primary DC, always. If the primary DC is unavailable, then the requests fail.

 Such a policy may be adequate if you have standard data-durability requirements and if an occasional failure of read requests (when the primary DC is down) is acceptable.

The Georeplication policies:

These policies specify a primary DC that hosts your service instance as well as a geographically distant, georeplication DC.

Write requests that you send to the global namespace URL are routed to the primary DC. Data that you write is replicated automatically, but asynchronously, to the georeplication DC. The primary and secondary DCs are eventually consistent.

 If the primary DC is unavailable, then write requests fail with the 403 – Forbidden error, but read requests are routed to the georeplication DC. When the primary DC is available again, requests to the global namespace URL are routed to the primary DC.

 You’ll be billed for the sum of the capacities used in both DCs and for the data transfer from the primary to the georeplication DC.

 A policy that has a georeplication DC is ideal if you have advanced durability requirements for your data or if read requests must succeed always regardless of the state of the primary DC.”

The first option, there’s a possibility of not being able to reach your backups but has the benefit of 1:1 ratio on storage used.   The second option has the benefit of guarantees being able to reach your backups but double storage usage and you are charged for data transfer between DC.

Once you select your georeplication policy, your backup will work 🙂

If you found this blog post useful, please like as well as follow me through my various Social Media avenues available on the sidebar and/or subscribe to this oracle blog via WordPress/e-mail.

Thanks

Zed DBA (Zahid Anwar)

Delete Old SBT_TAPE Backups that are No Longer Available in RMAN

When in the situation of having ‘SBT_TAPE’ backups, that are still known by the catalog or control file, but the device type ‘SBT_TAPE’ is no longer available.  If you try to delete the backups you get the following error message:

RMAN> list backup summary;

List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
11208 B 0 A SBT_TAPE 20-JUL-17 1 1 YES TAG20170720T200232
11209 B 0 A SBT_TAPE 20-JUL-17 1 1 YES TAG20170720T200232
11210 B 0 A SBT_TAPE 20-JUL-17 1 1 YES TAG20170720T200232
...
11356 B 0 A SBT_TAPE 28-JUL-17 1 1 YES TAG20170728T200202
11357 B 0 A SBT_TAPE 28-JUL-17 1 1 YES TAG20170728T200202
11358 B A A SBT_TAPE 28-JUL-17 1 1 YES TAG20170728T201725

RMAN> delete backup;

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of delete command at 08/10/2017 12:49:55
ORA-19554: error allocating device, device type: SBT_TAPE, device name:
ORA-27211: Failed to load Media Management Library
Additional information: 2

 

This is because the backups are of device type ‘SBT_TAPE’, which is no longer available.  To remove, you need to allocate channel for maintenance of device type ‘SBT’ but dummy to disk as explained in MOS Note:

Need Help To Remove Old Tape Backups From Catalog (Doc ID 342284.1)

GOAL

How to delete obsolete TAPE backups via RMAN, when the Media Management Layer (MML Software not installed) is NOT available anymore.

So how to delete OLD backups which have been made to tape, while the current backup strategy is to disk and NO Media Manager is available.

SOLUTION

Allocate a maintenance channel with the dummy sbt API and run the DELETE FORCE OBSOLETE.

RMAN> allocate channel for maintenance device type sbt
parms 'SBT_LIBRARY=oracle.disksbt, ENV=(BACKUP_DIR=/tmp)';


RMAN> delete force obsolete;

The DUMMY API (oracle.disksbt) is simulating the callout to the Media Management Layer (MML).  This way RMAN thinks an actual MML is available and can perform the maintenance.”

My scenario:

RMAN> allocate channel for maintenance device type sbt
2> parms 'SBT_LIBRARY=oracle.disksbt, ENV=(BACKUP_DIR=/tmp)';

allocated channel: ORA_MAINT_SBT_TAPE_1
channel ORA_MAINT_SBT_TAPE_1: SID=808 device type=SBT_TAPE
channel ORA_MAINT_SBT_TAPE_1: WARNING: Oracle Test Disk API

RMAN> delete force obsolete;

RMAN retention policy will be applied to the command
RMAN retention policy is set to recovery window of 8 days
Deleting the following obsolete backups and copies:
Type Key Completion Time Filename/Handle
-------------------- ------ ------------------ --------------------
Backup Set 11217 20-JUL-17
 Backup Piece 11217 20-JUL-17 vks9rkqo_1_1
Backup Set 11214 20-JUL-17
 Backup Piece 11214 20-JUL-17 vls9rkqo_1_1
Backup Set 11216 20-JUL-17
 Backup Piece 11216 20-JUL-17 vms9rkqo_1_1
...
 Backup Piece 11341 28-JUL-17 3tsagnmq_1_1
Backup Set 11346 28-JUL-17
 Backup Piece 11346 28-JUL-17 3usagnmq_1_1
Backup Set 11340 28-JUL-17
 Backup Piece 11340 28-JUL-17 3vsagnmq_1_1

Do you really want to delete the above objects (enter YES or NO)? yes
deleted backup piece
backup piece handle=vks9rkqo_1_1 RECID=11217 STAMP=949867353
deleted backup piece
backup piece handle=vls9rkqo_1_1 RECID=11214 STAMP=949867353
deleted backup piece
backup piece handle=vms9rkqo_1_1 RECID=11216 STAMP=949867353
...
deleted backup piece
backup piece handle=3tsagnmq_1_1 RECID=11341 STAMP=950558426
deleted backup piece
backup piece handle=3usagnmq_1_1 RECID=11346 STAMP=950558426
deleted backup piece
backup piece handle=3vsagnmq_1_1 RECID=11340 STAMP=950558426
Deleted 132 objects

RMAN>

 

You may still have some ‘SBT_TAPE’ backups remaining due to your retention policy and hence the backups are not obsolete, therefore you need to crosscheck as follows:

RMAN> list backup summary;

List of Backups
===============
Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- ---
11348 B 0 A SBT_TAPE 28-JUL-17 1 1 YES TAG20170728T200202
11349 B 0 A SBT_TAPE 28-JUL-17 1 1 YES TAG20170728T200202
11350 B 0 A SBT_TAPE 28-JUL-17 1 1 YES TAG20170728T200202
11351 B 0 A SBT_TAPE 28-JUL-17 1 1 YES TAG20170728T200202
11352 B 0 A SBT_TAPE 28-JUL-17 1 1 YES TAG20170728T200202
11353 B 0 A SBT_TAPE 28-JUL-17 1 1 YES TAG20170728T200202
11354 B 0 A SBT_TAPE 28-JUL-17 1 1 YES TAG20170728T200202
11355 B 0 A SBT_TAPE 28-JUL-17 1 1 YES TAG20170728T200202
11356 B 0 A SBT_TAPE 28-JUL-17 1 1 YES TAG20170728T200202
11357 B 0 A SBT_TAPE 28-JUL-17 1 1 YES TAG20170728T200202
11358 B A A SBT_TAPE 28-JUL-17 1 1 YES TAG20170728T201725

RMAN> allocate channel for maintenance device type sbt
2> parms 'SBT_LIBRARY=oracle.disksbt, ENV=(BACKUP_DIR=/tmp)';

allocated channel: ORA_MAINT_SBT_TAPE_1
channel ORA_MAINT_SBT_TAPE_1: SID=17 device type=SBT_TAPE
channel ORA_MAINT_SBT_TAPE_1: WARNING: Oracle Test Disk API

RMAN> delete backup;

List of Backup Pieces
BP Key BS Key Pc# Cp# Status Device Type Piece Name
------- ------- --- --- ----------- ----------- ----------
11348 11348 1 1 AVAILABLE SBT_TAPE 46sagnpr_1_1
11349 11349 1 1 AVAILABLE SBT_TAPE 47sagnpr_1_1
11350 11350 1 1 AVAILABLE SBT_TAPE 44sagnpr_1_1
11351 11351 1 1 AVAILABLE SBT_TAPE 48sagnqb_1_1
11352 11352 1 1 AVAILABLE SBT_TAPE 49sagnqb_1_1
11353 11353 1 1 AVAILABLE SBT_TAPE 45sagnpr_1_1
11354 11354 1 1 AVAILABLE SBT_TAPE 41sagnpr_1_1
11355 11355 1 1 AVAILABLE SBT_TAPE 43sagnpr_1_1
11356 11356 1 1 AVAILABLE SBT_TAPE 42sagnpr_1_1
11357 11357 1 1 AVAILABLE SBT_TAPE 40sagnpr_1_1
11358 11358 1 1 AVAILABLE SBT_TAPE 4asagoml_1_1

Do you really want to delete the above objects (enter YES or NO)? yes

RMAN-06207: WARNING: 11 objects could not be deleted for SBT_TAPE channel(s) due
RMAN-06208: to mismatched status. Use CROSSCHECK command to fix status
RMAN-06210: List of Mismatched objects
RMAN-06211: ==========================
RMAN-06212: Object Type Filename/Handle
RMAN-06213: --------------- ---------------------------------------------------
RMAN-06214: Backup Piece 46sagnpr_1_1
RMAN-06214: Backup Piece 47sagnpr_1_1
RMAN-06214: Backup Piece 44sagnpr_1_1
RMAN-06214: Backup Piece 48sagnqb_1_1
RMAN-06214: Backup Piece 49sagnqb_1_1
RMAN-06214: Backup Piece 45sagnpr_1_1
RMAN-06214: Backup Piece 41sagnpr_1_1
RMAN-06214: Backup Piece 43sagnpr_1_1
RMAN-06214: Backup Piece 42sagnpr_1_1
RMAN-06214: Backup Piece 40sagnpr_1_1
RMAN-06214: Backup Piece 4asagoml_1_1

RMAN> crosscheck backup;

crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=46sagnpr_1_1 RECID=11348 STAMP=950558523
crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=47sagnpr_1_1 RECID=11349 STAMP=950558524
crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=44sagnpr_1_1 RECID=11350 STAMP=950558523
crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=48sagnqb_1_1 RECID=11351 STAMP=950558539
crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=49sagnqb_1_1 RECID=11352 STAMP=950558539
crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=45sagnpr_1_1 RECID=11353 STAMP=950558523
crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=41sagnpr_1_1 RECID=11354 STAMP=950558523
crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=43sagnpr_1_1 RECID=11355 STAMP=950558523
crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=42sagnpr_1_1 RECID=11356 STAMP=950558523
crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=40sagnpr_1_1 RECID=11357 STAMP=950558523
crosschecked backup piece: found to be 'EXPIRED'
backup piece handle=4asagoml_1_1 RECID=11358 STAMP=950559445
Crosschecked 11 objects

RMAN> delete expired backup;

List of Backup Pieces
BP Key BS Key Pc# Cp# Status Device Type Piece Name
------- ------- --- --- ----------- ----------- ----------
11348 11348 1 1 EXPIRED SBT_TAPE 46sagnpr_1_1
11349 11349 1 1 EXPIRED SBT_TAPE 47sagnpr_1_1
11350 11350 1 1 EXPIRED SBT_TAPE 44sagnpr_1_1
11351 11351 1 1 EXPIRED SBT_TAPE 48sagnqb_1_1
11352 11352 1 1 EXPIRED SBT_TAPE 49sagnqb_1_1
11353 11353 1 1 EXPIRED SBT_TAPE 45sagnpr_1_1
11354 11354 1 1 EXPIRED SBT_TAPE 41sagnpr_1_1
11355 11355 1 1 EXPIRED SBT_TAPE 43sagnpr_1_1
11356 11356 1 1 EXPIRED SBT_TAPE 42sagnpr_1_1
11357 11357 1 1 EXPIRED SBT_TAPE 40sagnpr_1_1
11358 11358 1 1 EXPIRED SBT_TAPE 4asagoml_1_1

Do you really want to delete the above objects (enter YES or NO)? yes
deleted backup piece
backup piece handle=46sagnpr_1_1 RECID=11348 STAMP=950558523
deleted backup piece
backup piece handle=47sagnpr_1_1 RECID=11349 STAMP=950558524
deleted backup piece
backup piece handle=44sagnpr_1_1 RECID=11350 STAMP=950558523
deleted backup piece
backup piece handle=48sagnqb_1_1 RECID=11351 STAMP=950558539
deleted backup piece
backup piece handle=49sagnqb_1_1 RECID=11352 STAMP=950558539
deleted backup piece
backup piece handle=45sagnpr_1_1 RECID=11353 STAMP=950558523
deleted backup piece
backup piece handle=41sagnpr_1_1 RECID=11354 STAMP=950558523
deleted backup piece
backup piece handle=43sagnpr_1_1 RECID=11355 STAMP=950558523
deleted backup piece
backup piece handle=42sagnpr_1_1 RECID=11356 STAMP=950558523
deleted backup piece
backup piece handle=40sagnpr_1_1 RECID=11357 STAMP=950558523
deleted backup piece
backup piece handle=4asagoml_1_1 RECID=11358 STAMP=950559445
Deleted 11 EXPIRED objects

RMAN>

Now you can continue to use device type ‘DISK’ or configure a new ‘SBT_TAPE’ 🙂

 

If you found this blog post useful, please like as well as follow me through my various Social Media avenues available on the sidebar and/or subscribe to this oracle blog via WordPress/e-mail.

Thanks

Zed DBA (Zahid Anwar)

RMAN-06403: could not obtain a fully authorized session

An automated process that refreshes a Development database from Production by doing a RMAN duplicate failed with ‘RMAN-06403: could not obtain a fully authorized session’:

Starting Duplicate Db at 25-JUL-2017 17:44
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 07/25/2017 17:44:46
RMAN-05501: aborting duplication of target database
RMAN-06403: could not obtain a fully authorized session
RMAN-04006: error from auxiliary database: ORA-01034: ORACLE not available
ORA-27101: shared memory realm does not exist
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3651
Additional information: 1054940735

 

This was initially puzzling as nothing appeared to have changed.  A ‘My Oracle Support’ (MOS) search, revealed the following MOS note:

Duplicating database using RMAN fails with errors RMAN-06403, RMAN-04006, ORA-01034, ORA-27101 (Doc ID 274233.1)

CAUSE

The errors are occurring because the auxiliary database is not started in nomount state.

SOLUTION

The auxiliary instance must be in a nomount state during duplication of database using RMAN.

Startup the auxiliary instance in nomount state.  Then try to duplicate the database again.

SQL> connect / as sysdba
startup nomount;

Also you have to verify the following:

1. Ensure that the ORACLE_SID and ORACLE_HOME were set correctly when starting the auxiliary instance.  Especially any additional backslash at the end of the ORACLE_HOME can cause mismatches

2. Verify that the ORACLE_HOME directory is not a linked directory.
Make a hard copy of the init.ora in the ORACLE_HOME/dbs directory.

3. Double check the ‘listener.ora’ and ‘tnsnames.ora’ for correctness.”

 

The database was in nomount state started with a basic pfile:

*.db_name=V1DEV
*.db_unique_name=V1DEV

 

But upon checking point 3, I noticed the static listener registration that is required as the database is in nomount and thus doesn’t register with the listener had the wrong home:

SID_LIST_LISTENER =
 (SID_LIST =
 (SID_DESC =
 (SID_NAME = V1DEV1)
 (GLOBAL_DBNAME = V1DEV)
 (ORACLE_HOME = /u01/app/oracle/product/12.1.0.2/dbhome_1)
 )
 )

 

I recently changed the Oracle Home to use the dbhome_2 Oracle Home, so that the Development databases were not locked in with the DR databases using the dbhome_1 Oracle Home.  This allows for independent patching between the Oracle Homes, which allows soak testing of patches in Development before applying to Production:

Cloning an Oracle Home

 

Once this was changed:

SID_LIST_LISTENER =
 (SID_LIST =
 (SID_DESC =
 (SID_NAME = V1DEV1)
 (GLOBAL_DBNAME = V1DEV)
 (ORACLE_HOME = /u01/app/oracle/product/12.1.0.2/dbhome_2)
 )
 )

 

It started working again 🙂 :

Starting Duplicate Db at 26-JUL-2017 11:38
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=515 device type=DISK
allocated channel: ORA_AUX_DISK_2
channel ORA_AUX_DISK_2: SID=1475 device type=DISK
allocated channel: ORA_AUX_DISK_3
channel ORA_AUX_DISK_3: SID=643 device type=DISK
allocated channel: ORA_AUX_DISK_4
channel ORA_AUX_DISK_4: SID=835 device type=DISK
current log archived

 

If you found this blog post useful, please like as well as follow me through my various Social Media avenues available on the sidebar and/or subscribe to this oracle blog via WordPress/e-mail.

Thanks

Zed DBA (Zahid Anwar)

How to exit out of ed in SQL*Plus

I, from time to time, get stuck in ‘ed‘ on SQL*Plus because the editor not defined like this:

SQL> select * from duall;
select * from duall
 *
ERROR at line 1:
ORA-00942: table or view does not exist

SQL> ed
Wrote file afiedt.buf
22
^C
?
^Z
?

The Ctrl-C and Ctrl-Z, wouldn’t get you out.

The solution is simple, type ‘q‘ and press ‘Enter‘, then set editor using ‘define_editor=vi‘ and try again 🙂 :

q

1* select * from duall
SQL> define_editor=vi
SQL> ed
Wrote file afiedt.buf

1* select * from dual
SQL> /

D
-
X

SQL>

 

If you found this blog post useful, please like as well as follow me through my various Social Media avenues available on the sidebar and/or subscribe to this oracle blog via WordPress/e-mail.

Thanks

Zed DBA (Zahid Anwar)