Dontcheff

What’s next for DBAs as we enter the mid-21st century

In Databases, DBA, Oracle AI Database 26ai on May 16, 2026 at 09:01

For years, the industry predicted the decline of the DBA role. Instead, the opposite happened. “The AI Database Myth: Why Automation Hasn’t Replaced Human Judgment” made it clear: The DBA Role Didn’t Shrink – It Matured!

“When incidents occur, no executive asks what the tool suggested. They ask who approved the decision. Accountability has not been automated away.”

The “Death of the DBAâ€Ķ Againâ€Ķ” article by Tim Hall points to several links on the topic of the DBA relevance while the one above (click on the picture) by Douglas McDowell mentions the steady decline in the number of traditional Database Administrators and overall level of database expertise.

The role evolved from operational administration into strategic infrastructure engineering. Modern enterprises may appear cloud-native on the surface, but underneath, their most critical complexity still lives in the database layer.

And nowhere is this more visible than in large database environments.

Applications may define user experience. But databases define operational reality!

Or perhaps if I can be more blunt: in enterprise IT, the true architecture is ultimately the database architecture. Databases are the most complex element in modern IT environments.

Why DBAs still sit at the center of enterprise complexity? Well, for decades, enterprise IT has tried to simplify complexity through abstraction like virtualization, cloud, containers, automation, platform engineering, even now with AI-assisted development.

Yet despite all this progress, one component remains extraordinarily difficult to replace, modernize, automate, or fully abstract: the enterprise database.

And in the largest enterprises, that usually means the Oracle database. The modern DBA is no longer “just” a database administrator. In many enterprises, the database has become the single most operationally and architecturally complex element in the entire IT landscape.

I have been observing the DBA profession for more than 25 years. And say, 20-25 years ago, complexity was mostly infrastructure related. DBAs dealt with important systems, but the environment itself was relatively predictable. We had physical servers, storage arrays, networks, backup systems, you name it… It was complex, but it was also contained. The database was important, but largely centralized. Today’s database environments often include:

  • Hybrid cloud,
  • Multi-cloud,
  • Autonomous databases,
  • Kubernetes integration,
  • Data Guard,
  • GoldenGate,
  • Exadata,
  • Sharding,
  • Active Data Guard,
  • Multitenant architectures,
  • Zero Downtime Migration,
  • Distributed analytics,
  • JSON workloads,
  • AI/vector workloads,
  • DORA/Regulatory sovereignty requirements.

The database is no longer a standalone platform! It has become an ecosystem.

New generation database experts often ask me why the Oracle Database became so complex. The story goes like this: the database carries the business. Applications can fail gracefully. Web servers can be redeployed. Containers can restart in seconds.

But when the database fails, the impact is immediate and far-reaching: revenue is affected, transactions come to a halt, reporting is disrupted, compliance risks emerge, and recovery quickly escalates to senior management attention. Ultimately, it can also damage the company’s reputation.

The database is often the financial system of record, the ERP backbone, the supply chain engine, the HR platform, the operational core of the enterprise. All business and mission critical systems sit on top of a database.

This creates enormous pressure on DBAs because the database is expected to provide zero downtime, perfect consistency, high performance, global availability, disaster recovery, security and even zero-downtime simultaneously. Well, zero-downtime exists only in power point presentations but that is another story 🙂

Enterprise databases accumulate decades of enterprise history and are one of the most underestimated realities in enterprise IT. In many enterprises, the database contains more business logic than the applications themselves. This is why database migrations are rarely technical projects alone. They become organizational transformation programs.

Cloud did not eliminate DBA complexity. Cloud vendors promised simplification. And to some extent, they delivered provisioning, infrastructure automation and elasticity. But cloud also introduced entirely new categories of complexity. The DBA must now understand:

  • AWS, OCI, GCP and Azure architectures,
  • cloud integrations,
  • interconnects,
  • hybrid networking,
  • cloud security models,
  • cross-cloud replication,
  • cloud cost optimization,
  • performance tuning (tricky in the cloud, read below)
  • shared responsibility models.

The DBA role expanded from database administration into cloud platform engineering. Cloud removed hardware management. It did not remove database complexity. Performance tuning became more difficult, not less. In earlier generations, performance bottlenecks were relatively visible as we had CPU saturation, slow disks or memory shortages.

Today, database performance problems may involve (not even mentioning clumsy software generated SQL):

  • virtualization layers,
  • cloud storage latency,
  • noisy neighbors,
  • container orchestration,
  • distributed queries,
  • inter-region latency,
  • storage tiering,
  • application microservices,
  • encryption overhead,
  • AI/vector processing.

The database is no longer just responsible for storing data; it has also become a critical part of the organization’s security boundary. Data Gravity makes Oracle, or any other enterprise database for all that matters, hard to replace.

