R
Rob Fitzpatrick
Guest
First, with an Enterprise license you should have large file support enabled; I'll assume that's true. Otherwise the variable extent can't grow beyond 2 GB. > With the BI variable extent, I thought that should have handled the bi growing. So I'm thinking of increasing the threshold, but at what value? The variable extent will allow the BI area to grow, but not much in your case. You have two 1 GB fixed extents and a 2.4 GB BI threshold. Therefore the variable can only grow to 400 MB before forward processing stops. Because you are not using -bistall, that stop means a database shutdown. If you did specify -bistall, that would give you an opportunity to increase the threshold online at the time when you stall, so you can collect valuable information in promon about what is happening. If you shut down, that opportunity is lost. > The parameters have been there for years, we'll most likely hit this scenario again. Does this type of shutdown happen often? If you want a different result in this situation, you should change your BI configuration. I suggest you increase your -bithold so your variable extent can grow larger. The value that is appropriate for you depends on your available space. Ensure that the BI file system has plenty of free space and is not likely to be filled with other data (e.g. other DBs' BI extents, application or DB logs, client temp files, etc.). Don't use more than a quarter of the available space. It is important to monitor not just the BI usage and size but also what is happening with clients. BI growth will be cause by a combination of (a) one or more users with long-running transactions in ACTIVE status and (b) all users' transaction activity, i.e. the amount of BI notes that are written while those long-running transaction are active. Use promon (R&D 1, 4, 3) or ProTop and closely monitor long-running transactions. Ideally database transactions should last a few seconds or less, so if you see them get into the range of five to ten minutes then you should be prepared to take action. Likely the root cause of the BI growth is an application issue. You can use proGetStack on the client side or Client Database Request Statement Caching (in promon or ProTop) on the server side to determine what code the client in the long transaction is running. Alternatively, if it's a human user you can just ask them or look over their shoulder. 
Once you determine what the offending code is, have the user exit out of what they are doing. If that is not possible, you will want to disconnect the user. That's not a problem if the user is remote, but be aware that there is a chance that disconnecting a shared-memory 4GL client could cause a database shutdown if that user dies while holding a latch.
Continue reading...
Once you determine what the offending code is, have the user exit out of what they are doing. If that is not possible, you will want to disconnect the user. That's not a problem if the user is remote, but be aware that there is a chance that disconnecting a shared-memory 4GL client could cause a database shutdown if that user dies while holding a latch.Continue reading...