1. Installation Guide
  2. Patching Oracle Audit Vault and Database Firewall Release 20

6 Patching Oracle Audit Vault and Database Firewall Release 20

If you're on Oracle Audit Vault and Database Firewall (Oracle AVDF) release 20, you can apply the most recent release update (RU) patch to access the latest features and bug fixes.

If you're on Oracle AVDF release 12.2, see Upgrading Oracle Audit Vault and Database Firewall from Release 12.2 to Release 20 to perform a full upgrade to release 20.

Note:

  • The patching process uses the same pre-upgrade RPM as the upgrade process, although patching involves a smaller subset of tasks compared to a full upgrade.

  • This chapter uses the terms update and patch interchangeable.

6.1 About Patching Oracle Audit Vault and Database Firewall

Follow these guidelines for patching Oracle Audit Vault and Database Firewall (Oracle AVDF) release 20 to the latest release update (RU).

Use the following high-level process to patch Oracle AVDF:

  1. Download the files from My Oracle Support.
  2. Complete the pre-update tasks, such as creating a backup.
  3. Update the Audit Vault Servers.
  4. Verify that Audit Vault Agents and Host Monitor Agents were updated automatically.
  5. Update the Database Firewalls.
  6. Complete the post-update tasks, such as confirming that the update was successful.

Note:

If you have a large amount of event data, maintain sufficient disk space of about 5% of the total event log data size. If you have both HDD and SAN storage, then maintain the necessary disk space on either HDD or SAN. Each disk group (EVENTDATA, SYSTEMDATA, and RECOVERY) should have at least 20% available space.

Note:

To updateOracle AVDF to a new release with minimal downtime for monitoring and collecting data, see Updating Oracle AVDF with Minimal Downtime by Using Backup and Restore.

6.2 Download the Files

To patch or upgrade Oracle Audit Vault and Database firewall (Oracle AVDF), you need to download files from My Oracle Support.

  1. Go to My Oracle Support and sign in.
  2. Click the Patches & Updates tab.
  3. Use the Patch Search box to search for the patch.
    1. Click the Product or Family (Advanced) link on the left.
    2. In the Product field, enter Audit Vault and Database Firewall.
    3. In the Release field, select the latest Oracle AVDF release from the drop-down list.
    4. Click Search.
  4. In the Patch Name column of the search results, click the link for the latest bundle patch.

6.3 Pre-update Tasks

Before updating Oracle Audit Vault and Database Firewall (Oracle AVDF) to the latest release, complete the prerequisite tasks, such as performing a backup.

Note:

If Audit Vault Agent is running on a Windows machine, close all the agent-related directories and open files before updating Oracle AVDF.

6.3.1 Back Up the Current Oracle Audit Vault and Database Firewall Installation

Before updating Oracle Audit Vault and Database Firewall (Oracle AVDF) to the latest release, back up the Audit Vault Server.

See Backing Up and Restoring the Audit Vault Server for complete information.

If your current Audit Vault Server is installed on a virtual machine (VM), such as Oracle VM or VMWare, Oracle recommends that you take a VM snapshot before starting the update process.

6.3.2 Release Existing Tablespaces That Are Retrieved Manually

If you're updating to Oracle Audit Vault and Database Firewall (Oracle AVDF) release 20.1 through 20.3, release all the existing tablespaces that were retrieved manually. This procedure is performed automatically if you're updating to Oracle AVDF release 20.4 or later.

If you don't release the existing tablespaces, the following situations could occur:

  • The update might fail, resulting in an error.
  • New indexes might not be created after the update because space can't be allocated.

To manually release the tablespaces, follow these steps:

  1. Log in to the Audit Vault Server console as a super administrator.

  2. Click the Settings tab.

  3. Click Archiving in the left navigation menu.

  4. Click the Retrieve subtab.

    The page lists all the retrieved tablespaces.

  5. Select and release all the tablespaces.

6.3.3 Verify That the SYS User Is Unlocked and the Password Is Not Expired

If the sys password has expired or the sys user is locked, you'll receive an error when you run the pre-upgrade RPM during the process of updating Oracle Audit Vault and Database Firewall (Oracle AVDF).

To prevent this issue, update the sys user on the primary and standby systems.

  1. Perform the following steps on both the primary and standby systems:

    1. Log in to the Audit Vault Server through SSH and switch to the root user.

      See Logging In to Oracle AVDF Appliances Through SSH.

    2. As the root user, run the following command:
      systemctl stop monitor
    3. Check for any observerctl processes running and stop them.
      ps -elf | grep observerctl
kill -9 <PID of observerctl>
    4. Check for any dgmgrl processes running and stop them.
      ps -elf | grep dgmgrl
kill -9 <PID of dgmgrl>
  2. Update the primary system.

    1. Log in to the primary Audit Vault Server through SSH and switch to the root user.

      See Logging In to Oracle AVDF Appliances Through SSH.

    2. Switch to the oracle user.

      su - oracle

    3. Start SQL*Plus by entering the following command:

      sqlplus / as sysdba

    4. Enter the following command:

      select avsys.secutil.gen_rand_pwd(30) as pwd from dual

      Note:

      Use this password in all steps that require a password on both primary and standby systems.

    5. Enter the following commands:

      alter user sys identified by <password_from_step_1d_above> account unlock;
      ALTER SYSTEM SWITCH LOGFILE;
    6. Exit back to the oracle user.

    7. As the oracle user, enter the following commands: 

       mkstore -wrl /var/lib/oracle/dbfw/network/admin/observer/ -modifyCredential DBFWDB_HA2_DGMGRL SYS <password_from_step_1d>
      mkstore -wrl /var/lib/oracle/dbfw/network/admin/observer/ -modifyCredential DBFWDB_HA1_DGMGRL SYS <password_from_step_1d>
      mkstore -wrl /var/lib/oracle/dbfw/network/admin/observer/ -modifyCredential DBFWDB_HA1 SYS <password_from_step_1d>
      mkstore -wrl /var/lib/oracle/dbfw/network/admin/observer/ -modifyCredential DBFWDB_HA2 SYS <password_from_step_1d>

    8. Securely copy the file to the standby system by entering the following command:

      scp /var/lib/oracle/dbfw/dbs/orapwdbfwdb support@<standby IP>:~/

  3. Update the standby system.

    1. Log in to the standby Audit Vault Server through SSH and switch to the root user.

      See Logging In to Oracle AVDF Appliances Through SSH.

    2. Ensure that the new file permissions are the same as the original file.

    3. Switch to the oracle user.

      su - oracle

    4. Enter the following commands:

      mkstore -wrl /var/lib/oracle/dbfw/network/admin/observer/ -modifyCredential DBFWDB_HA2_DGMGRL SYS <password_from_step_1d>
      mkstore -wrl /var/lib/oracle/dbfw/network/admin/observer/ -modifyCredential DBFWDB_HA1_DGMGRL SYS <password_from_step_1d>
      mkstore -wrl /var/lib/oracle/dbfw/network/admin/observer/ -modifyCredential DBFWDB_HA1 SYS <password_from_step_1d>
      mkstore -wrl /var/lib/oracle/dbfw/network/admin/observer/ -modifyCredential DBFWDB_HA2 SYS <password_from_step_1d>

  4. Enter the following commands as the root user on both primary and standby systems: 

    systemctl stop monitor
    systemctl stop dbfwlistener
    systemctl stop dbfwdb
    systemctl start dbfwdb
    systemctl start dbfwlistener
    systemctl start monitor

  5. Enter the following command as the oracle user on both primary and standby systems: 

    /usr/local/dbfw/bin/observerctl --start

Related Topics

6.3.4 Disable FIPS Mode Before Patching to AVDF 20.10

When patching from Oracle AVDF 20.x to 20.10 you first need to disable FIPS mode if it is currently enabled. Once the patch is applied successfully, enable FIPS mode again if required.

To patch AVDF to version 20.10 you must disable the FIPS mode before the patch. The FIPS mode can be enabled once the patch is completed. If the patch is attempted in FIPS mode then the operation will fail with the following message: 
Precondition: 'fips-mode-check.rb' Result: 'The installed system cannot be upgraded when the FIPS mode is enabled. Please disable the FIPS mode.'

Disable FIPS Mode on the Audit Vault Server

  1. Log in to Audit Vault Server console as a super administrator.
  2. Click the Settings tab.

    The Security tab in the left navigation menu is selected by default.

  3. Click the FIPS subtab on the main page.
  4. Click the toggle switch to disable FIPS 140-2.
  5. Click Save.

    A message says that the Audit Vault Server will reboot and prompts you to continue or cancel.

  6. Click OK to disable FIPS 140-2 for Audit Vault Server. Otherwise, click Cancel.

It can take several minutes for the console to become available after disabling FIPS mode.

In a high availability configuration, enabling FIPS 140-2 mode for the primary Audit Vault Server also enables FIPS 140-2 mode for the standby Audit Vault Server. Similarly, disabling FIPS mode for the primary Audit Vault Server also disables it for the standby Audit Vault Server.

Disable FIPS Mode in Database Firewall

  1. Log in to Audit Vault Server console as super administrator.
  2. Click Database Firewalls tab. The Database Firewalls tab in the left navigation menu is selected by default.
  3. Click the name of the specific Database Firewall instance for which you want to enable FIPS 140-2.
  4. Click FIPS under the Configuration section. A dialog is displayed.
  5. In the dialog, turn off the toggle switch to disable FIPS 140-2.
  6. Click Save. A message pops that Database Firewall will reboot and prompts you to continue or cancel.
  7. Click OK to continue to disable FIPS 140-2 for the Database Firewall instance. Else, click Cancel.

    The Database Firewall instance is restarted and is unavailable for some time.

  8. Wait for a while, and navigate back to the Database Firewalls tab in the left navigation menu.
  9. Check the status of FIPS 140-2 mode under the column FIPS Mode against the specific Database Firewall instance.
  1. Log in to Audit Vault Server console as super administrator.
  2. Click Database Firewalls tab. The Database Firewalls tab in the left navigation menu is selected by default.
  3. Click High Availability tab in the left navigation menu. All the Database Firewall instances that are configured in high availability are listed in the main page.
  4. The names of paired Database Firewall instances are listed under the Primary and Secondary columns on the main page. Select the specific pair of Database Firewall instances for which you want to disable FIPS.
  5. Click FIPS in the top right corner of the page. A dialog is displayed.
  6. In the dialog, turn off the toggle switch to disable FIPS 140-2.
  7. Click Save. A message pops that Database Firewall will reboot and prompts you to continue or cancel.
  8. Click OK to continue to disable FIPS 140-2 for the Database Firewall instance. Else, click Cancel.

    The Database Firewall instance is restarted and is unavailable for some time.

  9. Wait for a while, and navigate back to the Database Firewalls tab in the left navigation menu.
  10. Check the status of FIPS 140-2 mode under the column FIPS Mode against the specific Database Firewall instance.

