S
shaske1
Guest
A recent corruption incident made us realize that we could be in the position where we would need to deactivate the only index on a table in order to prevent access to the corrupt block (and subsequent database crash). This is especially needed for 24/7 (or near 24/7) operations when it is not feasible to build the new index for a very large table during the day. Alternatively there might be the option of allowing online idxfix to "mark unreadable" a corrupt block until the index can be repaired/replaced. (Current version of idxfix crashed the database when attempting to fix; we presumed backups, dbanalys, etc. would also crash the DB in the event.) PSC may not find this desirable since it may tend to complicate low-level OS block processing, but this could be a preferred workaround option. We assume the direct, online manipulation of the block (a online dbrpr block load) would not be the preferred solution. That also seems like a theoretical alternative, though the usefulness tends to hinge on the response time of Progress support to provide a file with the contents of the fixed block. Note also: idxactivate uses existing indexes and idxbuild would require both database downtime and replication rebuild, neither of which are desired. (Replication failover might be required, though for complex systems [dozens of hosts, services, and dependencies] that may require more time than is available. In this case failover is to be avoided whenever possible due to additional failure possibilities. That may include very limited DB corruption.)
Continue reading...
Continue reading...