Category: Exadata

While working with an Oracle Database Appliance, an inconsistency arose between the management layer and the storage stack, leading to a disk reported as “FAILED” by odaadmcli. Further investigation revealed the disk was fully operational, with ASM actively using it. Troubleshooting involved validating multipath status, ASM state, and using the odaadmcli stordiag command. A file synchronization issue was discovered, which was resolved by restarting the OAK daemon, returning the disk to an “ONLINE” state.

The document details troubleshooting steps taken to resolve a grid release update(19.28) error on an Exadata Cloud system. The initial issue involved SSH connectivity, followed by problems with the Database Cloud Service (DBCS) agent. Key actions included checking SSH configurations, inspecting platform information, and managing package updates. Ultimately, updating the dbaascli tools resolved the precheck failures, simplifying the patching process.

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.