Requires Free Membership to View
It's also difficult to comment on corruption/consistency risks because I am not sure whether you are consolidating five images of the same database used by five different client groups, whether these databases had a relationship via some sort of replication, or whether they were five nodes within a RAC cluster. Regardless of which of these three configurations you are coming from, this concern is mitigated at the planning stage. Do I have the same unique identifier for different data in more than one database? Do I have different identifiers for the same data in multiple databases? Is the field mapping the same in every database (i.e., Does each field mean the same thing to each client base?)
But I can say that if you operate with one server without any sort of second node either as a standby or clustered instance you are at a severe risk of unavailability. Recovery can still be managed but with what are often considered unacceptable outages. Redundancy is the key to availability. Your nodes, your storage, your network, everything should be redundant if you have high availability requirements (which is nearly everyone these days).
So yes, if you mean that you are using one box for everything your availability is jeopardized, your performance could suffer without scaling your hardware, your backups will take longer, you will have loss of service during patches and recovery operations and depending on how you were configured prior you could be looking at a data conversion headache. Sorry I can't be more specific but it's hard to say without knowing your details.
This was first published in October 2006
Join the conversationComment
Share
Comments
Results
Contribute to the conversation