Related Topics

6.4 Update the Audit Vault Server

Update the Audit Vault Server before you update the Audit Vault Agents and Database Firewalls.

Note:

In this section, the word appliance refers to the Audit Vault Server.

6.4.1 Update a Standalone Audit Vault Server

Follow this process to update a standalone Audit Vault Server that is not paired in a high availability environment.

  1. Stop all audit trails.
  2. Run the pre-upgrade RPM.
  3. Transfer the ISO file to the appliance.
  4. Start the update script.
  5. Restart the appliance.

Note:

When the appliance restarts, the update process continues. This takes several hours to complete on Audit Vault Servers. Don't restart the system while this is in progress.

Update Notes

  • If you have existing targets for which you ran Oracle Audit Vault and Database Firewall (Oracle AVDF) setup scripts to set user privileges (for example, for stored procedure auditing), no further action is required to update those privileges after you update Audit Vault Servers.

    Check the Oracle AVDF release notes to find out if you need to rerun the setup scripts because they've changed.

  • When updating from Oracle AVDF 12.2 to release 20.1-20.8, password hashing has been upgraded to a more secure standard. This change affects the operating system passwords (support and root). Change your passwords after you update Audit Vault Servers to take advantage of the more secure hash.

6.4.1.1 Stop All Audit Trails

Stop all audit trails before updating the Audit Vault Server.

  1. Log into the Audit Vault Server console as an administrator.
  2. Click the Targets tab.
  3. Click Audit Trails in the left navigation menu.
  4. Select all audit trails.
  5. Click Stop.
6.4.1.2 Run the Pre-upgrade RPM

Run the pre-upgrade RPM to check for the required space in the file system and prepare the system for updating.

Note:

The patching process uses the same pre-upgrade RPM as the upgrade process, although patching involves a smaller subset of tasks compared to a full upgrade.

The pre-upgrade RPM performs the following tasks to prepare the system for updating:

  • Rearranges free space on the appliance so that there's enough room to copy the patch files to the appliance and start the installation. After the update, the space for the patch files is returned to the file system.
  • Starting with updates from Oracle AVDF 20.9 to Oracle AVDF 20.10 and later, verifies that the Audit Vault Agents and Host Monitor Agents are compatible with the new version of the Audit Vault Server. For example, it verifies that agent host machines have compatible operating system and Java versions.
  • Verifies that other prerequisites and platform conditions are met before the update.
  • Prepares the system for updating by creating the /var/dbfw/upgrade directory with enough space to hold the main ISO file for the update.

To run the pre-upgrade RPM, follow these steps:

  1. Log in to the appliance through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Run the screen command as the root user.

    The screen command prevents network disconnections from interrupting the update. If the session terminates, resume by switching to the root user and then running the screen -r command.

  3. Change to the root directory. 

    cd /root

  4. Run the following command to copy the pre-upgrade RPM file from the downloaded location to the appliance:

    scp remote_host:/path/to/avdf-pre-upgrade-20.x.0.0.0.zip /root

  5. Verify the download by using a shasum of the avdf-pre-upgrade-20.x.0.0.0.zip file. 

    sha256sum /root/avdf-pre-upgrade-20.x.0.0.0.zip

  6. Unzip the bundle.

    unzip /root/avdf-pre-upgrade-20.x.0.0.0.zip

  7. Run the following command to run the avdf-pre-upgrade-20.x.0.0.0-0_NNNNNN.NNNN.x86_64.rpm file: 

    rpm -i /root/avdf-pre-upgrade-20.x.0.0.0-0_NNNNNN.NNNN.x86_64.rpm

    The following message appears:

    SUCCESS: The upgrade media can now be copied to '/var/dbfw/upgrade'.
The upgrade can then be started by running: /usr/bin/avdf-upgrade
6.4.1.3 Transfer the ISO File to the Appliance

Transfer the avdf-upgrade-20.x.0.0.0.iso file to the appliance that you're updating.

  1. Log in to the appliance through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Copy the avdf-upgrade-20.x.0.0.0.iso file by using the following command: 

    scp remote_host:/path/to/avdf-upgrade-20.x.0.0.0.iso /var/dbfw/upgrade
6.4.1.4 Start the Update Script

The update script mounts the ISO, changes to the correct working directory, runs the update process, and unmounts the ISO after the upgrade process is complete.

Note:

The system may take some time to complete the commands. Don't interrupt the update or the system may be left in an inconsistent state. For this reason, it is important to use a reliable and uninterruptible shell, such as a direct console login (or ILOM equivalent), or use the screen command to prevent network disconnections from interrupting the update.

  1. Log in to the appliance through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Run the screen command as the root user.

    The screen command prevents network disconnections from interrupting the update. If the session terminates, resume by switching to the root user and then running the screen -r command.

  3. Run the following command to perform the appropriate checks before updating:

    /usr/bin/avdf-upgrade

  4. Follow the system prompt, warning, and instruction to proceed with the update accordingly.

    You should see output like the following:

    Please wait while validating SHA256 checksum for /var/dbfw/upgrade/avdf-upgrade-20.x.0.0.0.iso 
Checksum validation successful for /var/dbfw/upgrade/avdf-upgrade-20.x.0.0.0.iso 
Mounting /var/dbfw/upgrade/avdf-upgrade-20.x.0.0.0.iso on /images 
mount: /dev/loop0 is write-protected, mounting read-only 
Successfully mounted /var/dbfw/upgrade/avdf-upgrade-20.x.0.0.0.iso on /images 

The following messages have important information about the upgrade process. 

Power loss during upgrade may cause data loss. Do not power off during upgrade. Please review Note ID 2235931.1 for a current list of known issues. 

The upgrade process is irreversible, please confirm 'y' to continue or 'n' to abort. [y/N]?

  5. Enter y to proceed.

    You should see output like the following:

    The Oracle base has been set to /var/lib/oracle 
Error: 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: 4475 
Additional information: 1990413931 
The Oracle base has been set to /var/lib/oracle 
Error: 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: 4475 
Additional information: 1990413931 
Verifying upgrade preconditions 
1/11: Mounting filesystems (1) 
2/11: Cleaning yum configuration 
3/11: Cleaning old packages and files 
4/11: Upgrading kernel 
5/11: Upgrading system 
6/11: Cleaning platform packages repo 
7/11: Adding required platform packages 
8/11: Cleaning AVDF packages repo 
9/11: Installing AVDF packages 
10/11: Setting boot title 
11/11: Setting final system status 
Reboot now to continue the upgrade process. 
Unmounted /var/dbfw/upgrade/avdf-upgrade-20.x.0.0.0.iso on /images

    Note:

    The preceding output varies depending on the base installation level, appliance type, and configuration.
6.4.1.5 Restart the Appliance

After updating, restart the appliance and continue the update process.

  1. Log in to the appliance through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Restart the appliance. For example:

    reboot

    Note:

    When the appliance restarts, the update process continues. This takes several hours to complete on Audit Vault Servers and several minutes to complete on Database Firewalls. Don't restart the system while this is in progress.

  3. If you've updated a Database Firewall, it may have regenerated the appliance certificate. In this scenario, you need to reregister the Database Firewall. To check this:

    1. Log in to the Audit Vault Server console as an administrator.

    2. Click the Database Firewalls tab.

      In the left navigation menu, Database Firewalls is selected by default and the page displays a list of configured Database Firewall instances.

    3. Select the Database Firewall instance that indicates a certificate error after the update.
    4. Click Reset Firewall.

    See Also:

    Registering a Database Firewall in the Audit Vault Server

6.4.2 Update a Pair of Audit Vault Servers That Are Configured for High Availability

Follow this process to update a pair of Audit Vault Servers in a high availability environment.

Note:

Don't change the primary and standby roles before completing the update on both Audit Vault Servers.

Follow this process:

  1. Update the standby Audit Vault Server.

  2. After you reboot the standby Audit Vault Server, ensure that it is up and running before updating the primary Audit Vault Server.
  3. Stop the audit trails on the primary Audit Vault Server.

  4. Update the primary Audit Vault Server.

    After you reboot the primary Audit Vault Server and confirm that it's running, no additional reboot is needed. It's fully functional at this point.

6.4.2.1 Update the Standby Audit Vault Server

Use this procedure to update the standby Audit Vault Server in a high availability environment. Update the standby Audit Vault server first, then update the primary Audit Vault Server.

Follow this process:

  1. Check the failover status on the primary Audit Vault Server.
  2. Run the pre-upgrade RPM.
  3. Transfer the ISO file to the appliance.
  4. Start the update script.
  5. Restart the appliance.

Note:

When the appliance restarts, the update process continues. This takes several hours to complete on Audit Vault Servers. Don't restart the system while this is in progress.

6.4.2.1.1 Check the Failover Status on the Primary Audit Vault Server

Before running the pre-upgrade RPM in a high availability environment, check the failover status on the primary Audit Vault Server. If the failover status is STALLED, then wait for a while and check the status again. If the status doesn't change, then contact Oracle Support.

Follow these steps on the primary Audit Vault Server:

  1. Log in to the primary Audit Vault Server through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Switch to the oracle user.

    su - oracle

  3. Run the following command:

    /usr/local/dbfw/bin/setup_ha.rb --status

  4. Check the failover status in the output.

6.4.2.1.2 Run the Pre-upgrade RPM

Run the pre-upgrade RPM to check for the required space in the file system and prepare the system for updating.

Note:

The patching process uses the same pre-upgrade RPM as the upgrade process, although patching involves a smaller subset of tasks compared to a full upgrade.

