Before you can use SnapValidator to protect the Oracle database, you must prepare the database for SnapValidator checks in a test environment to avoid disruptions to the production environment.
Steps
- Ensure that you are working in the test environment, not the production environment.
- Ensure that the Oracle data files or LUNs are in a single volume.
- Ensure that you do not put the following types of files in the same volume as the Oracle data:
- Oracle configuration files
- Files or LUNs that are not Oracle-owned (for example, scripts or text files)
- Oracle software
For an existing database, you might have to move configuration files and other non-Oracle data to another virtual volume.
- If you are using new LUNs for Oracle data and the LUN is accessed by non-Windows hosts, set the LUN Multiprotocol Type (ostype) to the appropriate host operating system (solaris, hpux, aix, linux, netware or vmware). If the LUNs are accessed by Windows hosts, the ostype must be windows or windows_gpt, depending on whether your version of Windows uses the GPT partition method. LUNs in an existing database can be used, regardless of their ostype.
For more information about LUN multiprotocol types, see the Data ONTAP Block Access Management Guide for iSCSI and FC.
- Ensure Oracle H.A.R.D. checks are enabled on the host running the Oracle application server (the db_block_checksum value in the init.ora file is set to true).
- Implement SnapValidator checks by licensing SnapValidator and then enabling it.
- Ensure you set SnapValidator to log all errors to the storage system consoles for all invalid operations by entering the following command: vol options volume-name svo_reject_errors off
- Test your environment by writing data to the storage system.
- Set SnapValidator to reject invalid operations and return an error to the host and log that error to the storage system consoles for all invalid operations by entering the following command: vol options volume-name svo_reject_errors on
- Put the database into production.
