Using SnapValidator

What SnapValidator does

Oracle Hardware Assistant Resilient Data (H.A.R.D.) is a system of checks embedded in Oracle data blocks that enable a storage system to validate write operations to an Oracle database. The SnapValidator^TM software implements Oracle H.A.R.D. checks to detect and reject invalid Oracle data before it is written to the storage system.

Note
SnapValidator is not based on Snapshot technology.

H.A.R.D. checks that SnapValidator implements

SnapValidator implements the following Oracle H.A.R.D validations:

Checks for writes of corrupted datafile blocks. This includes the checksum value and validation of selected fields in the block.
Checks for writes of corrupted redo log blocks. This includes the checksum value and validation of selected fields in the block.
Checks for writes of corrupted controlfile blocks. This includes the checksum value and validation of selected fields in the block.
Verifies that writes of Oracle data are multiples of a valid Oracle blocksize for the target device.

When to use SnapValidator

You use SnapValidator if you have existing Oracle database files or LUNs on a storage system or if you want to store a new Oracle database on the storage system.

Supported protocols

SnapValidator checks are supported for the following protocols:

LUNs accessed by FCP or iSCSI protocols
Files accessed by NFS

Guidelines for preparing a database for SnapValidator

You prepare database files or LUNs for SnapValidator checks by using the following guidelines.

Make sure you are working in your test environment, not your production environment.
Make sure the Oracle data files or LUNs are in a single volume.
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)
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 Operating System type (ostype) to image. If the LUNs are accessed by Windows hosts, the ostype must be windows. LUNs in an existing database can be used, regardless of their ostype. For more information about LUN Operating System types, see Creating LUNs, igroups, and LUN maps.
Make sure Oracle H.A.R.D. checks are enabled on the host running the Oracle application server. You enable H.A.R.D. checks by setting the db_block_checksum value in the init.ora file to true.
Example: db_block_checksum=true
License SnapValidator. For more information, see Licensing SnapValidator.
Enable SnapValidator checks on your volumes. For more information, see Enabling SnapValidator checks on volumes.
Make sure 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 your database into production.

Tasks for implementing SnapValidator checks

After you prepare the database, you implement SnapValidator checks by completing the following tasks on the storage system:

License SnapValidator.
For detailed information, see Licensing SnapValidator.
Enable SnapValidator checks on the volume that contains the Oracle data.
For detailed information, see Enabling SnapValidator checks on volumes.
If you are using LUNs for Oracle data, configure the disk offset for each LUN in the volume to enable SnapValidator checks on those LUNs.
For detailed information, see Enabling SnapValidator checks on LUNs.

Licensing SnapValidator

To license SnapValidator complete the following steps.

Step	Action
1	Verify whether SnapValidator is licensed by entering the following command: license Result A list of all available services appears. Services that are enabled show the license code. Services that are not enabled are indicated as "not licensed." For example, the following line indicates that SnapValidator is not licensed. snapvalidator not licensed
2	If SnapValidator is...	Then...
	Licensed	Proceed to Enabling SnapValidator checks on volumes.
	Not licensed	Enter the following command: `license add` license_code license_code is the license code you received when you purchased the SnapValidator license.

Enabling SnapValidator checks on volumes

You enable SnapValidator checks at the volume level. To enable SnapValidator checks on a volume, complete the following steps.

Note
You cannot enable SnapValidator on the root volume.

Step	Action
1	On the storage system command line, enable SnapValidator by entering the following command: *vol options volume-name* svo_enable on** Result All SnapValidator checks are enabled on the volume, with the exception of checksums.
2	If you want to...	Then enter the following command:
	Enable data checksumming on the volume	*vol options volume-name* svo_checksum on**
	Disable block number checks because the volume contains Oracle Recovery Manager (RMAN) backup data.	*vol options volume-name* svo_allow_rman on**
	Set SnapValidator to return an error log to the host and storage system consoles for all invalid operations. You might want to do this when you are testing SnapValidator before you put your database into production.	*vol options volume-name* svo_reject_errors off** When you set this option to Off, SnapValidator only logs errors but does not reject invalid operations.
	Set SnapValidator to reject all invalid operations and return an error log to the host and storage system consoles.	*vol options volume-name* svo_reject_errors on** If this option is not set to On, then SnapValidator detects invalid operations but only logs them as errors. The following shows a SnapValidator error example displayed on the storage system console: Thu May 20 08:57:08 GMT [filer_1: wafl.svo.checkFailed:error]: SnapValidator: Validation error Bad Block Number:: v:9r2 vol:flextest inode:98 length:512 Offset: 1298432
3	If the volume contains LUNs, proceed to Enabling SnapValidator checks on LUNs in the next section.

