What are the characteristics of an ideal 24/7 running database server?
Some of the characteristics may be more pertinent than others for your organization. Due to this reason, I am providing the following features of a 24/7 running database server.
The system should accommodate a variety of system and database failures. All single points of failure should be identified, and adequate redundancy should be provided to each such component.
The system should provide as much failover transparency as possible when the primary system crashes, restricting major service disruptions. Note that smooth failover depends on the time taken to detect the failure of the primary database server and act accordingly. It may require periodic polling to determine the stability of the primary system. Setting the poll to occur too frequently may hamper overall system performance, whereas making it occur less often than required may result in service disruption not being detected till the poll occurs again, potentially causing the disruption to be visible to the end-users. Additionally, once the failure is detected, the failover strategy should be robust enough to reroute new database connections, as well as divert (reconnect) existing connections. Keep in mind that existing connections can be a real challenge. The 24/7 solution must enforce having restart ability features built into applications (that initiated the active connections). In case that is not possible, then the solution must provide a wrapper around application-connections to restart as and when necessary, minimizing duplication of work and reissuing the call to the failover instance. A brief service disruption may be evident to users at certain times, as their active connections are broken.
The 24/7 should preserve data integrity. There shouldn’t be any data loss or violation of inherent data relationships. For instance, while propagating all writes from the primary database to the secondary one, no data loss should be allowed to creep in.
The cost of engineering the system, and the system itself, ought to be less than the revenue/productivity loss in not attaining 24/7 uptime. The cost of 24×7 systems may be higher in the short run. However, such high costs may be mitigated over a period of time, since they represent capital expenditure. It is necessary to consider this fact when comparing the loss from potential downtime with the 24×7 system cost. Always consider system failure during peak hours when computing revenue loss. Doing so allows you to evaluate worst-case scenarios and chances are system failure may occur during peak hours or may occurring non-peak hours but creep into the peak hours time frame if timely recovery is not possible.
Optimal Resource Usage:
The 24/7 database server should attempt to use system resources as optimally as possible, without reaching the system saturation point, especially during peak hours.
Migration to the 24×7 database server should be relatively uncomplicated, with downtime and service disruption being within an acceptable range. Of course, this range needs to be determined as part of the analysis, prior to crafting the solution. Changes to related components like applications, security policies, etc should be feasible.
Existing in-house personnel should be able to maintain the new 24/7 running database server without having to resort to infeasible means it needed frequent off-site training, complex tools or regular visits by expert consulting staff.
On a regular day-to-day basis, the new database server should not impede performance. Note that a certain level of impact may be unavoidable. For instance, if the 24/7 solution requires all application writes to be split across multiple databases including one of the remote sites, the network latency may affect the speed of every writer. However, it has to be ensured that such an impact is within an acceptable range.
Your actual solution may not be able to successfully cater to all these goals. However, the idea is to accommodate as many goals as possible, starting with the ones most important to your organization.
When you want to make a strong Oracle DBA career then you should be aware of database services and other database technology. Without having knowledge of Oracle internals, Oracle performance tuning, and skill of Oracle database troubleshooting you can’t be an Oracle DBA expert. This expert DBA Team club blog always provides you latest technology news and database news to keep yourself up to date. You should need to be aware of Cloud database technology like DBaaS. These all Oracle DBA tips are available in a single unique resource at our orageek. Meanwhile, we are also providing some sql tutorials for Oracle DBA. This is the part of Dbametrix Group and you would enjoy more advanced topics from our partner resource.
Consider Reading these articles:
Transparent Application Failover-Oracle RAC
Security-related Issues in Cloud Computing