The pre-upgrade RPM performs the following tasks to prepare the system for updating:

  • Rearranges free space on the appliance so that there's enough room to copy the patch files to the appliance and start the installation. After the update, the space for the patch files is returned to the file system.
  • Starting with updates from Oracle AVDF 20.9 to Oracle AVDF 20.10 and later, verifies that the Audit Vault Agents and Host Monitor Agents are compatible with the new version of the Audit Vault Server. For example, it verifies that agent host machines have compatible operating system and Java versions.
  • Verifies that other prerequisites and platform conditions are met before the update.
  • Prepares the system for updating by creating the /var/dbfw/upgrade directory with enough space to hold the main ISO file for the update.

To run the pre-upgrade RPM, follow these steps:

  1. Log in to the appliance through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Run the screen command as the root user.

    The screen command prevents network disconnections from interrupting the update. If the session terminates, resume by switching to the root user and then running the screen -r command.

  3. Change to the root directory. 

    cd /root

  4. Run the following command to copy the pre-upgrade RPM file from the downloaded location to the appliance:

    scp remote_host:/path/to/avdf-pre-upgrade-20.x.0.0.0.zip /root

  5. Verify the download by using a shasum of the avdf-pre-upgrade-20.x.0.0.0.zip file. 

    sha256sum /root/avdf-pre-upgrade-20.x.0.0.0.zip

  6. Unzip the bundle.

    unzip /root/avdf-pre-upgrade-20.x.0.0.0.zip

  7. Run the following command to run the avdf-pre-upgrade-20.x.0.0.0-0_NNNNNN.NNNN.x86_64.rpm file: 

    rpm -i /root/avdf-pre-upgrade-20.x.0.0.0-0_NNNNNN.NNNN.x86_64.rpm

    The following message appears:

    SUCCESS: The upgrade media can now be copied to '/var/dbfw/upgrade'.
The upgrade can then be started by running: /usr/bin/avdf-upgrade
6.4.2.1.3 Transfer the ISO File to the Appliance

Transfer the avdf-upgrade-20.x.0.0.0.iso file to the appliance that you're updating.

  1. Log in to the appliance through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Copy the avdf-upgrade-20.x.0.0.0.iso file by using the following command: 

    scp remote_host:/path/to/avdf-upgrade-20.x.0.0.0.iso /var/dbfw/upgrade
6.4.2.1.4 Start the Update Script

The update script mounts the ISO, changes to the correct working directory, runs the update process, and unmounts the ISO after the upgrade process is complete.

Note:

The system may take some time to complete the commands. Don't interrupt the update or the system may be left in an inconsistent state. For this reason, it is important to use a reliable and uninterruptible shell, such as a direct console login (or ILOM equivalent), or use the screen command to prevent network disconnections from interrupting the update.

  1. Log in to the appliance through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Run the screen command as the root user.

    The screen command prevents network disconnections from interrupting the update. If the session terminates, resume by switching to the root user and then running the screen -r command.

  3. Run the following command to perform the appropriate checks before updating:

    /usr/bin/avdf-upgrade

  4. Follow the system prompt, warning, and instruction to proceed with the update accordingly.

    You should see output like the following:

    Please wait while validating SHA256 checksum for /var/dbfw/upgrade/avdf-upgrade-20.x.0.0.0.iso 
Checksum validation successful for /var/dbfw/upgrade/avdf-upgrade-20.x.0.0.0.iso 
Mounting /var/dbfw/upgrade/avdf-upgrade-20.x.0.0.0.iso on /images 
mount: /dev/loop0 is write-protected, mounting read-only 
Successfully mounted /var/dbfw/upgrade/avdf-upgrade-20.x.0.0.0.iso on /images 

The following messages have important information about the upgrade process. 

Power loss during upgrade may cause data loss. Do not power off during upgrade. Please review Note ID 2235931.1 for a current list of known issues. 

The upgrade process is irreversible, please confirm 'y' to continue or 'n' to abort. [y/N]?

  5. Enter y to proceed.

    You should see output like the following:

    The Oracle base has been set to /var/lib/oracle 
Error: 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: 4475 
Additional information: 1990413931 
The Oracle base has been set to /var/lib/oracle 
Error: 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: 4475 
Additional information: 1990413931 
Verifying upgrade preconditions 
1/11: Mounting filesystems (1) 
2/11: Cleaning yum configuration 
3/11: Cleaning old packages and files 
4/11: Upgrading kernel 
5/11: Upgrading system 
6/11: Cleaning platform packages repo 
7/11: Adding required platform packages 
8/11: Cleaning AVDF packages repo 
9/11: Installing AVDF packages 
10/11: Setting boot title 
11/11: Setting final system status 
Reboot now to continue the upgrade process. 
Unmounted /var/dbfw/upgrade/avdf-upgrade-20.x.0.0.0.iso on /images

    Note:

    The preceding output varies depending on the base installation level, appliance type, and configuration.
6.4.2.1.5 Restart the Appliance

After updating, restart the appliance and continue the update process.

  1. Log in to the appliance through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Restart the appliance. For example:

    reboot

    Note:

    When the appliance restarts, the update process continues. This takes several hours to complete on Audit Vault Servers and several minutes to complete on Database Firewalls. Don't restart the system while this is in progress.

  3. If you've updated a Database Firewall, it may have regenerated the appliance certificate. In this scenario, you need to reregister the Database Firewall. To check this:

    1. Log in to the Audit Vault Server console as an administrator.

    2. Click the Database Firewalls tab.

      In the left navigation menu, Database Firewalls is selected by default and the page displays a list of configured Database Firewall instances.

    3. Select the Database Firewall instance that indicates a certificate error after the update.
    4. Click Reset Firewall.

    See Also:

    Registering a Database Firewall in the Audit Vault Server
6.4.2.2 Stop All Audit Trails

Stop all audit trails before updating the Audit Vault Server.

  1. Log into the Audit Vault Server console as an administrator.
  2. Click the Targets tab.
  3. Click Audit Trails in the left navigation menu.
  4. Select all audit trails.
  5. Click Stop.
6.4.2.3 Update the Primary Audit Vault Server

To update the primary Audit Vault Server in a high availability environment, follow the same process that you used to update the standby Audit Vault Server.

6.5 Verify That Audit Vault Agents and Host Monitor Agents Were Automatically Updated

The Audit Vault Agents and Host Monitor Agents are automatically updated when you update the Audit Vault Server. However, some situations require manual updates.

Note:

During the Audit Vault Agent automatic update process, its status is UNREACHABLE. It may take as long as 45 minutes to return to the RUNNING state.

In the following situations you may need to update the Audit Vault Agents manually:

  • On Windows hosts, the Audit Vault Agent is updated automatically only if you've registered it as a Windows service and you've set this service to use the credentials of the OS user that originally installed the agent. See Additional Requirements for Starting Audit Vault Agent as a Service on Windows for more information.

    When you start the agent from the command line, the Audit Vault Agent does not automatically update. In this case, update the agent manually. For example:

    <agent_home>\bin\agentctl.bat stop

    Download the new agent.jar from the Audit Vault Server console and extract it using java -jar agent.jar from the agent_home of the existing agent. Then run the following command: 

    <agent_home>\bin\agentctl.bat start

    Don't delete the existing agent_home directory.

  • When configuring the Audit vault Server for high availability, if the designated standby Audit Vault Server's agents were deployed before pairing, then manually download and deploy the agents again after pairing.

6.6 Update the Database Firewalls

After you update all Audit Vault Servers, update the Database Firewalls.

When you update Database Firewalls that are configured for high availability (a resilient pair), update both primary and standby Database Firewalls. Update the standby Database Firewall instance first. Restart the standby instance after the update. Swap the roles of the primary and standby Database Firewall instances in the high availability environment so that the existing standby instance becomes the primary instance. Update the standby (previous primary) Database Firewall instance.

For standalone Database Firewall instances, update all of them independently.

Note:

  • After updating to Oracle Audit Vault and Database Firewall (Oracle AVDF) release 20.3 or later, the status of some of the Database Firewall monitoring points may be Down.

    The Database Firewall policies that were created before the update are being migrated to the new format. This may take a few minutes. Navigate to the Jobs dialog box in the Audit Vault Server console and check the status of the Firewall post-upgrade actions job. If the background job fails, then deploy the Database Firewall policy by using the Audit Vault Server console only. Verify that the status of the Database Firewall monitoring points has changed to Up. Otherwise, start the monitoring point.

  • You can't perform the following operations until the Database Firewalls are updated:

    • Database Firewall policy deployment
    • New configurations or configuration changes

  • In this section, the word appliance refers to the Database Firewall.

6.6.1 Update a Standalone Database Firewall

Use this procedure to update a standalone Database Firewall that is not paired in a high availability environment.

Follow this process:

  1. Stop all Database Firewall monitoring points.
  2. Run the pre-upgrade RPM.
  3. Transfer the ISO file to the appliance.
  4. Start the update script.
  5. Restart the appliance.

Note:

When the appliance restarts, the update process continues. This takes several minutes to complete on Database Firewalls. Don't restart the system while this is in progress.

6.6.1.1 Stop All Database Firewall Monitoring Points

Stop all monitoring points before updating the Database Firewall.

  1. Log into the Audit Vault Server console as an administrator.
  2. Click the Database Firewalls tab.
  3. Click Database Firewall Monitoring in the left navigation menu.
  4. Select all monitoring points.
  5. Click Stop.
6.6.1.2 Run the Pre-upgrade RPM

Run the pre-upgrade RPM to check for the required space in the file system and prepare the system for updating.

Note:

The patching process uses the same pre-upgrade RPM as the upgrade process, although patching involves a smaller subset of tasks compared to a full upgrade.

The pre-upgrade RPM performs the following tasks to prepare the system for updating:

  • Rearranges free space on the appliance so that there's enough room to copy the patch files to the appliance and start the installation. After the update, the space for the patch files is returned to the file system.
  • Starting with updates from Oracle AVDF 20.9 to Oracle AVDF 20.10 and later, verifies that the Audit Vault Agents and Host Monitor Agents are compatible with the new version of the Audit Vault Server. For example, it verifies that agent host machines have compatible operating system and Java versions.
  • Verifies that other prerequisites and platform conditions are met before the update.
  • Prepares the system for updating by creating the /var/dbfw/upgrade directory with enough space to hold the main ISO file for the update.

