Operationally Scalable Practices

I really enjoy being a technical guy. So far in my career I’ve made development choices favoring a technical path over other options. It’s been a great ride – I’ve worked in small teams and large teams; consulting roles and in-house roles; architecture/engineering roles and operations roles; big databases and little databases; environments with a few databases and environments with thousands of databases.

I’ve never been anywhere which had everything right. Also, my own ideas about what’s “right” are still evolving today. I have a habit of trying to be around people who are smarter than me… over the course of my career, my own knowledge and experience with Oracle have grown exponentially and yet I’ve never had trouble continuing to feel like a junior DBA. (In particular, my invitation to the Oak Table made this very easy!)

With that long introduction, here’s what I’m up to now: I’m going to write a series of articles about Operationally Scalable Practices for Oracle. I’ll use my train commutes and lunch breaks to write a collection of fairly specific “good ideas” that come to mind for managing and operating Oracle Databases. I hope that this stimulates interest and discussion from my peers who face similar challenges. And I hope that it will become a place I can return to later to see how my ideas evolve over time. Or even better – if I get some interesting feedback then it will become a place for collaboratively compiling the best ideas.

What is Operations

I’m drawing a distinction between operations and development activities, and my focus here will be on operations. Think of all the decisions you make when you’re building new systems, for example: how to name things, what directory structure to use, and values for OS and DB configuration parameters. There’s an abundance of resources for the development side of the house (designing and troubleshooting applications or SQL) – like material from Kyte, Lewis, Feuerstein, etc. However I haven’t seen many solid and comprehensive books for operations. As a result, there’s very little shared wisdom for writing organizational processes and standards about naming databases or setting init params. There is some incredibly deep expertise in the marketplace – but right now that knowledge is generally locked within individuals’ memory and organizations’ private powerpoints. Or else it’s available piecemeal on various blogs while there’s no comprehensive compilation. This is a significant gap which hurts younger organizations and newer DBAs. I hope these articles begin to address the need.

This topic will be relevant to any organization that spends time and resources on database operations – not just the big companies. I think you should be reading closely and heavily engaging these topics if – once a month or more – someone in your organization does any of the following activities:

• set up a new server
• set up a new database
• set up a new schema (or PDB)
• patch a server or database
• make a similar change on more than one database
• follow a similar process on more than one database

What are Operationally Scalable Practices?

Let me briefly introduce the concept of “operationally scalable practices”.

Operationally Scalable Practices are guidelines that drive attitude and policy in order for your organization to scale in four key ways:

• Size of Databases (your database gets bigger)
• Number of Databases/Schemas (you get more databases)
• Feature Usage (you use more features of the database)
• Operational Processes (you document more activities in order to make them easier, more routine and more predictable)

These articles should provide guidance as you architect standards and processes for your organization. They will not be theoretical; I have worked in person on very large databases and at organizations managing thousands of databases. I’ve been fortunate to meet and work with many brilliant architects and engineers… I’m hoping that I’ll remember some of what I’ve learned! The guidelines in my articles won’t be perfect and there will be room for improvement – but they are based on real experiences of myself and others.

Roadmap

I plan to start with an article about general guidelines which should establish key principles to underly the technical discussions and set out a more detailed structure for the content. I will follow that with a number of deeper articles on specific topics.

I consider these articles to be works in progress even after I publish them and I will revise them over time as my ideas evolve or as others point out improvements. I hope you stick around and generously share your thoughts and suggestions!

In fact, if you know any specific areas I should cover then please mention them now!