But there's nothing to stop you combing and consolidating lots of databases that are the same onto storage pools.
Welcome to The Register Debate in which we pitch our writers against each other on contentious topics in IT and enterprise tech, and you – the reader – decide the winning side. The format is simple: a motion is proposed, for and against arguments are published today, then another round of arguments on Wednesday, and a concluding …
As long as you know the performance characteristics won't be an issue. One database can cause performance problems for the entire pool. Should the sales guys and manufacturing floor grind to a halt because the accountants pushed through a buggy software change that will cause their database load to go crazy during their month end closing process?
Keeping things separate may be a little more wasteful of resources, but better isolates each from the problems of others.
I remember hearing that one Chinese bank (on a mainframe) had more people with current account than there are people in the US. There are many Chinese banks,so trying to put all of the Chinese into one big database, providing sub second response, HA, disaster recovery would be a challenge.
Now scale this up to have one database for world's population.
Operation capability is one thing, but then there is the backup question. When, what kind, and how much.
Sure they all worked fine when on separate storage, but then it got pooled and many of those databases trying to do full backups at various times over the weekend now saturate this pooled storage I/O, so they take longer. Which causes backup windows to run into other windows. And then you have a total FUBAR situation.
Be careful out there...
it's highly important that Storage admins have good understanding about their application architectures & behaviour, especially the I/O patterns, heavy jobs timings, backup schedules, etc. Storage management in today's era is no more just provisioning capacity, but requires continuous monitoring, analysis drilling down to the virtual disk/LUN/Pool and FE/BE supporting components. However, consolidation avoids wasting resources by pooling together. Right-sizing workloads combined with varying SLAs & QoS is the way to go, by using modern Arrays with powerful features. And trust me, TCO will be much lower than having siloed storages, if done properly.
Biting the hand that feeds IT © 1998–2020