Progress 11.2.1 (although it'll be 11.5 by the time this matters)
We've got 3 fixed and one variable BI extents, and all variable on the AI extents. If -aistall and -bistall are used will it stop the database crashing if the AI/BI drives run out of disk space? Or does it just work if the extents are full?
Progress 11.2.1 (although it'll be 11.5 by the time this matters)
We've got 3 fixed and one variable BI extents, and all variable on the AI extents. If -aistall and -bistall are used will it stop the database crashing if the AI/BI drives run out of disk space? Or does it just work if the extents are full?
Flag this post as spam/abuse.
Even if the AI/BI are on a different volume? So what if I size my AI/BI extents to take up the available disk space?
Even if the AI/BI are on a different volume? So what if I size my AI/BI extents to take up the available disk space?
Flag this post as spam/abuse.
The reason I ask is because on our new server the systems guys who have set it up have severely limited the volumes that the AI and BI files will be stored on in terms of disk space. If we have something happen (like recently where I compressed all the BLOBs) that pushes a load of info in the AIs we will likely end up with the DB falling over. They don't seem to understand this and I'm struggling to convince them to increase the available space.
Apparently space is at a premium on the SAN. Why on earth it's going on the SAN anyway I don't know.
SANs exist to make life easy for "storage engineers". They are never,
ever, a good thing for DBAs.
They are probably lying to you about what sort of RAID it is too.
You need to provision storage for your worst case.
If you have no better numbers to predict from you've got an example from
your BLOB problem so take that, multiply by X (where X is at least 2)
and tack on a zero. Then create fixed length bi and ai extents to meet
that need.
Or, the classic method when you have to guess and the cost of being
wrong is high (i.e. "system will crash") is to take what you think is
likely, double it and use the next highest unit. Thus if you think 1GB
is your likely need ask for 2TB.
Yes, I know that I am usually a variable length ai kind of guy -- but
when you have to deal with intransigent SAN admins you sometimes have to
do things a bit differently.
Alternatively you could make sure that these guys get all of the phone
calls whenever something needs to grow.
Step 1: Slap the server guys
If you have limited space on the AI/BI volumes you are likely to have limited performance as well.
But I generally prefer to have fixed AI extents and more than you would reasonably need. Then make sure they are getting emptied/archived on a frequent basis. Usually I extract/release all AI files every 5 minutes or so.
Thanks Tom. I've been through all of this. By the way the new machine has been provisioned with 2 cores. For 250 odd concurrent users. And AppServers.
Reply by James PalmerThanks Tom. I've been through all of this. By the way the new machine has been provisioned with 2 cores. For 250 odd concurrent users. And AppServers.
Stop receiving emails on this subject.Flag this post as spam/abuse.
Not yet. Haven't installed Progress on it yet due to a lack of space on the c:\ drive meaning we'll blow that as soon as I install anything. Absolute shambles!
Quick follow-up to the fixed AI extent issue. Am I right in thinking that the archiver will only archive fixed extents once they are full? I've currently sized my AI extents at 512MB so that 72 of them fill up around 35GB. Then switched on aistall. But if they only archive once full, would I be better off with more, but smaller extents so that fill more quickly?
That depends, if the AI archiver is configured as On Demand (interval = 0) then you're right. If you're using an interval of for example 600 (10 minutes) it will switch every 10 minutes and save only the filled data of the 'old' full extent. So if only 218MB is used in your fixed extent after 10 minutes, the AI archiver will save that 218MB and make the extent empty.
Thanks for that. Strange then that we're not getting Archive files... Will have to work that out. :)
If you use fixed extents (which I don't advocate) then use -aiarcinterval. That way both time and full AI extents will trigger a switch.
If you're not getting AI archives check that the aimgt is running and has a valid aiarcdir. The db.lg will confirm this. Also check for the existence of db.archival.log.
Bounced the DB and I'm getting the archives now as expected.
Unfortunately I don't have much choice in the fixed extent malarky Paul, unless you can come up with another solution. Our systems guys have given us a 50GB volume for the AI files. We've been known to top 200GB in there very quickly on very rare occasions, but it happens. So I see the only solution as fixed extents and aistall so that the DB won't die if we run out of space.
From the business' POV, an aistall will not be viewed much more favourably then a crash. It will take you at least 15 minutes to get alerted and to respond effectively.
I do have a solution: you go up the org chart and tell someone intelligent that the BUSINESS is risking a shutdown because the SAN admin wants to save a thousand pounds. I find that when I write emails clearly and objectively, explaining the clear ROI (shutdown vs. £1000) things often get resolved. If you have documented proof that you have blown 50Gb of AI x times in the past y months, it makes your argument near irrefutable. And if not, at least your conscience is clear.
Thanks Paul. These emails have been sent and ignored. Therefore I need to put into place what I can to mitigate for the poor decisions made for me. The email trail is all nicely archived away and ready to wheel out when things go wrong. In the meantime I have to try and do what I can.