To run the pre-upgrade RPM, follow these steps:

  1. Log in to the appliance through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Run the screen command as the root user.

    The screen command prevents network disconnections from interrupting the update. If the session terminates, resume by switching to the root user and then running the screen -r command.

  3. Change to the root directory. 

    cd /root

  4. Run the following command to copy the pre-upgrade RPM file from the downloaded location to the appliance:

    scp remote_host:/path/to/avdf-pre-upgrade-20.x.0.0.0.zip /root

  5. Verify the download by using a shasum of the avdf-pre-upgrade-20.x.0.0.0.zip file. 

    sha256sum /root/avdf-pre-upgrade-20.x.0.0.0.zip

  6. Unzip the bundle.

    unzip /root/avdf-pre-upgrade-20.x.0.0.0.zip

  7. Run the following command to run the avdf-pre-upgrade-20.x.0.0.0-0_NNNNNN.NNNN.x86_64.rpm file: 

    rpm -i /root/avdf-pre-upgrade-20.x.0.0.0-0_NNNNNN.NNNN.x86_64.rpm

    The following message appears:

    SUCCESS: The upgrade media can now be copied to '/var/dbfw/upgrade'.
The upgrade can then be started by running: /usr/bin/avdf-upgrade
6.6.1.3 Transfer the ISO File to the Appliance

Transfer the avdf-upgrade-20.x.0.0.0.iso file to the appliance that you're updating.

  1. Log in to the appliance through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Copy the avdf-upgrade-20.x.0.0.0.iso file by using the following command: 

    scp remote_host:/path/to/avdf-upgrade-20.x.0.0.0.iso /var/dbfw/upgrade
6.6.1.4 Start the Update Script

The update script mounts the ISO, changes to the correct working directory, runs the update process, and unmounts the ISO after the upgrade process is complete.

Note:

The system may take some time to complete the commands. Don't interrupt the update or the system may be left in an inconsistent state. For this reason, it is important to use a reliable and uninterruptible shell, such as a direct console login (or ILOM equivalent), or use the screen command to prevent network disconnections from interrupting the update.

  1. Log in to the appliance through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Run the screen command as the root user.

    The screen command prevents network disconnections from interrupting the update. If the session terminates, resume by switching to the root user and then running the screen -r command.

  3. Run the following command to perform the appropriate checks before updating:

    /usr/bin/avdf-upgrade

  4. Follow the system prompt, warning, and instruction to proceed with the update accordingly.

    You should see output like the following:

    Please wait while validating SHA256 checksum for /var/dbfw/upgrade/avdf-upgrade-20.x.0.0.0.iso 
Checksum validation successful for /var/dbfw/upgrade/avdf-upgrade-20.x.0.0.0.iso 
Mounting /var/dbfw/upgrade/avdf-upgrade-20.x.0.0.0.iso on /images 
mount: /dev/loop0 is write-protected, mounting read-only 
Successfully mounted /var/dbfw/upgrade/avdf-upgrade-20.x.0.0.0.iso on /images 

The following messages have important information about the upgrade process. 

Power loss during upgrade may cause data loss. Do not power off during upgrade. Please review Note ID 2235931.1 for a current list of known issues. 

The upgrade process is irreversible, please confirm 'y' to continue or 'n' to abort. [y/N]?

  5. Enter y to proceed.

    You should see output like the following:

    The Oracle base has been set to /var/lib/oracle 
Error: 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: 4475 
Additional information: 1990413931 
The Oracle base has been set to /var/lib/oracle 
Error: 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: 4475 
Additional information: 1990413931 
Verifying upgrade preconditions 
1/11: Mounting filesystems (1) 
2/11: Cleaning yum configuration 
3/11: Cleaning old packages and files 
4/11: Upgrading kernel 
5/11: Upgrading system 
6/11: Cleaning platform packages repo 
7/11: Adding required platform packages 
8/11: Cleaning AVDF packages repo 
9/11: Installing AVDF packages 
10/11: Setting boot title 
11/11: Setting final system status 
Reboot now to continue the upgrade process. 
Unmounted /var/dbfw/upgrade/avdf-upgrade-20.x.0.0.0.iso on /images

    Note:

    The preceding output varies depending on the base installation level, appliance type, and configuration.
6.6.1.5 Restart the Appliance

After updating, restart the appliance and continue the update process.

  1. Log in to the appliance through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Restart the appliance. For example:

    reboot

    Note:

    When the appliance restarts, the update process continues. This takes several hours to complete on Audit Vault Servers and several minutes to complete on Database Firewalls. Don't restart the system while this is in progress.

  3. If you've updated a Database Firewall, it may have regenerated the appliance certificate. In this scenario, you need to reregister the Database Firewall. To check this:

    1. Log in to the Audit Vault Server console as an administrator.

    2. Click the Database Firewalls tab.

      In the left navigation menu, Database Firewalls is selected by default and the page displays a list of configured Database Firewall instances.

    3. Select the Database Firewall instance that indicates a certificate error after the update.
    4. Click Reset Firewall.

    See Also:

    Registering a Database Firewall in the Audit Vault Server

6.6.2 Update a Pair of Database Firewalls That Are Configured for High Availability

Use this procedure to update a pair of Database Firewalls in a high availability environment.

Follow this process:

  1. Update the standby Database Firewall.
  2. After the standby Database Firewall has fully restarted, swap the standby Database Firewall so that it becomes the primary Database Firewall.
  3. Update the original primary (now standby) Database Firewall.
  4. (Optional) After the original primary Database Firewall has fully restarted, swap the Database Firewalls so they return to their original primary and standby roles.
6.6.2.1 Update the Standby Database Firewall

Use this procedure to update the standby Database Firewall in a high availability environment. Update the standby Database Firewall first, then swap this Database Firewall so that it becomes the primary Database Firewall. Then update the original primary (now standby) Database Firewall.

Follow this process:

  1. Stop all Database Firewall monitoring points.
  2. Run the pre-upgrade RPM.
  3. Transfer the ISO file to the appliance.
  4. Start the update script.
  5. Restart the appliance.

Note:

When the appliance restarts, the update process continues. This takes several minutes to complete on Database Firewalls. Don't restart the system while this is in progress.

6.6.2.1.1 Stop All Database Firewall Monitoring Points

Stop all monitoring points before updating the Database Firewall.

  1. Log into the Audit Vault Server console as an administrator.
  2. Click the Database Firewalls tab.
  3. Click Database Firewall Monitoring in the left navigation menu.
  4. Select all monitoring points.
  5. Click Stop.
6.6.2.1.2 Run the Pre-upgrade RPM

Run the pre-upgrade RPM to check for the required space in the file system and prepare the system for updating.

Note:

The patching process uses the same pre-upgrade RPM as the upgrade process, although patching involves a smaller subset of tasks compared to a full upgrade.

The pre-upgrade RPM performs the following tasks to prepare the system for updating:

  • Rearranges free space on the appliance so that there's enough room to copy the patch files to the appliance and start the installation. After the update, the space for the patch files is returned to the file system.
  • Starting with updates from Oracle AVDF 20.9 to Oracle AVDF 20.10 and later, verifies that the Audit Vault Agents and Host Monitor Agents are compatible with the new version of the Audit Vault Server. For example, it verifies that agent host machines have compatible operating system and Java versions.
  • Verifies that other prerequisites and platform conditions are met before the update.
  • Prepares the system for updating by creating the /var/dbfw/upgrade directory with enough space to hold the main ISO file for the update.

To run the pre-upgrade RPM, follow these steps:

  1. Log in to the appliance through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Run the screen command as the root user.

    The screen command prevents network disconnections from interrupting the update. If the session terminates, resume by switching to the root user and then running the screen -r command.

  3. Change to the root directory. 

    cd /root

  4. Run the following command to copy the pre-upgrade RPM file from the downloaded location to the appliance:

    scp remote_host:/path/to/avdf-pre-upgrade-20.x.0.0.0.zip /root

  5. Verify the download by using a shasum of the avdf-pre-upgrade-20.x.0.0.0.zip file. 

    sha256sum /root/avdf-pre-upgrade-20.x.0.0.0.zip

  6. Unzip the bundle.

    unzip /root/avdf-pre-upgrade-20.x.0.0.0.zip

  7. Run the following command to run the avdf-pre-upgrade-20.x.0.0.0-0_NNNNNN.NNNN.x86_64.rpm file: 

    rpm -i /root/avdf-pre-upgrade-20.x.0.0.0-0_NNNNNN.NNNN.x86_64.rpm

    The following message appears:

    SUCCESS: The upgrade media can now be copied to '/var/dbfw/upgrade'.
The upgrade can then be started by running: /usr/bin/avdf-upgrade
6.6.2.1.3 Transfer the ISO File to the Appliance

Transfer the avdf-upgrade-20.x.0.0.0.iso file to the appliance that you're updating.

  1. Log in to the appliance through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Copy the avdf-upgrade-20.x.0.0.0.iso file by using the following command: 

    scp remote_host:/path/to/avdf-upgrade-20.x.0.0.0.iso /var/dbfw/upgrade
6.6.2.1.4 Start the Update Script

The update script mounts the ISO, changes to the correct working directory, runs the update process, and unmounts the ISO after the upgrade process is complete.

Note:

The system may take some time to complete the commands. Don't interrupt the update or the system may be left in an inconsistent state. For this reason, it is important to use a reliable and uninterruptible shell, such as a direct console login (or ILOM equivalent), or use the screen command to prevent network disconnections from interrupting the update.

  1. Log in to the appliance through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Run the screen command as the root user.

    The screen command prevents network disconnections from interrupting the update. If the session terminates, resume by switching to the root user and then running the screen -r command.

  3. Run the following command to perform the appropriate checks before updating:

    /usr/bin/avdf-upgrade

  4. Follow the system prompt, warning, and instruction to proceed with the update accordingly.

    You should see output like the following:

    Please wait while validating SHA256 checksum for /var/dbfw/upgrade/avdf-upgrade-20.x.0.0.0.iso 
