Friday, February 10, 2023

Java (1.6) could not be located. OPatch cannot proceed!

 

Java (1.6) could not be located. OPatch cannot proceed!



We get below java error, when we try to query opatch utility like lsinventory, version, apply, rollback ...etc

follow below steps/workaround for the issue

Java (1.6) could not be located

Details of error are as follows.

[SERVER1]/u01/app$ OPatch/opatch version
Java (1.6) could not be located. OPatch cannot proceed! OPatch returns with error code = 1 [SERVER1]/u01/app$ [SERVER1]/u01/app/OPatch $

 

OPatch cannot proceed!

This errors are related with the Opatch version or opatch utility was downloaded for a wrong platform or using older version of opatch.

Install the latest opatch

OR

Use the JDK option like following.

Use the JDK option like following.

which java
copy the java path and go to jdk location inside java home 

opatch apply -jdk <<FULL_PATH_OF_JDK>
example output as below.

Use the JDK option like following.


[SERVER1]/u01/app$ 
[SERVER1]/u01/app$ OPatch/opatch version
Java (1.6) could not be located. OPatch cannot proceed! OPatch returns with error code = 1 [SERVER1]/u01/app$
[SERVER1]/u01/app/OPatch $
[SERVER1]/u01/app/OPatch $ ./opatch lsinventory
-jdk /export2/jdk/ -oh /u01/app/
Oracle Interim Patch Installer version 13.9.4.2.4 Copyright (c) 2021, Oracle Corporation. All rights reserved. Oracle Home : /u01/app Central Inventory : /u01/app/18c/oraInventory from : /u01/app//oraInst.loc OPatch version : 12.2.0.1.33 OUI version : 12.2.0.1.4 Log file location : /u01/app/cfgtoollogs/opatch/opatch2021-06-21_14-11-18PM_1.log Lsinventory Output file location : /u01/app/cfgtoollogs/opatch/lsinv/lsinventory2021-06-21_14-11-18PM.txt -------------------------------------------------------------------------------- ARU platform id: 226 ARU platform description:: Linux x86-64 Installed Top-level Products (1): Oracle Database 12c 12.2.0.1.0 There are 1 products installed in this Oracle Home. There are no Interim patches installed in this Oracle Home. -------------------------------------------------------------------------------- OPatch succeeded. [SERVER1]/u01/app/OPatch $









Thursday, December 22, 2022

Create file system in LINUX system which is Larger than 2TB

Create file system in LINUX system which is Larger than 2TB



###########################################################################
###########################################################################
Run the following command to install the e2fsprogs and parted :

yum install -y parted
yum install -y e2fsprogs


Perform the following operations to partition and format a data disk larger than 2 TiB in size and mount the file system.


Check whether a data disk exists.

Run the following command:
fdisk -l

A command output similar to the following one is returned. The command output includes information about the data disk. If no data disk information is returned, the instance does not have data disks attached.

Disk /dev/vdb: 3221.2 GB, 3221225472000 bytes, 6291456000 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Use the Parted tool to partition the data disk.

Run the following command to start partitioning:
parted /dev/sdb

Run the following command to convert the partition format from MBR to GPT:
mklabel gpt

Run the following command to create a primary partition and specify the start and end sectors for the partition:
mkpart primary 1 100%

where the 100% is total size of the disk allocated, you can choose as required.

Run the following command to check whether the partition is aligned:
align-check optimal 1

A command output similar to the following one is returned:
1 aligned


Note: -  
If 1 not aligned is returned, the partition is not aligned. 
We recommend that you run the following commands 
and use the (<optimal_io_size> + <alignment_offset>)/<physical_block_size> formula to obtain the start sector number to align the partition for optimal performance. 

For example, if the start sector number is 1024, you can then run the mkpart primary 1024s 100% command to create another primary partition.

cat /sys/block/vdb/queue/optimal_io_size
cat /sys/block/vdb/queue/minimum_io_size
cat /sys/block/vdb/alignment_offset
cat /sys/block/vdb/queue/physical_block_size


Run the following command to view the partition table:
print


Run the following command to exit the Parted tool:
quit




The following figure shows the result of partitioning by using the Parted tool.Partitioning by using Parted


Run the following command to enable the system to re-read the partition table:
partprobe


Run one of the following commands to create a file system for the /dev/vdb1 partition.
Run one of the following commands to create a file system based on your needs:

Create an ext4 file system.
mkfs -t ext4 /dev/vdb1




Run the following command to create a mount point named /test:
mkdir /test

Run the following command to mount the /dev/vdb1 partition to /test:
mount /dev/vdb1 /test

Run the following command to view the current disk space and usage:
df -h





If the command output shows the information of the new file system, the mount operation is successful. You can use the new file system.df output

(Recommended) Write the information of the new partition to /etc/fstab to enable this partition to be automatically mounted on system startup.


Run the cp /etc/fstab /etc/fstab.bak command to back up etc/fstab:

Run the following command to write information of the new partition to /etc/fstab:
echo `blkid /dev/vdb1 | awk '{print $2}' | sed 's/\"//g'` /test ext4 defaults 0 0 >> /etc/fstab



