Skip to main content

ORACLE AUDIT VAULT - UPDATE FROM 20.14 to 20.17.

 We can update the Oracle Audit Vault using the same configuration and we require to follow the below commands.

firstly you need to download the Oracle Audit Vault patches.

--

first need to update the new network environment using below commands.

 

vi /usr/local/dbfw/etc/dbfw.conf

 

 - change GATEWAY to 192.168.128.255 and host ip to 192.168.128.50

 - remove syslog ip from both records. 


SYSLOGDEST="192.168.10.1"

SYSLOGDEST="192.168.10.1:4444"


 /usr/local/dbfw/bin/priv/configure-networking


you can check the current status of the below command.

[oracle@auditvault-testvm ~]$ rpm -qa | grep -i avs 

[root@auditvault-testvm bin]# rpm -qa | grep -i avs

avs-database-2-19.27.0.0.0-0.x86_64
avs-database-19.27.0.0.0-0.x86_64
avs-bootstrap-20.17.0.0.0-0_260303.0015.noarch
bootstrap-avs-dependencies-20.17.0.0.0-0_260303.0015.noarch
avs-dbsat-20.14.0.0.0-0_250520.0400.x86_64
bootstrap-avs-application-20.14.0.0.0-0_250520.0400.noarch
avs-apex-20.14.0.0.0-0_250520.0400.x86_64
avs-20.14.0.0.0-0_250520.0400.x86_64


Check status screen from using below command.

/opt/avdf/install/bin/bootstrap-post-reboot.rb --upgrade --screen_session


copy the zip files to /var/dbfw/upgrade/patch location

unzip using below command 

unzip p399193301

rpm -i avdf-pre-upgrade-20-10910

if this previous query didnt run properly you require to remove the rpm and reinstall. here is how to proceed.

to find the installed version:
rpm -q avdf-pre-upgrade

to remove the installed version:
rpm -e avdf-pre-upgrade-20-10910

once this is installed: it will give you errors if space is concerned. you need to add storage to /root location if required.

clear below locations as well

/tmp/
/var/log/audit/

once the pre-upgrade is passed you require to copy the .iso to /var/dbfw/upgrade location ( around 18GB )

/usr/bin/avdf-upgrade

once the below step is you require to reboot. 

which will complete the rest of the upgrade.

Online references:

AVDF Update notes
https://docs.oracle.com/en/database/oracle/audit-vault-database-firewall/20/sigig/patch.html#GUID-1C679858-AFA3-49DB-84D4-946C84BE756B

BACKUP
https://docs.oracle.com/en/database/oracle/audit-vault-database-firewall/20/sigad/manage_server.html#GUID-9DED73B1-0FFF-4325-B756-0CC345B2CB8D


REFERENCE
https://docs.oracle.com/en/database/oracle/audit-vault-database-firewall/20/

Comments

Post a Comment

Popular posts from this blog

Convert TIMESTAMP to SCN and SCN to TIMESTAMP in Oracle

  Convert TIMESTAMP to SCN and SCN to TIMESTAMP in Oracle In many recovery scenario we need to know our SCN and timestamps. We can convert this by using the following function SCN_TO_TIMESTAMP TIMESTAMP_TO_SCN We can use this function with help of dual functions. Example of using this function as follows: 1. Convert the SCN to Timestamp SQL> select scn_to_timestamp(2011955) from dual; SCN_TO_TIMESTAMP(2011955) ----------------------------------------------------- 05-SEP-18 12.46.20.000000000 PM 2. Convert the Timestamp to SCN SQL> select timestamp_to_scn(to_timestamp('05-09-2018 12:46:21','dd-mm-yyyy hh24:mi:ss')) scn from dual; SCN ---------- 2011955
Post a Comment
Read more

Warning: long redo log write elapsed times detected, the LG* process tracefiles have more details

Warning: long redo log write elapsed times detected, the LG* process tracefiles have more details This warning means LGWR / LGnn background processes are taking too long to write redo to the online redo logs. It is usually related to one of these: - Slow storage / high I/O latency on redo log disks - Redo logs placed on busy disks together with datafiles, FRA, archive logs, backups, or OS files - Too many commits from the application, causing frequent LGWR flushes - Redo log size too small, causing frequent log switches - CPU scheduling issue, where LGWR is not getting CPU quickly - Data Guard synchronous transport delay, if using SYNC/AFFIRM - In newer 19c RU versions, especially around 19.28, this warning can appear more visibly because of diagnostic changes, so first confirm whether there is a real performance impact before changing anything. - Oracle’s own wait-event documentation says log file sync is the foreground wait for redo write confirmation after commit, and log file paral...
Post a Comment
Read more

How To Enable Flash Recovery Area In Oracle Database

  The flash recovery area(FRA) is an Oracle-managed destination( either FILE SYSTEM or ASM ) for centralized backup and recovery files. It simplifies the backup management. The following recovery-related files are stored in the flash recovery area: — Current control file — Online redo logs — Archived redo logs — Flashback logs — Control file auto backups — Datafile and control file copies — Backup pieces — Foreign archived redo log Below are the steps for enabling  flash  recovery area. DB_RECOVERY_FILE_DEST_SIZE   and  DB_RECOVERY_FILE_DEST   initial parameters are required for enabling FRA. DB_RECOVERY_FILE_DEST_SIZE   -> It is the disk quota size for the flash recovery area. DB_RECOVERY_FILE_DEST   – > This initialization parameter is a valid destination for the Flash Recovery Area. It can be a directory, file system, or ASM disk group. NOTE  : DB_RECOVERY_FILE_DEST_SIZE must be set before DB_RECOVERY_FILE_DEST. 1. Check whether FRA ...
Post a Comment
Read more