Checksum validation successful for /var/dbfw/upgrade/avdf-upgrade-20.x.0.0.0.iso 
Mounting /var/dbfw/upgrade/avdf-upgrade-20.x.0.0.0.iso on /images 
mount: /dev/loop0 is write-protected, mounting read-only 
Successfully mounted /var/dbfw/upgrade/avdf-upgrade-20.x.0.0.0.iso on /images 

The following messages have important information about the upgrade process. 

Power loss during upgrade may cause data loss. Do not power off during upgrade. Please review Note ID 2235931.1 for a current list of known issues. 

The upgrade process is irreversible, please confirm 'y' to continue or 'n' to abort. [y/N]?

  5. Enter y to proceed.

    You should see output like the following:

    The Oracle base has been set to /var/lib/oracle 
Error: 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: 4475 
Additional information: 1990413931 
The Oracle base has been set to /var/lib/oracle 
Error: 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: 4475 
Additional information: 1990413931 
Verifying upgrade preconditions 
1/11: Mounting filesystems (1) 
2/11: Cleaning yum configuration 
3/11: Cleaning old packages and files 
4/11: Upgrading kernel 
5/11: Upgrading system 
6/11: Cleaning platform packages repo 
7/11: Adding required platform packages 
8/11: Cleaning AVDF packages repo 
9/11: Installing AVDF packages 
10/11: Setting boot title 
11/11: Setting final system status 
Reboot now to continue the upgrade process. 
Unmounted /var/dbfw/upgrade/avdf-upgrade-20.x.0.0.0.iso on /images

    Note:

    The preceding output varies depending on the base installation level, appliance type, and configuration.
6.6.2.1.5 Restart the Appliance

After updating, restart the appliance and continue the update process.

  1. Log in to the appliance through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Restart the appliance. For example:

    reboot

    Note:

    When the appliance restarts, the update process continues. This takes several hours to complete on Audit Vault Servers and several minutes to complete on Database Firewalls. Don't restart the system while this is in progress.

  3. If you've updated a Database Firewall, it may have regenerated the appliance certificate. In this scenario, you need to reregister the Database Firewall. To check this:

    1. Log in to the Audit Vault Server console as an administrator.

    2. Click the Database Firewalls tab.

      In the left navigation menu, Database Firewalls is selected by default and the page displays a list of configured Database Firewall instances.

    3. Select the Database Firewall instance that indicates a certificate error after the update.
    4. Click Reset Firewall.

    See Also:

    Registering a Database Firewall in the Audit Vault Server
6.6.2.2 Swap the Standby and Primary Database Firewalls

After updating the standby Database Firewall, swap the standby Database Firewall so that it becomes the primary Database Firewall. You can also swap the Database Firewalls back to their original roles after updating them both.

  1. Log into the Audit Vault Server console as an administrator.
  2. Click the Database Firewalls tab.
  3. Click High Availability in the left navigation menu.
  4. Select this resilient pair of Database Firewall instances.

  5. Click Swap.

6.6.2.3 Update the Original Primary (Now Standby) Database Firewall

To update the original primary (now standby) Database Firewall in a high availability environment, follow the same process that you used to update the original standby Database Firewall.

6.7 Post-update Tasks

After updating Oracle Audit Vault and Database Firewall (Oracle AVDF), complete these tasks to confirm the update process, enable required functionality, and resolve any remaining issues.

Note:

  • If you're updating Audit Vault Server to releases 20.1 through 20.3, then apply the Deprecated-Cipher-Removal.zip patch after updating.
  • If you're updating Audit Vault Server to release 20.4 and later, then apply the Deprecated-Cipher-Removal.zip patch only if you reduce the TLS level during the update.

See Also:

Unable to Log in to the Oracle AVDF Appliance through SSH

6.7.1 Confirm the Update Process

Use these steps to verify that the update process was successful.

Successful Updates of Audit Vault Servers

  1. Verify that you can open the Audit Vault Server console without any issues.
  2. Verify that you can log in to the Audit Vault Server console as an administrator and an auditor without any issues.
  3. Verify that you can connect to the Audit Vault Server through SSH without any issues.
  4. Log in to the Audit Vault Server console as an administrator and check the following items:
    1. Click Settings tab, and then click System in the left navigation menu.
    2. Verify that the Audit Vault Server Version field displays the correct version of Audit Vault Server.
    3. Check the Uptime value.
    4. Ensure that Database Firewall log collection displays a green arrow pointing up.
    5. Ensure that Background Job displays a green arrow pointing up.
    6. Check the High Availability Status value.

Successful Updates of Audit Vault Agents

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Agents tab.
  3. Verify that all Audit Vault agents have a status of RUNNING.
  4. Verify that the Agent Details column displays the correct version for each Audit Vault Agent.

Successful Updates of Database Firewalls

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Database Firewalls tab.
  3. Verify that all Database Firewalls have a status of Up.
  4. Verify that the Version column displays the correct version for each Database Firewall.
  5. Click the link for a specific Database Firewall in the Name column.
  6. Verify that the Firewall Version field also displays the correct version.
  7. Click the Health Indicators link in the Diagnostics section and verify that all the health indicators must have a green mark.
  8. Close the dialog box.
  9. Click Database Firewall Monitoring in the left navigation menu.
  10. Verify that tall the monitoring points have a status of Up.

Unsuccessful Updates

The following symptoms indicate that an update has failed:

  • You're unable to open the Audit Vault Server console.
  • An SSH connection to the Audit Vault Server (or the terminal) displays an error that the update has failed.

Note:

Also review the system diagnostics for the current status and system log for any errors.

6.7.2 Post Upgrade Agent User Security Hardening

When updating to Oracle Audit Vault and Database Firewall (Oracle AVDF) 20.9 or later, tighten the agent user privileges after all the agents have been updated.

  1. Confirm that all the agents have been updated.

    See Confirm the Update Process.

  2. Download the revoke_privileges.sql script (patch number 35303191) from My Oracle Support.

  3. Log in to the Audit Vault Server through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  4. Unlock the avsys user.

    See Unlocking the AVSYS User.

    Note:

    Remember to relock the avsys account when you've completed this task.
  5. Transfer the downloaded revoke_privileges.sql script to the Audit Vault Server (for example, to /tmp).

  6. Start SQL*Plus as the avsys user. 

    sqlplus avsys

  7. Enter the password at the prompt.

  8. Run the revoke_privileges.sql script. 

    @<path to revoke_privileges.sql>

    For example, if you copied the file to /tmp, then enter @/tmp/revoke_privileges.sql.

  9. Exit back to root. 

    exit

  10. Lock the avsys user.

    See Locking the AVSYS User.

6.7.3 Enable Administrator Access to Existing Archive Locations

After updating Oracle Audit Vault and Database Firewall, the following new behavior applies to archive locations:

  • New archive locations are owned by the user with an administrator role who created them.
  • Users with the super administrator role can view all archive locations.
  • Only users with the super administrator role can access existing archive locations.

To give regular users with the administrator role access to existing archive locations, perform the following steps for each archive location:

  1. Log in to the Audit Vault Server through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Unlock the avsys user.

    See Unlocking the AVSYS User.

    Note:

    Remember to relock the avsys account when you've completed this task.
  3. Exit back to root.

  4. Start SQL*Plus as the avsys user. 

    sqlplus avsys

  5. Enter the password at the prompt.

  6. Run the following commands:

    update avsys.archive_host set created_by=<adminuser> where name=<archive location name>;
commit;
exit;

  7. Exit back to root. 

    exit

  8. Lock the avsys user.

    See Locking the AVSYS User.

6.7.4 Enable Archiving Functionality for High Availability

If the Audit Vault Server is deployed in a high availability environment, you might need to enable archiving after the update.

If you have Network File System (NFS) locations and archived data files, ensure that all the data files are available in the respective NFS locations. After completing the upgrade process, archiving is disabled, so you need to enable it.

  • Oracle Audit Vault and Database Firewall (Oracle AVDF) release 20.1 and later support archive and retrieve functionality with NFS server versions v3 and v4.
  • Only NFS v3 is not supported for releases 20.3 and earlier. It is supported starting Oracle AVDF release 20.4.
  • If your NFS server supports and permits both v3 and v4 for archive or retrieve, then no action is required.

  • If you have NFS v4 only in your environment for archive or retrieve, then set the _SHOWMOUNT_DISABLED parameter to TRUE using the following steps:

    1. Log in to the Audit Vault Server through SSH and switch to the root user.

      See Logging In to Oracle AVDF Appliances Through SSH.

    2. Switch to the oracle user.

      su - oracle

    3. Start SQL*Plus without the user name or password.

      sqlplus /nolog

    4. In SQL*Plus, run the following command:

      connect <super administrator>

    5. Enter the password when prompted.

    6. Run the following command:

      exec avsys.adm.add_config_param('_SHOWMOUNT_DISABLED','TRUE');

  1. Log in to the primary Audit Vault Server through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Switch to the oracle user.

    su - oracle

  3. Create new NFS locations by using the Audit Vault Server console.

    These new locations consider the newly mounted NFS points for both the primary and secondary Audit Vault Servers. Ensure that there is sufficient space in the newly created NFS locations to store all the necessary data files to be archived.

  4. Start SQL*Plus without the user name or password.

    sqlplus /nolog

  5. In SQL*Plus run the following command:

    connect super administrator

  6. Enter the password when prompted.

  7. Enable the archiving functionality by running the following command:

    exec management.ar.run_hailm_job('<NFS location name defined>');

    This command initiates a background job. You can view the status on the Jobs page. The name of the job is HAILM POST UPGRADE JOB.

    After you enable this functionality , all the archived data files are moved to the new NFS location and archiving is enabled after the job completes successfully.

6.7.5 Clear Unused Kernels from Oracle Audit Vault and Database Firewall

See My Oracle Support Doc ID 2458154.1 for instructions to clear unused kernels from Oracle Audit Vault and Database Firewall (Oracle AVDF).

6.7.6 Check the Observer Status After Updating to Oracle AVDF 20.7 or Later for High Availability

After upgrading from Oracle AVDF release 20.5 or 20.6 to release 20.7 or later in a high availability environment, you might encounter an issue with the Oracle Data Guard observer. The Audit Vault Server uses Oracle Data Guard to manage high availability.