Note
You must run the command as the root user. If you are a common user, 
you can run the su - command to switch to the root user, and then run this command. 

Alternatively, you can run the sudo vi /etc/fstab command to edit /etc/fstab.
We recommend that you use a universally unique identifier (UUID) to reference the new partition in /etc/fstab. 
You can run the blkid command to obtain the UUID of the new partition.



Run the following command to check the information of /etc/fstab:
cat /etc/fstab



###########################################################################

###########################################################################


Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: No URLs in mirrorlist

 Error: Failed to download metadata for repo 'appstream': Cannot prepare internal mirrorlist: No URLs in mirrorlist




Solution

~~~~~~~~~~~~~~~~~~~~


FROM centos
execute below

cd /etc/yum.repos.d/

sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-*

sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-*


now try to update or install

yum -y install java






Friday, July 22, 2022

Oracle GoldenGate extract recovery (Missing archivelogs)

Oracle GoldenGate extract recovery (Missing archivelogs)


Issue description: 

    The issue occurs when archive logs that are needed by Oracle GoldenGate extract gets deleted. For example this can happen when purging old archive logs using RMAN with “force” option. 

RMAN is integrated with OGG so under normal circumstances RMAN never deletes an archive log that is required by OGG extract. 

But with “force” option it does delete archive logs required by OGG extract. Although it is certainly not the best practice to use “force” option while purging old archive logs, 

however accident do happen. This post illustrates the steps needed to recover from such situation.


Example:

The error in the Oracle GoldenGate extract report file looks similar to the following example


ERROR   OGG-00868  Error code 1291, error message: ORA-01291: missing logfile

(Missing Log File WAITING FOR DICTIONARY REDO. Read Position SCN: 0.46921993 (46921993)).











1) Find out the archive logs (and the range) that the extract is complaining about. Let’s say the extract is complaining about SCN number 46921993.

Find out which archive log that SCN number belongs to.

SQL> Select sequence# from v$archived_log where 46921993 is between first_change# and next_change#;     Sequence#     ==========     100

SQL> Select sequence# from v$archived_log where sequence# >100 and name is NULL;

(Say the query came back with 10 archive logs (101 through 110)).

Sequence#     ==========      100      101      102      103      104      105      106      107      108      109      110





2) Restore the archive log using RMAN.
RMAN> Restore archive logs from logseq 100 until logseq 110;





















3) Register the archive logs for the capture process.
SQL> Alter database register logical logfile “/<path to logfile>/logfilename> for "OGG Capture Name";

4) Restart the OGG extract.
GGSCI> Start extract <OGG extract name>


Note: This solution is generic and applies to both Oracle cloud and on-premise customers

















Thursday, May 5, 2022

Oracle 19c Restore Point Replication From Primary To Standby

Oracle 19c Restore Point Replication From Primary To Standby

Primary Side:-
~~~~~~~~~~~~

SQL> SELECT database_role, open_mode FROM v$database;

DATABASE_ROLE        OPEN_MODE
—————-               ——————–
PRIMARY                      READ WRITE



SQL> create restore point FB_Restore_poiint  guarantee flashback database;
Restore point created.



SQL> select SCN, GUARANTEE_FLASHBACK_DATABASE, TIME, NAME, REPLICATED from v$restore_point;

SCN     GUARANTEE_FLASHBACK_DATABASE  TIME NAME  REPLICATED
———- —————————— —————————————- ————————-
2443446     YES  20-OCT-19 04.15.22.000000000 PM FB_Restore_poiint NO




PRIMARY - Alertlog
~~~~~~~~~~

2022-11-20T16:15:22.184171+05:30
Created guaranteed restore point FB_Restore_poiint





Standby Side:-
~~~~~~~~~~~~~

SQL> SELECT database_role, open_mode FROM v$database;

DATABASE_ROLE                 OPEN_MODE
—————-                        ——————–
PHYSICAL STANDBY      READ ONLY WITH APPLY



SQL> select SCN, GUARANTEE_FLASHBACK_DATABASE, TIME, NAME, REPLICATED from v$restore_point;

SCN     GUARANTEE_FLASHBACK_DATABASE  TIME NAME  REPLICATED
———- —————————— —————————————- ————————-
2443446 NO  20-OCT-19 04.15.22.000000000 PM FB_Restore_poiint_PRIMARY YES



SQL> select status,instance_name,database_role,protection_mode ,flashback_on from v$database,v$instance;

STATUS INSTANCE_NAME DATABASE_ROLE PROTECTION_MODE  FLASHBACK_ON
———— —————- —————- —————————————————————————-
OPEN               delhi       PHYSICAL STANDBY                         MAXIMUM AVAILABILITY  YES
 
    
        The naming convention for a replicated restore point uses the name of the restore point on the primary database suffixed with _PRIMARY. 
        If a replicated restore point with the same name exists on the standby database, then a replicated restore point is not created. 

    For example, when you create a restore point named PRE_MYTBS on the primary database, the replicated restore point is named FB_Restore_poiint_PRIMARY
    When you delete a restore point on the primary, the corresponding replicated restore point on the standby is also deleted.