Welcome back.

So this is part three where we will discuss about security options, a

feature available in autonomous transaction processing databases.

So in terms of security, only databases which are basically exposed to just the SQL
access only. So that prevents installing or modifying any software on the system.
So no highly privileged access. So no root, as well as SYSDBA.

No logins are allowed to operating system, or container database. So no call out to

OS is allowed here. So security configuration is deployed at all the levels, not
only database, but network as well as operating systems.

So database runs in a private virtual cloud network that prevents any kind of
network access by external [INAUDIBLE]. Public IP is not a requirement here.
Network encryptions are available, and our databases are always encrypted so that
way we are able to reduce the attack surface for operating system and database.

Automatic protection of customer data from Oracle operation staff, and this is
very, very important, as we are the only vendor basically who provides this kind of
security feature. So think of when we are providing you autonomous kind of
behavior. We are patching the database systems. We are looking if any security
vulnerabilities are there. But at the same time, operations should not be able to
look into the customer data.

And that is implemented through Oracle's own technology. So that is part of Oracle
kernel, database vault. So that's in the security ops and within databases. And
these help you implement these kind of operational control from the security
perspective.

So protection of any end user data from customers or administrators. So segregation

of roles and other responsibilities are in place. And database vault [INAUDIBLE]
can be configured here.

Oracle automatically applies the security updates for the entire stack. So whether
it's a quarterly or off cycle for any kind of high impact security vulnerabilities,
custom can separately use database vault for their own user data isolation because
it's part of database kernel.

And within DBA roles, you can have developer roles, or maybe, depending on the
departments. And also, if you want to have more controls, then you can use database
vault.

We'll look at the high availability options, which are available in the autonomous
transaction processing database. This offering basically automatically protects
from all kind of downtime failures that includes-- it has Exadata plus machine
learning, AI. You have real application clusters.

For site outages, it uses Active Data Guard, which will be coming soon. Right now
it is not available in the current release. For maintenance related activities,
Real Application Cluser rolling updates, as well as transparent application
continuity.

So in terms of managing changes, you have online indexing, or Edition Based

Redefintion. They are getting done. And these are all online operations that
definitely deal with your downtime requirements. And in case of any user errors,
you have Flashback Database it a part of this deployment. Or Flashback Database,
Tables, or Query. So they deal with the user errors.

Exadata and RAC is definitely for hardware level, no single point of failure, as
well as a Real Application Cluster is known to provide scalability and high
availability. It follows Oracle maximum ability architecture. So that is Oracle
best practices blueprint. And based on those proven Oracle high availability
technologies based on expert recommendations, as well as customer experience, the
goal of maximum ability architecture is to achieve basically optimum high
availability for Oracle customers. At the same time, looking at lowering the cost
as well as the complexity.

It also provides zero impact patching. And that enables patching of Oracle grid
infrastructure, as well as database software without basically interrupting the
database operations. So patches will be applied out of place and in a rolling
fashion, with one node being passed at a time when the database instance on the
other node is up and running.

So that way, it provides [INAUDIBLE] patching. And it is a Real Application Cluster

behind the scene. So in terms of serverless and fully automated daily backups to
Oracle storage cloud, basically object stored in buckets also provides on demand
backups, a flashback to 24 hours. So these are cool features which are even
available on serverless deployments.

And dedicated adds some extra features, like backup of archive logs, which are
performed every hour. So maybe in the future we will come a bit 15 minutes time
interval when we would release new enhancements.

The retention time for container database backups. It's configurable, like anything
between 7 days to 60 days. So currently, on demand backup retention is same as
container database indefinite retention is supported.

Zero Data Loss Recovery Cloud Service will be used for backups maybe in future, so
that would provide a different level of backup recovery service level agreements
and enhancements.

So in terms of high availability of ADs, it provides protection from the hardware

failures, software classes, or software updates. It uses a real application cluster
or database application continuity, Flashback database written in network. Triple
mirrored storage, as well as daily backups. And on top, extreme performance, or
extreme availability as protection from site outages, as well as data corruption.
So you will be seeing that coming maybe in the future releases in this.

So that is when we use Active Data Guard for our standbys. So backups are fully
automated data backup, as well as on demand backups are getting done as of today.
And uptime requirements are 99.9% of uptime. That translates to basically 22
minutes of downtime per month.

So many new things which are coming up in coming releases. So in terms of RTO and
RPO metrics, so high availability policy, recovery time objective, as well as
potential data loss. That is nothing but RPO service, SLOs, Service Level
Objectives.

So in terms of this network or a storage failure, the downtime for RTO is zero. And
that is all because it has no single point of failure. Potential data loss is zero.
RAC instance failures, within seconds you will have, because everything is RAC is
active, active. So it doesn't take time.

Data loss, there is zero data loss. RAC server failures could be in seconds, to
data loss is zero. Data corruption or any unrecoverable database, availability
domain, or regional failures. So that is time to restore and recover from cloud
object storage. So that's the RTO.

And in terms of potential data loss, since the last backups maximum 45 minutes
based on archive backup frequency. Hardware and software maintenance and updates.
So downtime is, again, zero, as well as potential data loss is zero. Major database
updates could be hours to zero in terms of RTO and there is no data loss.

Now, we are going to take a look at some of the unique features which is available
on autonomous dedicated. So one is customized software updates and patching. And
Oracle is responsible for all software updates operations. The database is
continuously available to applications. And updates apply across the RAC nodes
basically and Exadata storage servers.

Applications using application continuity, that is a best practice to run without

any interruption, and any quarterly patches or updates of all the components. So on
demand for critical security issues. That is there on dedicated. So from where
operating systems are stored as network in a hypervisor or Clusterware database,
they all are covered as part of quarterly maintenance schedule.

Updates are automatically scheduled based on customer preferences, like customer

can adjust basically timing to accommodate the critical business periods. Or
customer chooses the target software with a current or any previous quarterly
update or revision.

And based on their selection only, they're able to control it. So this picture
shows how it appears in the OCI console. Customers has full control on. So
automatic maintenance across every quarter. And Oracle notifies the exact date and
time for maintenance a few weeks in advance.

But customers are still able to configure these maintenance schedule. You can
either go with no preference, or you go with a specific schedule. So you choose the
preferred month, week, or week day, or the start time for infrastructure
maintenance. And then you need to click the Update Maintenance area. And you can
confirm the changes.

So it appears maintenance history is available in the console itself. So inside the

Maintenance History tab, it will show you if there are any planned maintenance
activity during the next 15 days, or any history of whatever business you have
performed so far.

We'll move to part four of Autonomous Database Dedicated. So thanks for watching.
And I will see you in part four where we'll talk more on developer tools and
productivity options available in Autonomous Dedicated. Thanks for watching.