To check the status of the Oracle Data Guard observer:

  1. Log in to the standby Audit Vault Server through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Switch to the oracle user.

    su - oracle

  3. Run the following commands:

    dgmgrl /
    show observer

    The output displays the status and the last ping interval of the observers running on both primary and standby Audit Vault Servers. The last ping interval of both observers must have a specific duration in seconds.

  4. If the output from the previous step doesn't display a specific duration for both observers, as shown in the following example, then complete the remaining steps to resolve the issue.

    
Host Name:                   <host name>
Last Ping to Primary:        (unknown)
Last Ping to Target:         (unknown)

    1. Log in to the standby Audit Vault Server through SSH and switch to the root user.

      See Logging In to Oracle AVDF Appliances Through SSH.

    2. Switch to the oracle user.

      su - oracle

    3. Run the following command:

      /usr/local/dbfw/bin/observerctl --stop
    4. Wait for one minute.

    5. Run the following commands:

      dgmgrl /
      show observer
    6. Verify that the last ping interval of both observers has a specific duration in seconds.

6.7.7 Configure Audit Vault Server Backups

The Audit Vault Server backup configuration file is release-specific and works on the same release for which it was created. Oracle recommends that you run the avbackup config command to create a new configuration file before performing the backup operation after updating Oracle Audit Vault and Database Firewall (Oracle AVDF).

6.7.8 Schedule Maintenance Jobs

Oracle Audit Vault and Database Firewall (Oracle AVDF) runs some jobs on the Audit Vault Server for proper and effective functioning of the system.

Oracle recommends that you run these jobs during a period when the Audit Vault Server usage is low, such as at night. You can schedule these jobs based on your time zone.
  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Settings tab.
  3. Click System in the left navigation menu.
  4. In the Configuration section, click one of the following links, depending on your release:
    Oracle AVDF Release Link
    20.1 and 20.2 Manage
    20.3 and later Maintenance
  5. To schedule a new maintenance job, enter the start time in hours and minutes.
    The time that you specify here is the time on the browser.
  6. In the Time Out (In hours) field, enter the duration of the maintenance job in hours.

    If the job doesn't complete in the specified duration, it times out.

    Note:

    The job runs at the specified start time daily. You can't change the repeat frequency.
  7. Click Save.

6.7.9 Enable FIPS Mode If It Was Disabled Before Patching to AVDF 20.10

After successfully patching to Oracle AVDF 20.10, you need to re-enable FIPS mode if it was disabled prior to patching.

Enable FIPS Mode on the Audit Vault Server

  1. Log in to Audit Vault Server console as a super administrator.
  2. Click the Settings tab.

    The Security tab in the left navigation menu is selected by default.

  3. Click the FIPS subtab on the main page.
  4. Click the toggle switch to enable FIPS 140-2. The toggle switch is green when it's on.
  5. Click Save.

    A message says that the Audit Vault Server will reboot and prompts you to continue or cancel.

  6. Click OK to continue to enable FIPS 140-2 for Audit Vault Server. Otherwise, click Cancel.

For Oracle AVDF on OCI, if SSH access becomes disabled after enabling FIPS mode, log into the Audit Vault Server console and disable FIPS mode. Then log back into the appliance through SSH and update the user keys for opc in /home/opc/.ssh/authorized_keys to be compliant with FIPS. It can take several minutes for the console to become available after enabling or disabling FIPS mode.

In a high availability configuration, enabling FIPS 140-2 mode for the primary Audit Vault Server also enables FIPS 140-2 mode for the standby Audit Vault Server. Similarly, disabling FIPS mode for the primary Audit Vault Server also disables it for the standby Audit Vault Server.

Enable FIPS Mode in Database Firewall

  1. Log in to Audit Vault Server console as super administrator.
  2. Click Database Firewalls tab. The Database Firewalls tab in the left navigation menu is selected by default.
  3. Click the name of the specific Database Firewall instance for which you want to enable FIPS 140-2.
  4. Click FIPS under the Configuration section. A dialog is displayed.
  5. In the dialog, turn on the toggle switch to enable FIPS 140-2. The toggle switch turns green when it is turned on.
  6. Click Save. A message pops that Database Firewall will reboot and prompts you to continue or cancel.
  7. Click OK to continue to enable FIPS 140-2 for the Database Firewall instance. Else, click Cancel.

    The Database Firewall instance is restarted and is unavailable for some time.

  8. Wait for a while, and navigate back to the Database Firewalls tab in the left navigation menu.
  9. Check the status of FIPS 140-2 mode under the column FIPS Mode against the specific Database Firewall instance.
  1. Log in to Audit Vault Server console as super administrator.
  2. Click Database Firewalls tab. The Database Firewalls tab in the left navigation menu is selected by default.
  3. Click High Availability tab in the left navigation menu. All the Database Firewall instances that are configured in high availability are listed in the main page.
  4. The names of paired Database Firewall instances are listed under the Primary and Secondary columns on the main page. Select the specific pair of Database Firewall instances for which you want to enable FIPS.
  5. Click FIPS in the top right corner of the page. A dialog is displayed.
  6. Turn on the toggle switch to enable FIPS 140-2. The toggle switch turns green when it is turned on.
  7. Click Save button. A message pops that the Database Firewall instances will reboot and prompts you to continue or cancel.
  8. Click OK to continue to enable FIPS 140-2 for the Database Firewall instances. Else, click Cancel.

    The Database Firewall instances are restarted and are unavailable for some time.

  9. Wait for a while and check the status of FIPS 140-2 mode under the column FIPS Mode against the paired Database Firewall instances.

Related Topics

6.7.10 Update Alert Notification Template for Alert Policies After Patching to AVDF 20.11

After successfully patching to Oracle AVDF 20.11, you need to update the alert notification template for your alert policies.

After patching to Oracle AVDF 20.11, the alert notification template for existing alert policies will be set to the default alert template. Auditors may need to update the alert notification template for their alert policies.

For more information on modifying email templates, see Creating or Modifying an Email Template in Oracle's Audit Vault and Database Firewall Auditor’s Guide.

6.8 Recover the Database If an Update Fails

If you backed up Oracle Audit Vault and Database Firewall (Oracle AVDF) before updating, and if there is enough space in the Audit Vault Server's flash recovery area, you may be able to recover the database after a failed update under the guidance of Oracle Support.

To make recovery of the database possible, you should have the following amount of free space in the flash recovery area:

20 GB or 150% of the amount of data that is stored in the Audit Vault Server database, whichever is larger

For information on monitoring the flash recovery area, see Oracle Audit Vault and Database Firewall Administrator's Guide.

6.9 Updating Oracle AVDF with Minimal Downtime by Using Backup and Restore

You can use the backup and restore functionality to update Oracle Audit Vault and Database Firewall (Oracle AVDF) to a new release with minimal downtime for monitoring and collecting data.

You can use this process to update from Oracle AVDF 20.3 and later to release 20.9 and later.

6.9.1 About the Update Process

When you update the Audit Vault Server to the latest Oracle AVDF release, you normally stop monitoring and collecting audit data at the beginning of the update process, which causes downtime until you complete the full update process.

To minimize this downtime, you can continue monitoring and collecting with your current (source) Audit Vault Server while performing the update on a new (destination) Audit Vault Server that's a backup-restored system. The source Audit Vault Server continues to monitor and collect audit data during the update. When the destination Audit Vault Server is completely updated, you migrate the delta data and then switch monitoring from the source Audit Vault Server to the new destination.

To update Oracle AVDF with the backup and restore functionality, use the following high-level process:

  1. Configure the source and destination Audit Vault Servers.
  2. Create a hot backup of the source Audit Vault Server.
  3. Restore the hot backup to the destination Audit Vault Server.
  4. Update the destination Audit Vault Server to the latest release.
  5. For a high availability environment, pair the primary and standby Audit Vault Servers.
  6. Replicate the collected audit data from the source Audit Vault Server to the destination.
  7. Update and migrate all monitoring and collection to the destination Audit Vault Server.
  8. Start all audit trails on the destination Audit Vault Server.

To perform the update process, complete all the tasks under this section.

6.9.2 Prerequisites

Complete the following tasks before beginning the update process.

  1. For the destination Audit Vault Server, complete a fresh installation of Oracle AVDF with the same hardware configuration as the current (source) Audit Vault Server.

    Install the same Oracle AVDF release that's running on the source Audit Vault Server. You'll update to the new Oracle AVDF release after you back up and restore to the destination Audit Vault Server.

    See Downloading and Installing Oracle Audit Vault and Database Firewall for instructions.

  2. Ensure that the new destination Audit Vault Server can access and connect to the source Audit Vault Server.

6.9.3 Configure the Source and Destination Audit Vault Servers

Before beginning the backup and restore process, you need to configure the source and destination Audit Vault Servers to be able to replicate the collected audit data later in the update process.

This configuration creates and starts the Oracle GoldenGate processes that will perform the data replication. You perform the actual replication later, after you update the destination Audit Vault Server to the latest release.

To configure the source and destination Audit Vault Servers, complete all the tasks under this section.

Note:

If, at any point during the update process, you need to change the destination Audit Vault Server or uninstall or reinstall the patch from the destination Audit Vault Server, uninstall the patch from the source Audit Vault Server and restart the update process from the beginning. For the patch bug numbers for your release, see Patch Bug Numbers for the Source and Destination Audit Vault Servers.

6.9.3.1 Patch Bug Numbers for the Source and Destination Audit Vault Servers

As part of the configuration, you install patches on the source and destination Audit Vault Servers.

Download both source and destination Audit Vault Server patches for your Oracle AVDF release.

Table 6-1 Patch Bug Numbers for the Source Audit Vault Server

Target Oracle AVDF Release Patch Bug Number
Updating to 20.11 36290747
Updating to 20.10 35703285
Updating to 20.9 34625846

Table 6-2 Patch Bug Numbers for the Destination Audit Vault Server

Target Oracle AVDF Release Patch Bug Number
Updating to 20.11 36290752
Updating to 20.10 35703288
Updating to 20.9 34625855
6.9.3.2 Create an NFS Location as an Archive Log Destination for the Source Audit Vault Server

