If you have ever read anything I have written or heard me speak, you would know I call myself a “Developer” and not a “DBA.” I think over the last 10 or 12 years, I am probably better known as an “Exadata Guy” as I have shifted my focus to that platform as it is ubiquitous across so many industries. Having shifted my focus to how the Oracle Database and Exadata actually work, I know I would have been a much better developer if I knew as much about the database then as I do now.
If you are a developer working today, you might not consider yourself a “database developer.” If you are writing a business application, then there is a database behind most, if not all, of your code. Let’s say you’re writing Java or Python code and you’re connecting to an Oracle Database (the brand really doesn’t matter but let’s go with Oracle) and you are given the label “Full Stack Developer.” The expectation is that you are skilled in all facets of the development process, which includes database.
As you write your code, you’re probably dealing with some or all of the following:
- Interpreting the Data Model of the underlying database
- Writing some version of database code (SQL or something that gets converted to SQL)
- Testing your code to ensure it meets the business requirements
The Missing Elements – Process and Performance
What might be missing here is the process of testing for performance. It is typical that Development or Pre-production environments are loaded with real, but abbreviated data sets. The reason for this is usually financially based as it is expensive to maintain multiple environments with Production volumes of data. So, when you do your testing, everything’s cool. No performance issues because the database is not very big. This is not a new story.
So, what do you do? You add an experienced database developer / performance tuner to the Dev/Ops team. Someone with large scale database performance management will recognize SQL coding practices which are known to be problematic in large database environments. For example, Common Table Expressions (CTE) or Correlate Sub-queries used in the wrong way can be devastating to performance in large database environments. If performance-robbing code makes it to production, it is often difficult to remove or replace it.
Remember, in my career as a developer, the first thing that worked was what when into production, not the best thing. The reason is that we, as developers, are usually building something that has never been built before so we’re doing lots of things for the first time, even if we have been working for 25 years. In my experience, the most egregious performance problems usually occur in the database. It is rare that an Application Server is at the root of why a report runs for 12 hours.
Scaling Your Database Infrastructure
If you want your project to result in a highly performant system which will scale with your business, make sure you have a good performance management resource on the Dev/Ops team. Not only will they help with code development, but they can also help to best utilize the features of your database environment.
Sometimes, you do have the best code and it performs to the degree that physics will allow, but it still falls short of expectations. In those cases, I always say, “Get more hardware, or get less data.” Getting more hardware may not be in the budget, but there are lots of ways to minimize your data set. This is where a database performance expert really matters.
Infolob believes in the concept of a Database Center of Excellence. We provide proprietary tools, processes, and highly skilled resources to help our Clients to exploit the full potential of their technical investments. When we implement this concept with our customers, the results include maximum stability, scalability, and performance from their most critical environments.
For all queries, please write to:
