Additionally, many companies suffered from periodic, but relatively unpredictable, bloats in active database sizes. In every environment with active database development, the databases occasionally bloated due to coding errors. Except in one case, all of these errors did not fit a predictable pattern. However, they did have a predictable bloat effect: over 50 percent growth in less than 24 hours. In about half of the cases, the database was not restored to its original, non-bloated state.
Estimation equations
Where does this idea lead us, other than to say you need at least a decade of historical data to correctly estimate your needs based on cycles rather than aggregate data? What if we don't have access to such information or don't have the time to build it?
Fortunately, a few rules of thumb emerge from the data I have in front of me: quadruple each development channel, triple each mail system, and assume that all non-IT databases will bloat at a rate of 100 percent per year, whether they do or not. Non-database storage tends not to spike unless and until an acquisition (either a purchase or being purchased) at which time it will either plummet as executives purge files or explode as people create documentation.
The real key lies in managing the growth of the development channels. Depending on your company's development methodology and archive requirements, you could end up managing six versions of your live data (development, QA, and live for two simultaneous systems) for anywhere between one and three years. Each channel requires at least twice its current size in storage capacity; it will be more comfortable running at around 25 percent maximum utilisation in case you need to perform rapid copies or restores.
In most shops, the rest of the storage (e.g., email, smaller databases and files) present us with far less trouble. Email grows relatively predictably; files do the same. The smaller databases making up the shadow ERP generally try to stay under the IT manager's radar, so you can count on the "developers" to control them. If they don't, a little friendly reminder to run the appropriate database control tools can earn the IT team a bit of extra political capital for use in another situation.
Working the punctuations into the plan
The good thing about regular punctuations is that you do not need to address them immediately. Once you have a grip on when they will occur, you can build their needs into an extended two-to-four-year expansion plan rather than making sudden purchases. When doing a consolidation, build the extra capacity into next year's budget -- this defers the cost while showing the decision makers that you have a clear plan for the future.
If you have recently installed new archive/back-up/storage solutions, going back and looking for the punctuations gives you valuable insight into the future. When the inevitable "sudden" demand comes in for new storage, you can coolly lay out your plan to meet the need using existing or readily available resources. This saves you headaches and allows you to continue your move from reactive to proactive infrastructure management.