One of the biggest misconceptions in modern IT is the belief that databases can be “easily migrated”. Applications may move quickly. Enterprise data rarely does.

Large database estates often contain:

  • petabytes of data,
  • thousands of integrations,
  • decades of tuning,
  • mission-critical SLAs,
  • operational dependencies everywhere.

This creates enormous data gravity. The larger the database environment, the more the surrounding architecture begins to orbit around it. This is why many “database modernization” initiatives ultimately become coexistence strategies rather than full migrations.

Today, AI is making databases even more strategic. AI workloads are increasing database complexity again. Enterprises now expect databases to support vector search, JSON workloads, AI pipelines, real-time inferences, unstructured content and GPU-adjacent architectures.

Even in the AI era, the database remains central because AI ultimately relies on enterprise data, and once you start looking at how that data is managed and governed, you quickly end up back at the database layer. AI did not reduce the importance of the DBA. It expanded it.

Now, the modern DBA is one of the last true generalists. Few roles in IT still require such broad and deep technical understanding. Which leads to my final observation:

As infrastructure became abstracted, the database became the place where complexity concentrated.

Thus, let me repeat it once more 🙂

If we step back, the prediction that the DBA role would disappear hasn’t really held up. Instead, the role has evolved. What used to be primarily operational work has grown into something much closer to strategic infrastructure engineering. Even in organizations that appear fully cloud-native, a significant portion of the real complexity still sits in the database layer, especially at scale. And that reality continues to shape how enterprise systems are designed and operated. Or perhaps even more directly:

In enterprise IT, the true architecture is ultimately the database architecture.

Comment »

DORA for DBAs

In Data, DBA, Regulations, Security and auditing on February 2, 2026 at 08:10

The Digital Operational Resilience Act (DORA), officially Regulation (EU) 2022/2554 is a European Union regulation. The full regulation text spans 79 pages in the Official Journal of the European Union and comprises 64 articles divided into 9 chapters.

DORA and DBAs? Why DORA matters for DBAs?

DORA is the EU’s new regulatory framework requiring financial institutions to ensure resilience of all ICT systems, including databases. For DBAs, this means formalizing and documenting operational practices that may have been informal or inconsistent. So, this is related directly to DBAs and database experts.

The basics are covered in a post by James Wood entitled “What is DORA, and how does it impact the database?“

A more detailed article was posted this month (January 2026) on the liquibase.com blog, namely “What is the Digital Operational Resilience Act (DORA) and what financial database & developer teams need to know“.

Here are 10 most important musts for DBAs and database professionals:

1. DORA applies to all “network and information systems supporting the business processes of financial entities”, which includes all production databases storing critical financial data. DORA for DBAs: You must treat every critical database as a regulated ICT asset and ensure it meets resilience and security expectations.

2. DORA requires organizations to implement a full ICT risk‑management framework, and databases must be included in these risk assessments because they are core ICT assets. DORA for DBAs: You must document database risks, such as outages, corruption, access misuse, and patch delays, and work to mitigate them.

3. DORA mandates major ICT‑related incident reporting, so any database outage, corruption, breach, failed patch, or upgrade causing service disruption qualifies as a reportable ICT incident. DORA for DBAs: You must have monitoring and alerting ready so you can detect issues quickly and provide accurate incident details.

4. If a database underpins payment systems, it is subject to payment‑related incident reporting, meaning even minor data‑integrity or availability issues become regulatory events. DORA for DBAs: You must treat payment‑related databases as high‑sensitivity systems with tighter controls and faster response obligations.

5. Databases must be included in DORA’s digital operational resilience testing, which covers backup validation, failover simulations, disaster recovery testing, load testing, and resilience scenario exercises. DORA for DBAs: You must perform and document regular DR tests and ensure the database can survive real‑world failure scenarios.

6. DORA requires cyber‑threat and vulnerability information sharing, which includes database vulnerabilities (e.g., Oracle, PostgreSQL, SQL Server, Db2, Snowflake, etc.), patches, and configuration risks. DORA for DBAs: You must stay on top of vendor security advisories and apply patches promptly.

7. Because database vendors and DBaaS/cloud providers qualify as ICT third‑party service providers, DORA requires formal supplier risk management, including resilience guarantees, security obligations, and incident‑reporting SLAs. DORA for DBAs: You must evaluate and document the risks of your cloud DB services and ensure the provider meets resilience expectations.

8. Database hosting or cloud‑database agreements must comply with DORA’s rules for contractual arrangements with ICT third‑party providers, ensuring auditability, transparency, security controls, and defined RPO/RTO levels. DORA for DBAs: You must help define or verify SLAs to ensure they match business continuity requirements (e.g., backups, failover, recovery speed).

