Note that the pictures below are straw-man works in progress (TODO)

OPINION: Normally we would expect someone in the team that owns a particular application schema/database to Grant access to others (assuming security isn't handled wholly in the application tier) i.e. (taking inspiration from another fridge based analogy of Brent Ozar's) DBAs give you a shelf (database/schema) in a fridge (database instance), developers put empty containers (tables) in that fridge, end users put food in, take food out, and otherwise manipulate food (data) in the containers... developers (acting on behalf of the service owners) control who can do things to the food in the containers (through Granting/Revoking Roles and Privileges) and how (through the application code)... we (DBAs) can do all the things to the containers that developers can do and more... but just because we can give other people access to the food in your containers, doesn't mean we should ("hey, do you fancy some of this caviar?, yeah I know it's Ian's, but I can bypass the security he put on it...")

So, we (DBAs) can Grant access to these tables, but so can the schema owner. We (DBAs) probably shouldn't make those Grants because it's not our data to share.

How many DBAs

Factors to consider:

• Number - the more databases you have, the more DBAs you need. Take into account "database" vs "instance" and "standalone" vs "clustered" (AlwaysOn/RAC/InnoDB Cluster).

• Size - the bigger the database, the longer things take and the bigger the impact when things go wrong.

• Users - the more users you have, the more calls you are likely to get

• Applications - 10 databases running the same application are easier to manage than 10 databases running different applications. Unique databases have unique issues. Applications that share an instance can disrupt each other. Applications that are undergoing constant Change need more DBAs than realtively static applications. In-house developed applications need more DBA involvement than off-the shelf applications.

• SLAs - performance SLAs, availability SLAs, compliance SLAs - tight SLAs need more DBAs

• Experience - a small team of experienced DBAs might achieve as much as a big team of inexperienced DBAs. Inexperienced developers will cause more issues than experienced developers. Inexperienced sysadmins may not be able to provide the support required to diagnose OS root causes of database issues meaning the DBAs will need to do get more involved. Strike the right balance between quality and quantity.

• Location - cloud vs on-prem. Newer reliable hardware vs older unreliable hardware. Over-provisioned resources vs under-provisioned resources (CPU. Memory, Stroage etc).

• Database Flavour - if you have Oracle, MS-SQL, MySQL, DB2 and PostgreSQL you really need to consider a minimum of 5 DBAs. You may be lucky and find some DBAs skilled in more than one database technology but it is really difficult to be an expert in more than one or two technologies at a time (there really is so much new to learn all the time) especially if you are using things outside core DBMS functionality (SSRS, SSIS, Oracle Applications Express, RAC, Oracle Advanced Compression, Oracle Advanced Security). This is even more important if you are also using other types of databases like MongoDB.

• Tools - some tasks can be automated away e.g if your database servers get built, patched and upgraded using automation tools whether on-prem or in the cloud, then your DBAs will spend less time building, patching and upgrading. Discovery tools reduce the need to capture data manually in spreadsheets or CMDBs. Monitoring tools reduce the effort to diagnose issues.

Bibliography & References