Jan 9, 2024
00:00
Welcome to the Oracle University Podcast, the first stop on your
cloud journey. During this series of informative podcasts, we’ll
bring you foundational training on the most popular Oracle
technologies. Let’s get started.
00:26
Nikita: Hello and welcome to the Oracle University Podcast. I’m
Nikita Abraham, Principal Technical Editor with Oracle University,
and I’m joined by Lois Houston, Director of Innovation
Programs.
Lois: Hi there! This is our second episode on Oracle’s Autonomous
Database, and today we’re going to spend time discussing Autonomous
Database on Dedicated Infrastructure. We’ll be talking with three
of our colleagues: Maria Colgan, Kamryn Vinson, and Kay
Malcolm.
00:53
Nikita: Maria is a Distinguished Product Manager for Oracle
Database, Kamryn is a Database Product Manager, and Kay is a Senior
Director of Database Product Management.
Lois: Hi Maria! Thanks for joining us today. We know that Oracle
Autonomous Database offers two deployment choices: serverless and
dedicated Exadata infrastructure. We spoke about serverless
infrastructure last week but for anyone who missed that episode,
can you give us a quick recap of what it is?
01:22
Maria: With Autonomous Database Serverless, Oracle automates all
aspects of the infrastructure and database management for you. That
includes provisioning, configuring, monitoring, backing up, and
tuning. You simply select what type of database you want, maybe a
data warehouse, transaction processing, or a JSON document store,
which region in the Oracle Public Cloud you want that database
deployed, and the base compute and storage resources necessary.
Oracle automatically takes care of everything else. Once
provisioned, the database can be instantly scaled through our UI,
our APIs, or automatically based on your workload needs. All
scaling activities happen completely online while the database
remains open for business.
02:11
Nikita: Ok, so now that we know what serverless is, let’s move on
to dedicated infrastructure. What can you tell us about it?
Maria: Autonomous Database Dedicated allows customers to implement
a private database cloud running on their own dedicated Exadata
infrastructure. That dedicated infrastructure can be in Oracle’s
Public Cloud or in the customer's own data center via Oracle
Exadata Cloud@Customer. It makes an ideal platform to consolidate
multiple databases regardless of their workload type or their size.
And it also allows you to offer database as a service within your
enterprise.
02:50
Lois: What are the primary benefits of Autonomous Database
Dedicated infrastructure?
Maria: With the dedicated deployment option, you must first
subscribe to Dedicated Exadata Cloud Infrastructure that is
isolated from other tenants with no shared processors, memory,
network, or storage resources.
This infrastructure choice offers greater control of both the
software and the infrastructure life cycle. Customers can specify
their own policies for workload separation, software update
schedules, and availability. One of the key benefits of an
autonomous database is a lower total cost of ownership through more
automation and operational delegation to Oracle. Remember it’s a
fully managed service. All database operations, such as backup,
software updates, upgrades, OS maintenance, incident management,
and health monitoring, will be automatically done for you by
Oracle. Its maximum availability architecture protects you from any
hardware failures and in the event of a full outage, the service
will be automatically failed over to your standby site. Built-in
application continuity ensures zero downtime during the standard
software update or in the event of a failover.
04:09
Nikita: And how is this billed?
Maria: Autonomous Database also has true pay-per-use billing so
even when autoscale is enabled, you’ll only pay for those
additional resources when you use them. And we make it incredibly
simple to develop on this environment with managed developer
add-ons like our low code development environment, APEX, and our
REST data services. This means you don’t need any additional
development environments in order to get started with a new
application.
04:40
Lois: Ok. So, it looks like the dedicated option offers more
control and customization. Maria, how do we access a dedicated
database over a network?
Maria: The network path is through a VCN, or Virtual Cloud Network,
and the subnet that's defined by the Exadata infrastructure hosting
the database. By default, this subnet is defined as private,
meaning, there's no public internet access to those databases. This
ensures only your company can access your Exadata infrastructure
and your databases.
Autonomous Database Dedicated can also take advantage of network
services provided by OCI, including subnets or VCN peering, as well
as connections to on-prem databases through the IP secure VPN and
FastConnect dedicated corporate network connections.
05:33
Maria: You can also take advantage of the Oracle Microsoft
partnership that enables customers to connect their Oracle Cloud
Infrastructure resources and Microsoft Azure resources through a
dedicated private connection. However, for some customers, a move
to the public cloud is just not possible. Perhaps it's due to
industry regulations, performance concerns, or integration with
legacy on-prem applications. For these types of customers, Exadata
Cloud@Customer should meet their requirements for strict data
sovereignty and security by delivering high-performance Exadata
Cloud Services capabilities in their data center behind their own
firewall.
06:16
Nikita: What are the benefits of Autonomous Database on Exadata
Cloud@Customer? How’s it different?
Maria: Autonomous Database on Exadata Cloud@Customer provides the
same service as Autonomous Database Dedicated in the public
cloud.
So you get the same simplicity, agility, and performance, and
elasticity that you get in the cloud. But it also provides a very
fast and simple transition to an autonomous cloud because you can
easily migrate on-prem databases to Exadata Cloud@Customer. Once
the database is migrated, any existing applications can simply
reconnect to that new database and run without any application
changes being needed. And the data will leave your data center, so
making it a very safe way to adopt a cloud model.
07:04
Lois: So, how do we manage communication to and from the public
cloud?
Maria: Each Cloud@Customer rack includes two local control plane
servers to manage the communication to and from the public cloud.
The local control plane acts on behalf of requests from the public
cloud, keeping communications consolidated and secure. Platform
control plane commands are sent to the Exadata Cloud@Customer
system through a dedicated WebSocket secure tunnel.
Oracle Cloud operations staff use that same tunnel to monitor the
autonomous database on Exadata Cloud@Customer both for maintenance
and for troubleshooting. The two remote, control plane servers
installed in the Exadata Cloud@Customer rack host that secure
tunnel endpoint and act as a gateway for access to the
infrastructure. They also host components that orchestrate the
cloud automation, aggregates and routes telemetry messages from the
Exadata Cloud@Customer platform to the Oracle Support Service
infrastructure. And they also host images for server patching.
08:13
Maria: The Exadata Database Server is connected to the
customer-managed switches via either 10 gigabit or 25 gigabit
Ethernet. Customers have access to the customer Virtual Machine, or
VM, via a pair of layer 2 network connections that are implemented
as Virtual Network Interface Cards, or vNICs. They're also tagged
VLAN. The physical network connections are implemented for high
availability in an active standby configuration.
Autonomous Database on Exadata Cloud@Customer provides the best of
both worlds-- all of the automation including patching, backing up,
scaling, and management of a database that you get with a cloud
service, but without the data ever leaving the customer's data
center.
09:01
Nikita: That's interesting. And, what happens if a dedicated
database loses network connectivity to the OCI control plane?
Maria: In the event an autonomous database on Exadata
Cloud@Customer loses network connectivity to the OCI control plane,
the Autonomous Database will actually continue to be available for
your applications. And operations such as backups and autoscaling
will not be impacted in that loss of network connectivity.
However, the management and monitoring of the Autonomous Database
via the OCI console and APIs as well as access by the Oracle Cloud
operations team will not be available until that network is
reconnected.
09:43
Maria: The capability suspended in the case of a lost network
connection include, as I said, infrastructure management-- so
that's the manual scaling of an Autonomous Database via the UI or
our OCI CLI, or REST APIs, as well as Terraform scripts. They won't
be available. Neither will the ability for Oracle Cloud ops to
access and perform maintenance activities, such as patching. Nor
will we be able to monitor the Oracle infrastructure during the
time where the system is not connected.
10:20
Lois: That’s good to know, Maria. What about data encryption and
backup options?
Maria: All Oracle Autonomous Databases encrypt data at REST. Data
is automatically encrypted as it's written to the storage. But this
encryption is transparent to authorized users and applications
because the database automatically decrypts the data when it's
being read from the storage. There are several options for backing
up the Autonomous Database Cloud@Customer including using a Zero
Data Loss Recovery Appliance, or ZDLRA. You can back it up to
locally mounted NFS storage or back it up to the Oracle Public
Cloud.
10:57
Nikita: I want to ask you about the typical workflow for Autonomous
Database Dedicated infrastructure. What are the main steps
here?
Maria: In the typical workflow, the fleet administrator role
performs the following steps. They provision the Exadata
infrastructure by specifying its size, availability domain, and
region within the Oracle Cloud. Once the hardware has been
provisioned, the fleet administrator partitions the system by
provisioning clusters and container databases. Then the developers,
DBAs, or anyone who needs a database can provision databases within
those container databases.
Billing is based on the size of the Exadata infrastructure that's
provisioned. So whether that's a quarter rack, half rack, or full
rack. It also depends on the number of CPUs that are being
consumed. Remember, it's also possible for customers to use their
existing Oracle database licenses with this service to reduce the
cost.
11:53
Lois: And what Exadata infrastructure models and shapes does
Autonomous Database Dedicated support?
Maria: That's the X7, X8, and X8M and you can get all of those in
either a quarter, half, or full Exadata rack. Currently, you can
create a maximum of 12 VM clusters on an Autonomous Database
Dedicated infrastructure.
We also advise that you limit the number of databases you provision
to meet your preferred SLA. To meet the high availability SLA, we
recommend a maximum of 100 databases. To meet the extreme
availability SLA, we recommend a maximum of 25 databases.
12:35
Nikita: Ok, so now that I know all this, how do I actually get
started with Autonomous Database on dedicated infrastructure?
Maria: You need to increase your service limit to include that
Exadata infrastructure and then you need to create the fleet and
DBA service roles. You also need to create the necessary network
model, VM clusters, and container databases for your
organization.
Finally, you need to provide access to the end users who want to
create and use those Autonomous databases. Autonomous Database
requires a subscription to that Exadata infrastructure for a
minimum of 48 hours. But once subscribed, you can test out ideas
and then terminate the subscription with no ongoing costs. While
subscribed, you can control where you place the resources to
perhaps manage latency sensitive applications.
13:29
Maria: You can also have control over patching schedules, software
versions, so you can be sure that you're testing exactly what you
need to. You can also migrate databases to the Autonomous Database
via our export, import capabilities via the object store or through
Data Pump or Golden Gate. As with any Autonomous Database, once
it's provisioned, you've got full access to both autoscaling and
all our cloning capabilities.
13:57
Lois: Maria, I've heard you talk about the importance of clean role
separation in managing a private cloud. Can you elaborate on that,
please?
Maria: A successful private cloud is set up and managed using clean
role separation between the fleet administration group and the
developers, or DBA groups. The fleet administration group
establishes the governance constraints, including things like
budgeting, capacity compliance, and SLAs, according to the business
structure. The physical resources are also logically grouped to
align with this business structure, and then groups of users are
given self-service access to the resources within these groups. So
a good example of this would be that the developers and DBA groups
use self-service database resources within these constraints.
14:46
Nikita: I see. So, what exactly does a fleet administrator do?
Maria: Fleet administrators allocate budget by department and are
responsible for the creation, monitoring, and management of the
autonomous exadata infrastructure, the autonomous exadata VM
clusters, and the autonomous container databases. To perform these
duties, the fleet administrators must have an Oracle Cloud account
or user, and that user must have permissions to manage these
resources and be permitted to use network resources that need to be
specified when you create these other resources.
15:24
Nikita: And what about database administrators?
Maria: Database administrators create, monitor, and manage
autonomous databases. They, too, need to have an Oracle Cloud
account or be an Oracle Cloud user. Now, those accounts need to
have the necessary permissions in order to create and access
databases. They also need to be able to access autonomous backups
and have permission to access the autonomous container databases,
inside which these autonomous databases will be created, and have
all of the necessary permissions to be able to create those
databases, as I said.
While creating autonomous databases, the database administrators
will define and gain access to an admin user account inside the
database. It's through this account that they will actually get the
necessary permissions to be able to create and control database
users.
16:24
Lois: How do developers fit into the picture?
Maria: Database users and developers who write applications that
will use or access an autonomous database don't actually need
Oracle Cloud accounts. They'll actually be given the network
connectivity and authorization information they need to access
those databases by the database administrators.
16:45
Lois: Maria, you mentioned the various ways to manage the lifecycle
of an autonomous dedicated service. Can you tell us more about
that?
Maria: You can manage the lifecycle of an autonomous dedicated
service through the Cloud UI, Command Line Interface, through our
REST APIs, or through one of the several language SDKs. The
lifecycle operations that you can manage include capacity planning
and setup, the provisioning and partitioning of exadata
infrastructure, the provisioning and management of databases, the
scaling of CPU storage and other resources, the scheduling of
updates for the infrastructure, the VMs, and the database, as well
as monitoring through event notifications.
17:30
Lois: And how do policies come into play?
Maria: OCI allows fine-grained control over resources through the
application of policies to groups. These policies are applicable to
any member of the group.
For Oracle Autonomous Database on dedicated infrastructure, the
resources in question are autonomous exadata infrastructure,
autonomous container databases, autonomous databases, and
autonomous backups.
Lois: Thanks so much, Maria. That was great information.
18:05
The Oracle University Learning Community is a great place for you
to collaborate and learn with experts, peers, and practitioners.
Grow your skills, inspire innovation, and celebrate your successes.
The more you participate, the more recognition you can earn. All of
your activities, from liking a post to answering questions and
sharing with others, will help you earn badges and ranks, and be
recognized within the community.
If you are already an Oracle MyLearn user, go to MyLearn to join
the community. You will need to log in first. If you have not yet
accessed Oracle MyLearn, visit mylearn.oracle.com and create an
account to get started.
18:44
Nikita: Welcome back! Hi Kamryn, thanks for joining us on the
podcast. So, in an Autonomous Database environment where most DBA
tasks are automated, what exactly does an application DBA do?
Kamryn: While Autonomous Database automates most of the repetitive
tasks that DBAs perform, the application DBA will still want to
monitor and diagnose databases for applications to maintain the
highest performance and the greatest security possible.
Tasks the application DBA performs includes operations on
databases, cloning, movement, monitoring, and creating alerts. When
required, the application DBA performs low-level diagnostics for
application performance and looks for insights on performance and
capacity trends.
19:36
Nikita: I see. And which tools do they use for these tasks?
Kamryn: There are several tools at the application DBA's disposal,
including Enterprise Manager, Performance Hub, and the OCI
Console.
For Autonomous Dedicated, all the database operations are exposed
through the console UI and available through REST API calls,
including provisioning, stop/start, lifecycle operations for
dedicated database types, unscheduled on-demand backups and
restores, CPU scaling and storage management, providing
connectivity information, including wallets, scheduling
updates.
20:17
Lois: So, Kamryn, what tools can DBAs use for deeper
exploration?
Kamryn: For deeper exploration of the databases themselves,
Autonomous Database DBAs can use SQL Developer Web, Performance
Hub, and Enterprise Manager.
20:31
Nikita: Let’s bring Kay into the conversation. Hi Kay! With
Autonomous Database Dedicated, I’ve heard that customers have more
control over patching. Can you tell us a little more about
that?
Kay: With Autonomous Database Dedicated, customers get to determine
the update or patching schedule if they wish. Oracle automatically
manages all patching activity, but with the ADB-Dedicated service,
customers have the option of customizing the patching schedule. You
can specify which month in every quarter you want, which week in
that month, which day in that month, and which patching window
within that day. You can also dynamically change the scheduled
patching date and time for a specific database if the originally
scheduled time becomes inconvenient.
21:22
Lois: That's great! So, how often are updates published, and what
options do customers have when it comes to applying these
updates?
Kay: Every quarter, updates are published to the console, and OCI
notifications are sent out. ADB-Dedicated allows for greater
control over updates by allowing you to choose to apply the current
update or stay with the previous version and skip to the next
release. And the latest update can be applied immediately. This
provides fleet administrators with the option to maintain test and
production systems at different patch levels.
A fleet administrator or a database admin sets up the software
version policy at the Autonomous Container Database level during
provisioning, although the defaults can be modified at any time for
an existing Autonomous Container Database. At the bottom of the
Autonomous Exadata Infrastructure provisioning screen, you will see
a Configure the Automatic Maintenance section, where you should
click the Modify Schedule.
22:34
Nikita: What happens if a customer doesn't customize their patching
schedule?
Kay: If you do not customize a schedule, it behaves like Autonomous
Serverless, and Oracle will set a schedule for you. ADB-Dedicated
customers get to choose the patching schedule that fits their
business.
22:52
Lois: Back to you, Kamryn, I know a bit about Transparent Data
Encryption, but I'm curious to learn more. Can you tell me what it
does and how it helps protect data?
Kamryn: Transparent Data Encryption, TDE, enables you to encrypt
sensitive data that you store in tables and tablespaces. After the
data is encrypted, this data is transparently decrypted for
authorized users or applications when they access this data. TDE
helps protect data stored on media, also called data at rest. If
the storage media or data file is stolen, Oracle database uses
authentication, authorization, and auditing mechanisms to secure
data in the database, but not in the operating system data files
where data is stored. To protect these data files, Oracle database
provides TDE.
23:45
Nikita: That sounds important for data security. So, how does TDE
protect data files?
Kamryn: TDE encrypts sensitive data stored in data files. To
prevent unauthorized decryption, TDE stores the encryption keys in
a security module external to the database called a keystore.
You can configure Oracle Key Vault as part of the TDE
implementation. This enables you to centrally manage TDE key
stores, called TDE wallets, in Oracle Key Vault in your enterprise.
For example, you can upload a software keystore to Oracle Key Vault
and then make the contents of this keystore available to other
TDE-enabled databases.
24:28
Lois: What about Oracle Autonomous Database? How does it handle
encryption?
Kamryn: Oracle Autonomous Database uses always-on encryption that
protects data at rest and in transit. All data stored in Oracle
Cloud and network communication with Oracle Cloud is encrypted by
default. Encryption cannot be turned off.
By default, Oracle Autonomous Database creates and manages all the
master encryption keys used to protect your data, storing them in a
secure PKCS 12 keystore on the same Exadata systems where the
databases reside. If your company's security policies require,
Oracle Autonomous Database can instead use keys you create and
manage. Customers can control key generation and rotation of the
keys.
25:19
Kamryn: The Autonomous databases you create automatically use
customer-managed keys because the Autonomous container database in
which they are created is configured to use customer-managed keys.
Thus, those users who create and manage Autonomous databases do not
have to worry about configuring their databases to use
customer-managed keys.
25:41
Nikita: Thank you so much, Kamryn, Kay, and Maria for taking the
time to give us your insights. To learn more about provisioning
Autonomous Database Dedicated resources, head over to
mylearn.oracle.com and search for the Oracle Autonomous Database
Administration Workshop.
Lois: In our next episode, we will discuss Autonomous Database
tools. Until then, this is Lois Houston…
Nikita: …and Nikita Abraham signing off.
26:07
That’s all for this episode of the Oracle University Podcast. If
you enjoyed listening, please click Subscribe to get all the latest
episodes. We’d also love it if you would take a moment to rate and
review us on your podcast app. See you again on the next episode of
the Oracle University Podcast.