9. Cloud database services may be designated as critical ICT third‑party providers, placing them under EU‑level supervisory oversight, which increases documentation, evidence, and performance reporting requirements for financial institutions using them. DORA for DBAs: You must maintain detailed documentation of how your databases rely on cloud vendors and ensure compliance evidence is always available.

10. Because DORA addresses resilience against cyber threats and ICT disruptions, databases must have strong data‑integrity controls, including ACID consistency, audit logging, access control, encryption, and protection against manipulation or corruption.
DORA for DBAs: You must enforce good database hygiene: secure configuration, proper auditing, reliable backups, and strong access controls.

So, for DBAs it is a combination of both excellent documentation based on tasks and measures which for the now have been either implemented partially or never have been done or tested.

Now, here is what it means in simple words:

  • Make sure that the production databases are not much different from the ones in the lower environments, refresh the data on regular basis
  • Enable almost full database auditing in the database, audit even DBA activities
  • Ensure you have all trace and background files of all databases available, store them in a separate historical database
  • Automate as much as possible: all schema changes, parameter changes, password changes (make the database access as complex as possible), etc.
  • On regular basis, test restore and recovery
  • Test if the DR solution works on at least quarterly basis
  • Monitor regulatory compliance, even automate it
  • Apply all security patches and updates as soon as they have been released
  • Monitor the database monitoring (sounds odd, right?)
  • Document all steps listed above!

For cloud databases, ensure that the cloud provider’s SLAs, resilience features, security controls, and incident‑reporting obligations fully meet DORA requirements. After all, you as DBA, remain responsible for the data even when the platform is outsourced! So, here is a DBA checklist for the 5 Pillars of DORA:

1. Information Sharing (Database‑Related Threat Intelligence)
DORA allows threat‑information sharing to strengthen collective cyber defenses.

  • Subscribe to security advisories for all DB engines (Oracle, PostgreSQL, SQL Server, Db2, MySQL)
  • Communicate database vulnerabilities internally
  • Share lessons learned from database incidents with internal security teams
  • Update config and patch policies based on shared threat intelligence
  • Participate in cross‑team meetings on cyber threats, focusing on database angles

2. ICT Risk Management (Databases)
DORA requires a complete ICT risk‑management framework, including databases as critical ICT assets.

  • Maintain a full inventory of all databases (on‑prem, cloud, replicated, test, DR)
  • Classify each database by criticality (Mission Critical, Business Critical, Task Critical or non-Critical)
  • Ensure configurations follow a hardened baseline (encryption, wrapped procedures, least‑privilege)
  • Keep database patching schedules up‑to‑date (security and engine updates)
  • Document all database risks (availability, integrity, access, vendor, performance)
  • Enable comprehensive auditing (logins, schema changes, privilege changes)
  • Implement strong access governance with role‑based access control
  • Perform regular internal reviews of DB security posture and DR readiness

3. ICT Incident Reporting (Database Incidents)
DORA requires formal processes for classifying and reporting ICT incidents.

  • Define what constitutes a database “major incident” (e.g., corruption, breach, extended outage)
  • Implement alerting for anomaly detection (CPU spikes, I/O stalls, unexpected schema changes)
  • Ensure logging provides evidence for regulatory reporting (timestamped, immutable, complete)
  • Prepare a DBA‑specific incident playbook aligned with DORA reporting timelines
  • Document incident classification thresholds (significant vs. major)
  • Support root‑cause analysis with proper forensic logging and backups
  • Ensure database‑specific incident response SLAs support DORA deadlines

4. Digital Operational Resilience Testing (Database Resilience)
DORA requires testing ICT resilience, including database failover and recovery scenarios.

  • Perform regular backup restore testing (not just verifying file existence)
  • Run failover tests for HA clusters, read replicas, and geo‑replication
  • Document RPO/RTO and validate they meet business requirements
  • Conduct load and stress tests to evaluate behavior under peak or attack scenarios
  • Participate in Threat‑Led Penetration Testing (TLPT) when databases are in scope
  • Verify that DR environments are consistent with production schemas and configs
  • Ensure test results are archived for audits

5. ICT Third‑Party Risk Management (Cloud & Vendor Databases)
DORA requires strong oversight of all ICT third parties, including cloud databases.

  • Maintain a list of all vendor‑managed and cloud databases (e.g., OCI Autonomous DB, Azure SQL, AWS RDS)
  • Validate vendor SLAs for uptime, RPO, RTO, and incident notifications
  • Ensure encryption, backups, logging, and access controls are verifiable and compliant
  • Review contracts for exit strategy, portability, audit rights, and data‑location guarantees
  • Monitor vendor patch cycles and apply critical updates promptly
  • Ensure third‑party changes can be audited and traced
  • Validate that vendor services support resilience testing (failovers, restores, snapshots)