Create a Network File System (NFS) location to use as the archive log destination for the Source Audit Vault Server.

  1. Log in to the source Audit Vault Server through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Monitor the space used for the archive logs.

    1. Switch to the oracle user.

      su - oracle

    2. Start SQL*Plus as sysdba. 

      sqlplus / as sysdba

    3. Run the following query:

      select  sum( blocks*block_size)/1024/1024 "Size (MB)" from v$archived_log where DELETED = 'NO';

      This query shows the space usage for the archive logs.

      Note:

      Use this query to monitor the size of archive log on source Audit Vault Server throughout the next steps. If the query output exceeds the size of the NFS location that you mount on the source Audit Vault Server in the following steps, add more space to the NFS location.

    4. Exit SQL*Plus.

      exit

  3. Mount an NFS location that has at least 500 GB free space on the source Audit Vault Server.

    1. Create a directory to use as a mount point (for example, /archive_log).

    2. Run the following command (using /archive_log as an example): 

      mount -t nfs <NFS_IP>:<export_path> /archive_log

      The exact mount command may vary.

      Make sure that the oracle user has read, write, and execute permissions for the directory that you created as the mount point.

      If you updated /etc/fstab to add the mount point, it reverts to the original state when the system is restarted.

  4. Set log_archive_dest_1 to the mounted NFS location.

    1. Switch to the oracle user.

      su - oracle

    2. Start SQL*Plus as sysdba. 

      sqlplus / as sysdba

    3. Run the following command (using /archive_log as an example): 

      alter system set log_archive_dest_1='LOCATION=/archive_log' scope=both;

    4. Exit SQL*Plus.

      exit
6.9.3.3 Configure the Source Audit Vault Server for Replication

Before you back up the source Audit Vault Server, you need to configure it for replication.

This is required to replicate the data that was collected during the update process from the source Audit Vault Server to the destination Audit Vault Server.

Note:

For a high availability configuration, apply this patch only on the primary Audit Vault Server.

  1. From My Oracle Support, download the source Audit Vault Server patch for your release. See Patch Bug Numbers for the Source and Destination Audit Vault Servers.

  2. Securely copy avs-source-20.x-replication.rpm to /home/support/ on the source Audit Vault Server.

    Note:

    If you're using the Oracle Cloud Infrastructure (OCI) marketplace image, copy the file to /home/opc/.

  3. Log in to the source Audit Vault Server through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  4. As the root user, install the RPM. 

    mv /home/support/avs-source-20.x-replication.rpm /
    rpm -i /avs-source-20.x-replication.rpm

    Note:

    If you're using the Oracle Cloud Infrastructure (OCI) marketplace image, enter the following commands:

    mv /home/opc/avs-source-20.x-replication.rpm /
    rpm -i /avs-source-20.x-replication.rpm

  5. Switch to the oracle user.

    su - oracle

  6. Run AVS_source_data_replication.py.

    1. Enter the following command:

      /usr/bin/python /var/lib/oracle/avs_source/AVS_source_data_replication.py --configure

      This command creates a new replication user, GGADMINSRC.

    2. When prompted, enter a new password for the GGADMINSRC user.

      The password should have at least one uppercase letter, one letter, one number, and one special character. It should be between 8 and 30 characters.

      You'll also need this password when you configure the destination Audit Vault Server for replication later in this process.

    3. When prompted, enter the super administrator user name and password.

    If the installation is successful, you should see the following message:

    AVS configured as source for replication successfully.

    If you don't see this message, contact Oracle Support.

  7. If you receive a warning message that archive log mode is not enabled, enable archive log mode before the next step.

    To enable archive log mode, follow these steps:

    1. Log in to the Audit Vault Server through SSH and switch to the root user.

      See Logging In to Oracle AVDF Appliances Through SSH.

    2. Run the following command to stop the monitor process:

      systemctl stop monitor

    3. Run the following command to shut down the Audit Vault Server repository (Oracle Database):

      systemctl stop dbfwdb

    4. Run the following command to ensure that the Audit Vault Server repository is shut down:

      /usr/local/dbfw/bin/dbfwdb status

      The output is ORACLE instance shut down.

    5. Switch to the oracle user.

      su - oracle

    6. Start SQL*Plus as sysdba. 

      sqlplus / as sysdba

    7. Run the following commands at the SQL*Plus prompt to enable archive log mode:

      startup mount
      alter database archivelog;
      alter database open;
      shutdown immediate;

    8. Exit SQL*Plus.

      exit

  8. Run the following command to start the Audit Vault Server repository (Oracle Database):

    systemctl start dbfwdb

  9. Run the following command to start the monitor process:

    systemctl start monitor

  10. As the root user, switch to the dvowner user and grant the replication privilege to the new replication user, GGADMINSRC. 

    su dvowner
    sqlplus /
    grant DV_GOLDENGATE_ADMIN, DV_GOLDENGATE_REDO_ACCESS to GGADMINSRC;
6.9.3.4 Configure the Destination Audit Vault Server for Replication

Before you back up the source Audit Vault Server and restore it to the destination Audit Vault Server, you need to configure it for replication.

This is required to replicate the data that was collected during the update process from the source Audit Vault Server to the destination Audit Vault Server.

  1. From My Oracle Support, download the destination Audit Vault Server patch for your release. See Patch Bug Numbers for the Source and Destination Audit Vault Servers.

  2. Securely copy avs-destination-20.x-replication.rpm to /home/support/ on the destination Audit Vault Server.

    Note:

    If you're using the Oracle Cloud Infrastructure (OCI) marketplace image, copy the file to /home/opc/.

  3. Log in to the destination Audit Vault Server through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  4. As the root user, install the RPM. 

    mv /home/support/avs-destination-20.x-replication.rpm /
    rpm -i avs-destination-20.x-replication.rpm

    Note:

    If you're using the Oracle Cloud Infrastructure (OCI) marketplace image, enter the following commands:

    mv /home/opc/avs-destination-20.x-replication.rpm /
    rpm -i avs-destination-20.x-replication.rpm

  5. Switch to the oracle user.

    su - oracle

  6. Verify that archive log mode is disabled.

    1. Start SQL*Plus as sysdba. 

      sqlplus / as sysdba

    2. Enter the following command to verify the archive log mode:

      select log_mode from v$database;

      If the output is NOARCHIVELOG, then archive log mode is disabled.

      If the output is ARCHIVELOG, then archive log mode is enabled and you need to disable it.

    3. To disable archive log mode, enter the following commands in sequence as the oracle user: 

      shutdown immediate;
      startup mount;
      alter database noarchivelog;
      alter database open;

    4. Verify that the changes were made.

      select name,log_mode from v$database;

      The output should be NOARCHIVELOG.

  7. Run the following command:

    /usr/bin/python /var/lib/oracle/avs_goldengate/AVS_target_data_replication.py --install_and_configure

    This command installs the Oracle GoldenGate Microservices Architecture.

  8. When prompted, enter a password for the new GoldenGate user, AVS_GG_ADMIN, that's created.

    The password should have at least one uppercase letter, one letter, one number, and one special character. It should be between 8 and 30 characters.

    You'll also need this password later in the replication process.

  9. When prompted, enter the IP address and the password for the GGADMINSRC user.

    You created this password when you configured the source Audit Vault Server for replication in the following step: Configure the Source Audit Vault Server for Replication.

    If the installation is successful, you should see the following message:

    AVS configured as destination for replication successfully.

    If you don't see this message, contact Oracle Support.

    Note:

    To see all available commands, run the following command:

    /usr/bin/python /var/lib/oracle/avs_goldengate/AVS_tar get_data_replication.py --help

  10. Mount the /var/lib/oracle/avs_goldengate/avs_goldengate_dep/var/lib/data directory to an NFS location with at least 500 GB of available free space.

    This is different from the NFS location that's mounted on the source Audit Vault Server.

    Run the following command:

    mount -t nfs <NFS_IP>:<export_path> /var/lib/oracle/avs_goldengate/avs_goldengate_dep/var/lib/data

    The exact mount command may vary.

    Make sure that the oracle user has read, write, and execute permissions for the directory that you created as the mount point.

    If you updated /etc/fstab to add the mount point, it reverts to the original state when the system is restarted.

  11. Mount the same NFS location that you mounted and used for archive logs on the source Audit Vault Server, with the exact same mount point path.

    This is the same NFS location that you set up in the following step: Create an NFS Location as an Archive Log Destination for the Source Audit Vault Server.

  12. As the oracle user, enter the following commands: 

    rman target /
    CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 5 TIMES to disk;

6.9.4 Create a Hot Backup of the Source Audit Vault Server

Perform a hot (or hot incremental) backup of the source Audit Vault Server to the Network File System (NFS) location that you configured earlier in this process.

Use the NFS location that you configured in the following step: Create an NFS Location as an Archive Log Destination for the Source Audit Vault Server.

The destination Audit Vault Server must be able to access this NFS backup location.

When performing the backup, set the REDUNDANCY to 2.

See Backup and Restore of Audit Vault Server for the full instructions.

Note:

For a high availability configuration, back up the primary Audit Vault Server and restore it to a standalone system.

6.9.5 Restore the Hot Backup to the Destination Audit Vault Server

Restore from the hot backup of the source Audit Vault Server to the destination Audit Vault Server.

Restore from the NFS location that you backed up to in the following step: Create a Hot Backup of the Source Audit Vault Server.

Set the USE_NEW_IP option to yes (USE_NEW_IP: Y).

See Restoring from Audit Vault Server Backup for instructions.

Note:

Don't perform the post-restore tasks after you complete the restore process.

6.9.6 Set the Archive Log Destination on the Destination Audit Vault Server

Before proceeding with the update to Oracle AVDF 20.9, set log_archive_dest_1 on the destination Audit Vault Server.

  1. Log in to the destination Audit Vault Server through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Switch to the oracle user.

    su - oracle

  3. Start SQL*Plus as sysdba. 

    sqlplus / as sysdba

  4. Enter the following command:

    alter system set log_archive_dest_1='LOCATION=+RECOVERY' scope=both;

  5. Exit SQL*Plus.

    exit

6.9.7 Update the Destination Audit Vault Server to the Latest Release

