Advertisement

Wednesday, July 18, 2018

Oracle Database - ORA-07217: sltln: environment variable cannot be evaluated. (After Windows to Linux Restore for Archive Logs)

We restored one of our databases from Windows to Linux, everything went fine since cross-platform is supported on our database version. 

However, when doing anything with archivelogs (crosscheck archivelog all) we faced issue 

ORA-07217: sltln: environment variable cannot be evaluated

Did quite a lot of research but there was no specific Document in Oracle which had the symptoms and solution. 

Then traced the rman for crosscheck command. 

export NLS_LANG=american

export NLS_DATE_FORMAT='Mon DD YYYY HH24:MI:SS'
rman target / trace="/tmp/tracefile.out" debug

Recovery Manager: Release 11.2.0.4.0 - Production on Wed Jul 18 08:48:41 2018

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

crosscheck archivelog all;
RMAN-06005: connected to target database: <DBNAME> (DBID=336051125)

RMAN>
RMAN-06009: using target database control file instead of recovery catalog
RMAN-08030: allocated channel: ORA_DISK_1
RMAN-08500: channel ORA_DISK_1: SID=47 device type=DISK
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of crosscheck command on ORA_DISK_1 channel at 07/18/2018 08:48:48

ORA-07217: sltln: environment variable cannot be evaluated.

Browsing through the trace file found issues (highlighted bold)

Excerpt from the trace file - 
DBGPLSQL:      channel ORA_DISK_1: started, command:556 [08:48:48.713] (change)
DBGPLSQL:      channel ORA_DISK_1: File \\PATH1\PATH2$\PATH3\\ARCH_D-MYDB_ID-336051125_S-4625
8_T-1_A-895598920_BBT74KKT belongs to 0 [08:48:48.713] (change)
DBGPLSQL:      channel ORA_DISK_1:  processing (file/handle=\\PATH1\PATH2$\PATH3\\ARCH_D-MYDB
_ID-336051125_S-46258_T-1_A-895598920_BBT74KKT,recid=93051, old_status=A, hdl_isdisk=1, devicetype=DISK, source_dbid=0)
 [08:48:48.713] (change)
DBGPLSQL:      channel ORA_DISK_1:  force: 0 [08:48:48.714] (change)
DBGPLSQL:      channel ORA_DISK_1: Calling ValidateArchivedLog for \\PATH1\PATH2$\PATH3\\ARCH_D
-MYDB_ID-336051125_S-46258_T-1_A-895598920_BBT74KKT [08:48:48.714] (change)
DBGRPC:        krmxrpc - channel ORA_DISK_1 kpurpc2 err=7217 db=target proc=SYS.DBMS_BACKUP_RESTORE.VALIDATEARCHIVEDLOG
 excl: 111
DBGRPC:        krmxrpc - caloing krmxtrim: with message of length 111: @@@ORA-07217: sltln: environment variable cannot be evaluated.
DBGRPC:        ORA-06512: at "SYS.DBMS_BACKUP_RESTORE", line 4075
DBGRPC:        @@@
DBGRPC:        krmxrpc - channel ORA_DISK_1, error 7217 received for rpc 6 before receiving 3123
DBGRPC:        krmxr - channel ORA_DISK_1 returned from peicnt
DBGMISC:       ENTERED krmstrim [08:48:48.714]
DBGMISC:        Trimming message: ORA-07217: sltln: environment variable cannot be evaluated. [08:48:48.714] (krmstrim)
DBGMISC:        ORA-06512: at "SYS.DBMS_BACKUP_RESTORE", line 4075 (krmstrim

We found out a $ was present in the path (this is because of entries of archive log in the control file which were windows path).
It was impossible to expired / delete the archives. 
So we cleared the archivelog entry section from the controlfile and recataloged the archivelogs 
Which then was the solution for us. 

From sqlplus plus prompt ran - 

 exec SYS.DBMS_BACKUP_RESTORE.resetCfileSection(11);
This clears the 

Then cataloged the archivelogs again which were present. 

Removing entries in v$archived_log referencing a particluar DEST_ID (Doc ID 845361.1)

Also you can find details on deleting other controlfile section in one of the blogs from Vijay

Copied from the above blog - 

DBMS_BACKUP_RESTORE.resetCfileSection() package:


-- Note that you can execute the following PL/SQL to remove all entries from V$RMAN_STATUS:
-- The preceding function removes all job-related entries. No rows will be visible until new backup jobs are shown in V$RMAN_BACKUP_JOB_DETAILS.

sqlplus / as sysdba
exec SYS.DBMS_BACKUP_RESTORE.resetCfileSection(28);
commit;


-- Removing entries in v$DATABASE_BLOCK_CORRUPTION view
-- Be aware that the corrupted blocks will remain corrupted until we fix the block corruption issue.
-- Error: Bug 13386807 : RMAN BACKUP FAILED ORA-03114 ORA-07445: [KRBINSERTBCR()+665]

exec SYS.DBMS_BACKUP_RESTORE.resetCfileSection(35);


-- Issue: V$DATABASE_BLOCK_CORRUPTION has rows referring to a non-existing datafile.

-- Removing entries in v$backup_corruption view
exec SYS.DBMS_BACKUP_RESTORE.resetCfileSection(17);
-- Removing entries in v$copy_corruption view
exec SYS.DBMS_BACKUP_RESTORE.resetCfileSection(18);


-- Removing entries in v$deleted_object view on RMAN catalog
-- Issue: RMAN backup is suddenly running very slowly after having deleted a large number of backupsets from catalog.

exec SYS.DBMS_BACKUP_RESTORE.resetCfileSection(19);


-- Removing entries in v$archived_log view
-- Issue: Removing entries in v$archived_log referencing a particluar DEST_ID

exec SYS.DBMS_BACKUP_RESTORE.resetCfileSection(11);


-- Removing entries in v$backup_spfile on RMAN catalog
-- RMAN Error: ORA-01400: cannot insert NULL into ("RMAN"."BSF"."MODIFICATION_TIME")


exec SYS.DBMS_BACKUP_RESTORE.resetCfileSection(21); 
-------------------------------------------------
Just to let you know my archivelogs entries looked like this on Linux

93837   1    46651   A 12-JUL-18
        Name: \\PATH1\PATH2$\PATH3\<DBNAME>\ARCH_D-MYDB_ID-336051125_S-46651_T-1_A-895598920_OCT7PIAB

93839   1    46652   A 12-JUL-18
        Name: \\PATH1\PATH2$\PATH3\<DBNAME>\ARCH_D-MYDB_ID-336051125_S-46652_T-1_A-895598920_ODT7PK2J

93841   1    46653   A 12-JUL-18
        Name: \\PATH1\PATH2$\PATH3\<DBNAME>\ARCH_D-MYDB_ID-336051125_S-46653_T-1_A-895598920_OET7PLQS

93843   1    46654   A 12-JUL-18

        Name: \\PATH1\PATH2$\PATH3\<DBNAME>\ARCH_D-MYDB_ID-336051125_S-46654_T-1_A-895598920_OFT7PNJ3

No comments:
Write comments