[SOUND] Welcome to Oracle University's Oracle Cloud infrastructure course on Oracle Autonomous Database. I'm going to talk to you about the various offerings available in autonomous database. My name is Kay Malcolm, I am a Senior Director of database product management. Here at Oracle, let's get started. The autonomous database completely revolutionizes data management. It allows you to focus on innovating your business and designing and developing new features and functions without having to worry about the full stack administration costs. We provide the ability to service maintain and manage the underlying infrastructure on which your data workload is running, so that you can focus on innovation and working on your application requirements. We also ensure data safety by eliminating many of the cyber attack vulnerabilities. And we're also able to meet service level objectives with three nines of availability. Now that's quite a tall order for a new product. But then when you think about it, we have been on this journey for over 20 years starting in Oracle Database nine AI. We began to introduce and matured many sophisticated automation capabilities from memory management to workload monitoring and tuning them. All of which are youth in the autonomous database continuing to our most recent release, database 21c. But it's not just the database management that Oracle has been automating. We've also spent the last decade working on the database infrastructure with our engineered systems. These engineered systems provide the best platform for the Oracle database as they are the only pre configured, pre tested and optimized platform for the database. Oracle ADB is actually a family of cloud services with each member of the family optimized for a particular workload. The first member of our family is the Autonomous Data Warehouse, or ADW. This has been optimized for analytic workloads like data warehouse Data Mars are is part of a data lake. The second member of the ADB family is Autonomous Transaction Processing or ATP. ATP is optimized for transaction processing or mixed workload environments. And makes an excellent platform for new application development. Autonomous database supports JavaScript Object Notation or JSON natively in the database, and it supports applications that use SOTA API's. To store and retrieve JSON data, or use SQL queries to store and retrieve data that's stored in JSON documents. Oracle autonomous JSON database or AJD. Is ATP but designed for developing NoSQL style applications that use JSON documents. You can promote an AJD or autonomous JSON database service to ATP. All members of the autonomous database family share the same fully automated. Highly performant exadata infrastructure that provides world class availability and scalability. They also share complete automation of all database administration tasks, such as provisioning. Patching security, backups, etc. ATP only differs from 80W when it comes to how we optimize each specific workload in the database. ADW is optimized for complex analytics while ATP is optimized For high throughput transaction processing, with 80W, you get a subset of database in memory and advanced analytics. Let's talk about data organisation. So when you start loading data into ADB, we store the data in the appropriate format for each workload. If it's ADW, we store the data in columnar format. That's best for analytics processing. If it's ATP, we store it in row format. And it's the best format for really fast single row lookups. Okay, let's cover data access. In ADW we use data summaries like storage indexes. On the extra data storage cells, and the Result Cache quickly accesses only the data that's needed for the query. In ATP indexes are used to access only the rows or the records that are needed for the transaction. Now let's have a chat about data processing, for analytics workloads. We automatically paralyze the query execution to access large volumes of data in a short amount of time to answer the most complex business questions. If it is a transaction processing system, then we automatically use indexes to quickly access the appropriate records. We also detect missing indexes and we create them for you. Okay memory, so when 80W, the data set is far too large to cache, so what we use memory for is to speed up large joins an aggregation says like group by statements. In ATP we use majority of the memory to cache the active data set to avoid any IO. We also use RDMA to access data directly in memory. On the other servers in the rack cluster, regardless of the workload, we need to keep optimizer statistics current to ensure that we get the most optimal execution plans. With ADW we are able to achieve this by gathering statistics as part of bulk load activities. Now with ATP data is added using more traditional insert statements and statistics are automatically gathered periodically. But as the data volumes change, or new access structures are created, there is potential for an execution plan to change, and any change could result in performance regression. So, what we do, we use Oracle SQL plan management to ensure that plans only change for the better. There are two physical deployment choices available to you. There's one deployment choice that we call autonomous database shared. And then the other deployment choice is called autonomous database dedicated. We're going to talk about these a lot in the next upcoming courses. But the easiest way to think about this. Is it autonomous database shared is a very simple and elastic small footprint to the large footprint version of the autonomous database versus the dedicated infrastructure, which is a customizable private Database Cloud in the public cloud. Another way to think of it if it's shared infrastructure means your autonomous database service will be running on an exadata system that is shared with other customers running their database workloads. Close on that same physical exit data box. Now rest assured your data is completely encrypted and isolated, and there is no way of anyone seeing a neighbor's data. The dedicated infrastructure on the other hand, is for tenants and customers who have workloads where they want complete control. Over the physical infrastructure in which they're laying down and running their data workload. Now, to drill into this more detail, the shared approach is really targeting simple workloads. A workload that could run on a single OCPU, for example, a workload that could run on a single OCPU, for example, can definitely benefit from this. It's much more elastic. We can start with one OCPU, we can grow all the way up to 128 OCPUs automatically and dynamically, and we can start small one terabyte of storage, and then expand that to beyond 100 terabytes of storage. And we have a very low time commitment. We can actually commit less than an hour, and it can automatically scale online for true pay per use. It's also possible to stop, it will be shared and not be billed for any OCPUs while the service is not running. Now dedicated on the other hand is as I mentioned, running on a fully dedicated exadata infrastructure, in the public cloud, it can run all your databases any size scale or criticality. And it definitely provides, the highest level of isolation because each one of your workloads, is running within your own zone. And it's physically separated from other tenants or other customers. Dedicated is definitely suitable for customers who have customizable operational requirements. You can control or you can have more control over when the systems are provisioned how your software is updated, as well as availability and density Have your servers that are being hosted in the autonomous database model. In a driven results first environment, autonomous database shared infrastructure is used by developers and data scientists. Whereas scenarios were the Architects and DBAs, rethink database it autonomous dedicated is primarily used. To wrap up, today I covered the autonomous database offerings available in the family of ADB solutions. Thanks for watching.
