A database failure is a nightmare for CTOs and IT Managers, and no matter how reliable your system or how meticulous your DBA, a failure is still possible. Before you can begin to prepare for these problems, you need to understand what sort of risks you’re facing and how different kinds of failure can affect you. Speaking broadly, there are two types of database failure: one is downtime – the time during which your clients cannot use your service – and the other is the loss of data, where the valuable information stored on your servers is lost, potentially causing both financial and legal repercussions.
So what are the consequences of these kinds of database failure, and why are CTOs and IT Managers so worried about them?
Downtime refers to a period in which a business’s services are unavailable due to system failure. The glaring problem with downtime is that, without a service to offer, a business will lose income. The ramifications of downtime vary from industry to industry, but there are two things that are always constant: it is costly to businesses and frustrating to clients. Just look at some of the recent instances to affect airlines in the last year: Southwest Airlines had a computer failure that caused massive delays and affected their website customer service and British Airways had a worldwide IT failure (which they blamed on a power surge, but data centre experts claim that is unlikely to be the cause).
Airlines aren’t alone, however. In May 2016, Salesforce’s systems went down due to a database error, estimated to have cost the company $20 million. Downtime not only costs money but also a business’s reputation and customer loyalty. That’s a lot of repercussions for a database disruption.
Understanding how much (hypothetical) downtime will cost your business is important for analysing the risk. We recommend calculating how much money per hour your business would lose in the event of a database failure. Remember, this isn’t just a case of working out the loss of income – although that is a part of it, which can be calculated by dividing your weekly income by 40 hours and then estimating what percentage of that revenue is dependent on database uptime – you also need to consider the cost of lost productivity while the problem is fixed, the cost to recover the database, and the reputational cost. It’s not just your money at stake, but your customers too.
Ultimately, downtime can be very damaging to businesses. If you’re a CTO or IT Manager, you need to make sure your DBA has a contingency plan in case of downtime and some accurate monitoring software to help prevent it happening in the first place. Alternatively, work with a remote DBA for the assurance that there is a plan in place and problems will always be resolved as soon as possible (or avoided in the first place).
The National Archives and Records Administration (NARA) once managed to misplace a hard drive containing private information on American citizens, Clinton administration records, and Secret Service and White House operating procedures. Perhaps even more concerning was when Amazon managed to permanently destroy some of its client’s data. If the US government and even Amazon are susceptible to data loss, then it’s clearly something that needs proactive attention.
CTOs and IT Managers can be on the ball 24/7, but still miss essential factors that can cause catastrophic failures. That’s what happened to Microsoft when they acquired Danger, the original producer of T-Mobile’s smartphone, Sidekick. This also meant they took over Danger’s data centre. The following year, users of Sidekick experienced a total loss of their data, including contacts, pictures, calendar entries, and other personal information. It turned out that Microsoft had failed to update the data centre to run on Microsoft technology. They were lucky enough to recover a lot of the data (eventually), but the damage to the company’s reputation had already been done.
It’s not just reputation to worry about, either. Businesses are affected in different ways from data loss depending on their industry. If a business in the manufacturing industry lost their data, it could affect regulatory compliance and lead to wasted product, fines, and potentially hazardous situations. This is particularly true with pharmaceuticals, who often need to show all the collected data from their manufacturing process when they complete a batch. Not only could they lose that batch, but they could face fines for not complying with regulations.
Remember that around 30% of the causes of data loss are human error, so always make sure there’s an expert in charge. It’s off-puttingly simple to delete your data, as a hosting provider learned in 2016 when they accidentally deleted their entire server, including websites for around 1500 customers (although the owner later claimed it was a prank).
So, while data centres are almost ubiquitous for businesses, they also come with their own jeopardy. Data is so valuable that keeping it in one place without a backup or established measures in the event of a failure is putting your entire business and its reputation at serious risk. Always make sure that your DBA understands all the ins and outs of your system because even the smallest error could mean disaster. Alternatively, you could use a remote DBA whose entire business model is based on protecting your data and making sure any downtime or losses have minimal impact on your business and customers. If that sounds tempting, feel free to get in touch!
For more information or to schedule a demo please contact usContact us
DSP attended the UK Oracle User Group Partner of the Year Awards last week, and we came away with awards for both categories in which we were nominatedRead more
Join us for lunch and to hear some war stories from staff and customers with experience of Oracle Database Cloud Service. We'll also understand more about the Autonomous Database and how Oracle will compete with AWS.Read more
Don't compromise when it comes to the security of your data: discover the key to capitalizing on your migration into Public Cloud.Read more