Database services

Octave Computing Limited are experts in the full life cycle of enterprise databases. We are familiar with the traditional online transaction processing (OLTP) databases and data warehouse (DW) databases. Each type of database has a different goal. The OLTP database's goal is a high throughput of transactions. Each transaction should use minimal system resources. The goal of a DW is to retrieve the data as quickly as possible. Each query may use as many resources as necessary to achieve this goal.

Administration

We can size your databases, specify the database servers and SAN requirements, build, patch, and administer your databases.

Oracle

Oracle is our database of choice for enterprises. We have more than ten years of experience with the following releases of Oracle Server and Oracle Database.

Microsoft SQL Server

Many off the shelf products only support running on Microsoft SQL Server. We can administer SQL Server 2000 and SQL Server 2005.

PostgreSQL

PostgreSQL is a reputable open source database that has a high degree of compatibility with the Oracle database.

Backup and recovery

We have lost count of the number of times that organisations have concentrated on backups without considering recovery. The goal for protecting data should be recovery. Backups are just a means to this end. We ask the difficult questions such as

What are the points of failure and the risk of occurrence?
How much loss of data is acceptable (if any)?
What is the desired 'mean time to recovery'?
Is complete recovery still possible even if the last backup has failed?

Upgrades and migrations

Security patching
Minor upgrades
Major upgrades and version migrations

Design

Relational design
Logical design
Physical design

Performance tuning

It is best to consider performance at each of the stages of design stated above. However, existing system may suffer performance problems especially after maintenance and growth. For example the following factors are common in non-performant systems.

Poorly normalised relational design
Inappropriate use of denormalisation
Poor choice of table keys
Inadequate indexing or over indexing
Use of literal predicates instead of bind variables in SQL (does not necessarily apply to DW or reporting databases)
SQL that runs fast in the development system (maybe 100 ms for a few rows) but has order n^2 or worse, so slows down appreciably when the data set grows
Hardware bottlenecks
Poor physical database design and implementation

Data management

It is very common to see data spread throughout an organisation by means of spreadsheets. This approach causes the loss of control of the data, is haphazard, and falls apart when the data sets become too large. Even so, people like the spreadsheets since they are a familiar tool especially when it comes to slicing and dicing, analysis, and graphing.

The solution we have put in place for multiple clients offers the benefits of using relational databases to store corporate data while retaining the autonomous benefits of the spreadsheets. For example by embedding SQL queries in spreadsheets data can be refreshed easily and will always be sourced from the same place. All data consumers will be 'singing from the same hymnsheet'. Management reports will be consistent. Add to this the resilience, integrity, and backup and recovery benefits of a relational database and you have a powerful solution.