- Log in to post comments
Senior Software Engineer | 10+ Years Specialized in InterSystems Technology and Product Stack
Dedicated to building high-performance, scalable solutions within the InterSystems ecosystem. Over a decade of experience architecting complex integrations and data-driven applications. Passionate about optimizing system performance and mentoring the next generation of InterSystems developers.
I agree, and I thought the same approach. However, my concern is more about %ValidateIndices() itself in InterSystems IRIS.
For large tables with heavily corrupted indexes, the bottleneck is not necessarily retaining tErrors after execution, but the fact that %ValidateIndices() builds large local arrays internally. If a single index contains a large number of corrupt entries, the process could still hit excessive memory usage or before control even returns to the caller.
The main point here is that the requirement is only to identify the corrupted index name, not to collect every corrupted entry into tErrors.
Currently there’s no lightweight mode to:
- stop after first/significant corruption
- or simply return whether an index is corrupted
without materializing all failed entries into local arrays.
- Log in to post comments
Thanks @Vishal Pallerla
- Log in to post comments
Hi @Sean McKenna Even though my user has been granted the
%DB_NAMESPACE(%DB_HIB) role and##class(SYS.Monitor.SAM.Config).AddApplicationClass()successfully returns1, I am still encountering a error and cannot view the metrics.