Enabling SnapValidator checks on LUNs

If you enable SnapValidator on volumes that contain database LUNs, you must also enable SnapValidator checks on the LUNs by defining the offset to the Oracle data on each LUN. The offset separates the Oracle data portion of the LUN from the host volume manager's disk label or partition information. The value for the offset depends on the operating system (OS) of the host accessing the data on the LUN. By defining the offset for each LUN, you ensure that SnapValidator does not check write operations to the disk label or partition areas as if they were Oracle write operations.

To define the offset, you must first identify the offset on your host and then define that offset to the storage system. The method you use to identify the offset depends on your host. For details see:

Identifying the disk offset for Solaris hosts

To identify the disk offset for Solaris hosts, complete the following steps.

Step	Action
1	On the host, enter the following command: prtvtoc /dev/rdsk/device_name Result The host console displays a partition map for the disk. Example The following output example shows the partition map for disk c3t9d1s2: prtvtoc /dev/rdsk/c3t9d1s2 * /dev/rdsk/c3t9d1s2 partition map * * Dimensions: * 512 bytes/sector * 384 sectors/track * 16 tracks/cylinder * 6144 sectors/cylinder * 5462 cylinders * 5460 accessible cylinders * * Flags: * 1: unmountable * 10: read-only * * First Sector Last * Partition Tag Flags Sector Count Sector Mount Directory 0 0 00 0 6144 6143 2 5 01 0 33546240 33546239 6 0 00 6144 33540096 33546239
2	Obtain the offset value by multiplying the value of the first sector of the partition you are using by the bytes/sector value listed under Dimensions. In the example shown in Step 1, which is using slice 6, the disk offset is 6144 * 512 = 3145728.

Step

Action

On the host, enter the following command:

prtvtoc /dev/rdsk/device_name

Result

The host console displays a partition map for the disk.

Example

The following output example shows the partition map for disk c3t9d1s2:

prtvtoc /dev/rdsk/c3t9d1s2

* /dev/rdsk/c3t9d1s2 partition map

* Dimensions:

*     512 bytes/sector

*     384 sectors/track

*      16 tracks/cylinder

*    6144 sectors/cylinder

*    5462 cylinders

*    5460 accessible cylinders

* Flags:

*   1: unmountable

*  10: read-only

*                          First     Sector    Last

* Partition  Tag  Flags    Sector     Count    Sector  Mount Directory

       0      0    00          0      6144      6143

       2      5    01          0  33546240  33546239

       6      0    00       6144  33540096  33546239

Obtain the offset value by multiplying the value of the first sector of the partition you are using by the bytes/sector value listed under Dimensions.

In the example shown in Step 1, which is using slice 6, the disk offset is 6144 * 512 = 3145728.

Identifying the disk offset for other hosts

To identify the disk offset for non-Solaris hosts, complete the following steps.

Step	Action
1	Prepare the LUN for storing Oracle data, for example, by setting up raw volumes.
2	On the host console, enter the following command: *dd if=/dev/zero of=/dev/path_to_storage* bs=4096 count=1 conv=notrunc** path_to_storage is the path to the LUN on the host. Result The host writes an Oracle 4K block of zeros to the storage system.
3	Check the SnapValidator error message displayed on the storage system console. The error message displays the offset. Example The following error message example shows that the disk offset is 1,048,576 bytes. filerA> Thu Mar 10 16:26:01 EST [filerA:wafl.svo.checkFailed:error]: SnapValidator: Validation error Zero Data:: v:9r2 vol:test inode:3184174 length:4096 Offset: 1048576

Step

Action

Prepare the LUN for storing Oracle data, for example, by setting up raw volumes.

On the host console, enter the following command:

dd if=/dev/zero of=/dev/path_to_storage bs=4096 count=1 
conv=notrunc

path_to_storage is the path to the LUN on the host.

Result

The host writes an Oracle 4K block of zeros to the storage system.

Check the SnapValidator error message displayed on the storage system console. The error message displays the offset.

Example

The following error message example shows that the disk offset is 1,048,576 bytes.

filerA> Thu Mar 10 16:26:01 EST 
[filerA:wafl.svo.checkFailed:error]: SnapValidator: 
Validation error Zero Data:: v:9r2 vol:test inode:3184174 
length:4096 Offset: 1048576

Defining the disk offset on the storage system

To define the disk offset on the storage system, complete the following step.

Step	Action
1	Use the volume manager tools for your host OS to obtain the value of the offset. For detailed information about obtaining the offset, see the vendor-supplied documentation for your volume manager.
2	On the storage system command line, enter the following command: lun set svo_offset lun_path offset offset is specified in bytes, with an optional multiplier suffix: `c` (1), `w` (2), `b` (512), `k` (1,024), `m` (kk), `g` (km), `t` (m*m).