After you back up the source Audit Vault Server and restore it to the destination Audit Vault Server, you update the destination Audit Vault Server to the latest release (Oracle AVDF 20.9 or later).

See Patching Oracle Audit Vault and Database Firewall Release 20 for instructions.

6.9.8 (High Availability Only) Pair the Primary and Standby Audit Vault Servers

After the update is complete, pair the Audit Vault Servers for high availability.

Use the destination Audit Vault Server as the primary server and perform a fresh install of the latest version of Oracle AVDF on the standby Audit Vault Server.

For instructions, see Configuring High Availability for Audit Vault Servers.

Related Topics

6.9.9 Replicate the Data That Was Collected During the Update Process

After you've updated the destination Audit Vault Server to the latest release, you need to replicate the data that was collected on the source Audit Vault Server during the update process to the destination Audit Vault Server.

To replicate the data that was collected during the updated process, complete all the tasks under this section.

6.9.9.1 Start the Replication on the Destination Audit Vault Server

To start the replication script on the destination Audit Vault Server, provide the complete path to the backup directory on the destination Audit Vault Server. This is the same path that you specified when you restored the hot backup to the destination Audit Vault Server.

Note:

In a high availability environment, complete these steps on the primary Audit Vault Server.

Prerequisite

Ensure that the backup directory and the /var/lib/oracle/avs_goldengate/avs_goldengate_dep/var/lib/data directory are mounted on the destination Audit Vault Server. For details, see Configure the Source and Destination Audit Vault Servers.

Procedure

  1. Log in to the destination Audit Vault Server through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Switch to the oracle user.

    su - oracle

  3. Enter the following command:

    /usr/bin/python2 /var/lib/oracle/avs_goldengate/AVS_target_data_replication.py --start <backup_directory>

    Provide the complete path to the backup directory on the destination Audit Vault Server. This is the same path that you specified when backing up and restoring to the destination Audit Vault Server in the following steps: Create a Hot Backup of the Source Audit Vault Server and Restore the Hot Backup to the Destination Audit Vault Server.

  4. When prompted, enter the password for the AVS_GG_ADMIN user.

    This is the password that you created when you installed the patch in the destination Audit Vault Server in the following step: Configure the Destination Audit Vault Server for Replication.

6.9.9.2 Check the Replication Status on the Destination Audit Vault Server

To ensure that the replication is running, check the replication status on the destination Audit Vault Server.

Note:

In a high availability environment, complete these steps on the primary Audit Vault Server.

  1. Log in to the destination Audit Vault Server through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Switch to the oracle user.

    su - oracle

  3. Enter the following command:

    /usr/bin/python2 /var/lib/oracle/avs_goldengate/AVS_target_data_replication.py --check_replication_status

    The status should be Running for both extract and replicat. If it's not Running for both, contact Oracle Support.

6.9.9.3 Set Up the Purge Task on the Destination Audit Vault Server

While the replication is running, set up the purge task on the destination Audit Vault Server to automatically purge Oracle GoldenGate trail files that were created during replication.

Note:

In a high availability environment, complete these steps on the primary Audit Vault Server.

  1. Log in to the destination Audit Vault Server through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Switch to the oracle user.

    su - oracle

  3. Enter the following command:

    /usr/bin/python2 /var/lib/oracle/avs_goldengate/AVS_target_data_replication.py --setup_purge_task

  4. When prompted, enter the password for the AVS_GG_ADMIN user.

    You created this password when you configured the destination Audit Vault Server for replication in the following step: Configure the Destination Audit Vault Server for Replication.

6.9.9.4 Check the Replication Lag Time on the Destination Audit Vault Server

Before you stop monitoring points and audit trails on the source Audit Vault Server, ensure that the replication lag time on the destination server is less than 60 seconds.

Note:

In a high availability environment, complete these steps on the primary Audit Vault Server.

  1. Log in to the destination Audit Vault Server through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Switch to the oracle user.

    su - oracle

  3. Enter the following command:

    /usr/bin/python2 /var/lib/oracle/avs_goldengate/AVS_target_data_replication.py --check_replication_lag

    You should see output in the following format: 

    Processing Lag: <time> seconds
Extract lag: <time> seconds
Replicat lag: <time> seconds
6.9.9.5 Stop All Monitoring Points and Audit Trails on the Source Audit Vault Server

When all replication lag times are less than 60 seconds, stop all monitoring points and audit trails on the source Audit Vault Server.

To check the lag time, see Check the Replication Lag Time on the Destination Audit Vault Server.

To stop monitoring points, see Starting, Stopping, or Deleting Database Firewall Monitoring Points.

To stop audit trails, see Stopping, Starting, and Autostart of Audit Trails in the Audit Vault Server.

6.9.9.6 Stop the Replication on the Destination Audit Vault Server

When the replication lag is 0 seconds, stop the data replication on the the destination Audit Vault Server.

Note:

In a high availability environment, complete these steps on the primary Audit Vault Server.

To check the lag time, see Check the Replication Lag Time on the Destination Audit Vault Server. You should see the following results before proceeding: 

Processing Lag: 0 seconds
Extract records processed. No lag.
Replicat records processed. No lag.

To stop the replication:

  1. Log in to the destination Audit Vault Server through SSH and switch to the root user.

    See Logging In to Oracle AVDF Appliances Through SSH.

  2. Switch to the oracle user.

    su - oracle

  3. Enter the following command:

    /usr/bin/python2 /var/lib/oracle/avs_goldengate/AVS_target_data_replication.py --stop

  4. After stopping, enter the following command and ensure that the replication status is Stopped. 

    /usr/bin/python2 /var/lib/oracle/avs_goldengate/AVS_target_data_replication.py --check_replication_status

6.9.10 Update and Migrate All Monitoring and Collection to the Destination Audit Vault Server

After the data replication is complete, update and migrate all Database Firewalls and Audit Vault Agents to the destination Audit Vault Server.

Prerequisites

If the source Audit Vault Server release was 20.3, 20.4, 20.5, or 20.6, ensure that the patch for bug 34676006 has been applied on the source Audit Vault Server.

If the source Audit Vault Server release was 20.1 - 20.9 ensure that the patch for bug 35997720 has been applied on the destination Audit Vault Server.

Procedure

  1. Update and migrate Database Firewalls by completing the following steps for each firewall:

    1. Update the Database Firewall to the latest release.

      See Patching Oracle Audit Vault and Database Firewall Release 20.

    2. Reassociate the Database Firewall with the destination Audit Vault Server's IP address.

      See Specifying the Audit Vault Server Certificate and IP Address.

    3. Reset the Database Firewall from the destination Audit Vault Server.

      See Resetting Database Firewall.

    4. In the destination Audit Vault Server console, ensure that the version of the Database Firewall shows the updated release (20.9 or later).
  2. Update and migrate Audit Vault Agents and Host Monitor Agents by running the agent update script on the source Audit Vault Server.

    1. Log in to the source Audit Vault Server through SSH and switch to the root user.

      See Logging In to Oracle AVDF Appliances Through SSH.

    2. Switch to the oracle user.

      su - oracle

    3. Enter the following command:

      sh /var/lib/oracle/avs_source/send_agent_migration_signal.sh  -primary_avs <ip_of_destination_primary_or_standalone_AVS>  [-standby_avs <ip_of_destination_standby_AVS>] [-tcpport <tcp  port def 1521>] [-tcpsport <tcps port def 2484>]

    4. Verify that the agents are successfully updated.

      In the destination Audit Vault Server console, the agents should be in the RUNNING state. If they're not, contact Oracle Support.

Postrequisite

If the source Audit Vault Server release was 20.1 - 20.9 and patch 35997720 was applied, then remove the patch from the destination Audit Vault Server.

6.9.11 Start All Audit Trails on the Destination Audit Vault Server

After the Database Firewalls and Audit Vault Agents are updated and migrated to the destination Audit Vault Server, start all audit trails on the destination Audit Vault Server.

For instructions, see Stopping, Starting, and Autostart of Audit Trails in the Audit Vault Server.

It may take up to 20 minutes for the audit trails to start running.

At this point, all monitoring and connections should be from the destination Audit Vault Server. The source Audit Vault Server has old data and can be decommissioned.

6.9.12 Uninstall the Replication Patches from the Source and Destination Audit Vault Servers

When the update is complete and data has been replicated to the destination Audit Vault Server, you can uninstall the replication patches from the source and destination Audit Vault Servers.

  1. Uninstall the patch from the source Audit Vault Server.

    For the patch bug numbers for your release, see Patch Bug Numbers for the Source and Destination Audit Vault Servers.

    1. Log in to the source Audit Vault Server through SSH and switch to the root user.

      See Logging In to Oracle AVDF Appliances Through SSH.

    2. Switch to the oracle user.

      su - oracle

    3. Run the following command:

      /usr/bin/python /var/lib/oracle/avs_source/AVS_source_data_replication.py --unconfigure
  2. When prompted, enter the super administrator user name and password.

  3. As the root user, uninstall the RPM. 

    rpm -e $(rpm -qa | grep avs-source)

  4. Uninstall the patch from the destination Audit Vault Server.

    For the patch bug numbers for your release, see Patch Bug Numbers for the Source and Destination Audit Vault Servers.

    Note:

    In a high availability environment, complete these steps on the primary Audit Vault Server.

    Note:

    Before uninstalling the patch, ensure that the following command was run:

    /usr/bin/python2 /var/lib/oracle/avs_goldengate/AVS_target_data_replication.py --stop

    For details, see the following step: Stop the Replication on the Destination Audit Vault Server.

    1. Log in to the destination Audit Vault Server through SSH and switch to the root user.

      See Logging In to Oracle AVDF Appliances Through SSH.

    2. Unmount the file system.

      /bin/umount /var/lib/oracle/avs_goldengate/avs_goldengate_dep/var/lib/data

    3. Switch to the oracle user.

      su - oracle

    4. Run the following command:

      /usr/bin/python2 /var/lib/oracle/avs_goldengate/AVS_target_data_replication.py --remove_users_and_uninstall
    5. When prompted, enter the super administrator user name and password.

    6. As the root user, uninstall the RPM. 

      rpm -e $(rpm -qa | grep avs-destination)