Category: Exadata

The recent analysis of an Exachk report revealed a new check for Hardware Assisted Resilient Data (HARD) capability during the ASM Relocation (rebalance, resync, or resilver) process. HARD checks validate data integrity in Exadata storage servers, preventing corruption. Setting the content.check attribute of asm diskgroup to TRUE will enable Hardware Assisted Resilient Data (HARD) Validation During ASM Relocation. This change aligns with Exadata best practices for improved data protection.

This post outlines the steps to configure Cisco Management Network Switches with multiple uplinks for redundancy in Oracle Exadata environments. It emphasizes the importance of the Administration Network, which connects all Exadata components for management purposes. Detailed steps are provided for configuring a Cisco 9348 Ethernet Switch, including LACP setup for uplink ports and validating spanning tree settings to ensure stable and reliable connectivity

A file system corruption issue was detected on the root partition of an Exadata storage server running Oracle Linux 7.9. This was identified by AIDE due to changes in file attributes. Investigations revealed errors in the logs pointing to inode inconsistencies. Attempts to resolve the corruption faced obstacles due to the unavailability of diagnostic ISO images. Ultimately, the file system corruption was fixed by using an Oracle Linux 7.9 installation ISO and running fsck manually.

The post describes a recovery process after a Mirrored Disk Failure in Normal Redundancy Mode, causing CRS downtime. The team restored OCR config, changed VOTING disk location, and employed Oracle support documentation for ASM-based OCR restoration. The process involved reconfiguring and relocating files and resolving issues with missing disks, leading to successful recovery.

The DR site faced dual disk failure, causing database and cluster failures. ASM issue triggered rebalancing, leading to additional disk failures. Recovery attempts failed, resulting in loss of standby databases and DATA disk group.

On a typically busy Monday at the office, a storage server experienced multiple disk failures, causing a reboot and loss of grid disks. Investigation revealed cacheContentLost status due to a flashdisk failure and import failure. The team resolved the issue by recreating the grid disks and replacing the faulty disks. To prevent future occurrences, they updated the Exadata server image. The problem has not recurred since.