Conclusion: What DBAs must do now: DORA isn’t just a compliance exercise as it is an opportunity for DBAs to strengthen operational discipline, improve resilience, reduce incidents, and elevate the role of database engineering within financial institutions.


Comment »

What is a JSON object in Oracle AI Database 26ai?

In DBA, Oracle AI Database 26ai, Oracle internals on October 16, 2025 at 14:54

The Oracle Autonomous AI JSON Database has a limit of 20GBs of relational data. Think of 20GBs of non-JSON tables, their indexes and MVs. It is possible to subscribe to the information event AJDNonJsonStorageExceeded, and thus be informed when the 20 GB limit is exceeded. 

However, at that point, it might be a bit too late…

There is a new view in Oracle AI Database 26ai called DBA_NONJSON_OBJECTS. As you can see from the view definition below, there is also a new package called DBMS_AJD_UTIL which contains few functions and is available (for viewing only) in clear text to the ADMIN user (no execution privileges on the package).

Here is the definition of DBA_NONJSON_OBJECTS:

The view shows all objects which are not JSON objects.

Access to DBA_NONJSON_OBJECTS is only granted to the ADMIN user and cannot be granted to any other user.

Here are the 3 main reasons why an Oracle table is considered a non-JSON table:

1. NO JSON CONTENT: Table and dependent objects do not contain any JSON information. That is either of JSON type or of BLOB type with the “is json format OSON” check constraint.

2. DATA TYPE VIOLATION: Table contains constrained datatypes. Columns that are not JSON can include only columns Oracle built-in types. Columns cannot be of type: LONG, LONG RAW, LOB related (CLOB/NCLOB/BLOB/BFILE), or VECTOR.

3. MAXIMUM SIZE OF NON-JSON COLUMNS EXCEEDED: Table exceeds the allotted limit of non-JSON columns. In each table, the sum of the maximum sizes of the non-JSON columns must be less than 533 bytes.

JSON objects are also indexes created on top of JSON tables, including JSON search indexes and spatial indexes. Also, materialized views created on top of JSON tables are considered JSON objects. When a materialized view is joined among JSON tables and any other tables, it is also considered a JSON object.

Let us try to create a table where the size of non-JSON columns is 532 (recall that we count 22 for number and 7 for date):

drop table if exists COFFEE_IS_JSON purge;
create table COFFEE_IS_JSON 
(id number primary key, description varchar2(510), coffee_info JSON);

As expected, we create a table which does not appear under DBA_NONJSON_OBJECTS.

Table COFFEE_IS_JSON created.

However, if you recreate it with the description size as varchar2(511), then it becomes at once a non-JSON object.

Here are the definitions of the 3 tables above which are non-JSON objects:

drop table COFFEE_IS_NONJSON purge;
create table COFFEE_IS_NONJSON 
(id number primary key, description varchar2(600), coffee_info JSON);

drop table CAR_IS_NONJSON purge;
create table CAR_IS_NONJSON 
(id number primary key, car_info JSON, car_data CLOB);

drop table STOCK_IS_NONJSON purge;
create table STOCK_IS_NONJSON 
(id number primary key, stock_info CLOB, stock_logo BLOB);

The indexes and materialized views created on top of JSON objects will not be considered non-JSON objects.

CREATE MATERIALIZED VIEW coffee_sales_mv
BUILD IMMEDIATE
REFRESH FORCE
START WITH TRUNC(SYSDATE+1)+12/24
NEXT SYSDATE+1
WITH ROWID
ENABLE QUERY REWRITE
AS SELECT jt.*
FROM coffee s,
json_table(s.data, '$' ERROR ON ERROR NULL ON EMPTY
COLUMNS (
item_id         NUMBER         PATH '$._id',
item_name       VARCHAR2(16)   PATH '$.item',
item_price      NUMBER         PATH '$.price',
NESTED PATH '$.CoffeeItems[*]'
COLUMNS (
details_description VARCHAR2(32)  PATH '$.Details.Description',
details_code        NUMBER        PATH '$.Details.Code'))) jt;

CREATE INDEX mv_det_code_idx ON coffee_sales_mv(details_code);

Note the table DBTOOLS$EXECUTION_HISTORY which stores SQL history. As it will count against your 20GBs, you might want to truncate it from time to time. May be after exporting the data in case you think you might need it in the future.

In case you really hit the 20GB limit, here is how to migrate from AJD to ATP. It is more of a promotion than a migration but this is semantics. Check the blog post by Mike Dietrich entitled Oracle AI Database 26ai replaces Oracle Database 23ai.

Comment »