R
Rob Fitzpatrick
Guest
> What would you do after threshold is increased? So transactions completes, no crash, use that value in the db start up param? So if same user scenario happens, you don't get the same warning/error? If I understand you correctly, you are concerned that if you increase the -bithold enough that this activity doesn't shut down the database then that will just mask the problem? The problem isn't the database shutdown (though of course it is problematic). The problem is the combination of user behaviour and application code that causes BI growth, and the shutdown is a symptom of that problem. If you monitor long-running transactions and alert when they happen, you won't miss these events and you should be able to retrieve some actionable information that tells you what to do next. I don't know if this is a vendor application or in-house, nor what is involved for you in making code changes. Maybe you can train users in what not to do, in the short term, until the code fix is available. > The BI would have reached a high water mark as well, would you change the structure? Add more extents? You could look at adding more BI extents. That could reduce the impact of BI growth, as your application freezes temporarily when a new BI cluster is formatted and inserted into the cluster ring. Having that happen within the fixed extents should be less time-consuming than also having to get more file space from the OS to grow the variable extent. But note that there is an impact to having a large BI file. For example it will make your online backups larger. Ultimately you need to fix the root cause to prevent the BI growth. Once you do that you can take a brief outage and truncate your BI file and then grow it back to whatever was its typical size before this issue hit you.
Continue reading...
Continue reading...