Step

Action

Use the volume manager tools for your host OS to obtain the value of the offset. For detailed information about obtaining the offset, see the vendor-supplied documentation for your volume manager.

On the storage system command line, enter the following command:

lun set svo_offset lun_path offset

offset is specified in bytes, with an optional multiplier suffix: c (1), w (2), b (512), k (1,024), m (k*k), g (k*m), t (m*m).

Disabling SnapValidator on a volume

To disable SnapValidator, complete the following steps.

Step	Action
1	On the storage system command line, enter the following command: vol options volume-name svo_enable off Result SnapValidator does not check Oracle write operations to files or LUNs. The settings for each type of check (for example, checksumming) are not disabled. If you re-enable SnapValidator, the settings for each type of check are saved.
2	To disable a specific SnapValidator option, enter the following command: vol options volume-name option off option is one of the following: svo_checksum--disables data checksumming on the volume. svo_allow_rman--allows block number checks on the volume. You disable this option (set it to Off) if the volume does not contain RMAN data. svo_reject_errors--detects invalid operations but does not reject them. Invalid operations are only logged as errors.

Step

Action

On the storage system command line, enter the following command:

vol options volume-name svo_enable off

Result

SnapValidator does not check Oracle write operations to files or LUNs. The settings for each type of check (for example, checksumming) are not disabled. If you re-enable SnapValidator, the settings for each type of check are saved.

To disable a specific SnapValidator option, enter the following command:

vol options volume-name option off

option is one of the following:

svo_checksum--disables data checksumming on the volume.
svo_allow_rman--allows block number checks on the volume. You disable this option (set it to Off) if the volume does not contain RMAN data.
svo_reject_errors--detects invalid operations but does not reject them. Invalid operations are only logged as errors.

Disabling SnapValidator checks on a LUN

To disable SnapValidator checks on a LUN, complete the following step.

Step	Action
1	On the storage system command line, enter the following command: *lun set lun_path* svo_offset disable**

How SnapValidator checks are set for upgrades and reverts

When you upgrade to Data ONTAP 7.0 from a previous release, all SnapValidator options on all volumes are disabled. The offset attribute (the svo_offset option) for LUNs is also disabled.

When you revert to a previous version of Data ONTAP, all SnapValidator options on all volumes are disabled. The value for the LUN offset is retained, but the earlier version of Data ONTAP does not apply it.

SnapValidator error messages

When write operations to LUNs fail

SnapValidator displays two messages similar to the following when write operations to a LUN fail.

The first message is generated by SnapValidator and indicates that the storage system detected invalid data. The error message does not show the full path to the LUN. The following is an example error message:
```
Thu May 20 08:57:08 GMT [fas940: wafl.svo.checkFailed:error]: 
SnapValidator: Validation error Bad Block Number:: v:9r2 
vol:dbtest inode:98 length:512 Offset: 1298432
```
The second error message is a scsitarget.write error, which shows the full path to the LUN. The following is an example error message that indicates a write to a specific LUN failed.
```
Thu May 20 14:19:00 GMT [fas940: 
scsitarget.write.failure:error]: Write to LUN 
/vol/dbtest/oracle_lun1 failed (5)
```

If you receive a message indicating that a write operation to a LUN failed, verify that you set the correct disk offset on the LUN. Identify the disk offset and reset the offset defined for the LUN by using the procedures described in Enabling SnapValidator checks on LUNs.

Other invalid data error messages

The following messages indicate that SnapValidator detected invalid data:

Checksum Error
Bad Block Number
Bad Magic Number
No Valid Block Size
Invalid Length for Log Write
Zero Data
Ones Data
Write length is not aligned to a valid block size
Write offset is not aligned to a valid block size

If you receive a message indicating that SnapValidator detected or rejected invalid data, verify the following:

You enabled the SnapValidator checks on the volumes that contain your data files. For more information, see Enabling SnapValidator checks on volumes.

You set the SnapValidator checks correctly. For example, if you set the svo_allow_rman volume option to on, then make sure that the volume contains Oracle Recovery Manager (RMAN) backup data. If you store RMAN data in a volume that does not have this option set, then you might receive an error message indicating that SnapValidator detected invalid data.

If the SnapValidator options on the storage system are correctly set but you still receive the above errors, you might have the following problems:

Your host is writing invalid data to the storage system. Consult your database administrator to check Oracle configuration on the host.
You might have a problem with network connectivity or configuration. Consult your system administrator to check the network path between your host and storage system.