{"id":13591,"date":"2020-03-29T15:33:56","date_gmt":"2020-03-29T13:33:56","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/"},"modified":"2020-03-29T15:33:56","modified_gmt":"2020-03-29T13:33:56","slug":"oracle-recovery-concepts","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/","title":{"rendered":"Oracle recovery concepts"},"content":{"rendered":"

I’ve published a while ago a twitter thead on some Oracle recovery concepts<\/a>. For those who are not following twitter, I’m putting the whole thread here:
\n <\/p>\n

🔴⏬ Here I start a thread about some Oracle Database concepts. We will see how far it goes\u200a-\u200aall questions\/comments welcome.<\/p>\n

🔴⏬ A database (or DBMS\u200a-\u200adatabase management system) stores (for short and long term) and manipulates (from many concurrent users\/devices) your\u00a0#data<\/a>.<\/p>\n

🔴⏬\u00a0#data<\/a>\u00a0is logically structured (tablespaces, schemas, tables, columns, datatypes, constraints,\u2026). The structure is described by\u00a0#metadata<\/a>.<\/p>\n

🔴⏬ Stored\u00a0#data<\/a>\u00a0(tables and indexes) is physically structured (blocks, extents, segments, datafiles), which is also maintained by\u00a0#metadata<\/a><\/p>\n

🔴⏬ The logical\u00a0#metadata<\/a>\u00a0and some physical\u00a0#metadata<\/a>\u00a0are stored in the\u00a0#dictionary<\/a>\u00a0,also known\u00a0#catalog<\/a><\/p>\n

🔴⏬ The\u00a0#dictionary<\/a>\u00a0is also data itself: it is the system data describing the user data. Its own metadata is fixed, hardcoded in the software for\u00a0#bootstrap<\/a><\/p>\n

🔴⏬ The set of persistent files that stores system data (metadata for user data) and user data is what we call (with Oracle) the\u00a0#database<\/a><\/p>\n

🔴⏬ The database files are internally referenced by an identifier (file_id, file#, Absolute File Number,…). The file names are not defined in the\u00a0#dictionary<\/a>\u00a0but (only) in the main metadata file for the database, the\u00a0#controlfile<\/a><\/p>\n

\n
\n
\n
\n
\"\"<\/a><\/div>\n<\/div>\n<\/div>\n<\/div>\n<\/div>\n

🔴⏬ So, we have user\u00a0#data<\/a>\u00a0and its\u00a0#metadata<\/a>\u00a0(system data) in\u00a0#datafiles<\/a>. Where is metadata for system data? The code that contains this metadata (structures), and the functions to manipulate data, is the database\u00a0#software<\/a><\/p>\n

🔴⏬ Oracle database software installed on the server is often referred by its install location environment variable, the\u00a0$ORACLE<\/a>_HOME<\/p>\n

🔴⏬ As with any software, the Oracle Database binary code is loaded by the OS to be run by multiple\u00a0#process<\/a>, which work in\u00a0#memory<\/a><\/p>\n

🔴⏬ The processes and memory running the Oracle software for one database system is what is called an Oracle\u00a0#instance<\/a><\/p>\n

🔴⏬ I think the\u00a0#instance<\/a>\u00a0was simply called the Oracle ‘system’ at some time as we identify with Oracle System ID (ORACLE_SID) and modify it with ALTER SYSTEM<\/p>\n

🔴⏬ The\u00a0#instance<\/a>\u00a0processes open the database files when needed, to read or write data (user\u00a0#data<\/a>\u00a0or\u00a0#metadata<\/a>), when started in state\u00a0#OPEN<\/a><\/p>\n

🔴⏬ Before being in\u00a0#OPEN<\/a>\u00a0state, where all database files are opened, the instance must read the list of database files from the\u00a0#controlfile<\/a>, when the state is\u00a0#MOUNT<\/a><\/p>\n

🔴⏬ Multiple instances can open the same database from different nodes, in the case of Real Application Cluster (RAC) and synchronizes themselves though the\u00a0#shared<\/a>\u00a0storage and the private network\u00a0#interconnect<\/a><\/p>\n

🔴⏬ For the instance to know which\u00a0#controlfile<\/a>\u00a0to read, we provide its name as an instance parameter, which is read when the instance is started in its first state:\u00a0#NOMOUNT<\/a><\/p>\n

🔴⏬Those parameters (memory sizes, database to open, flags…) are stored on the server in the instance configuration file, the server-side parameter file: the\u00a0#spfile<\/a><\/p>\n

🔴⏬ The\u00a0#spfile<\/a>\u00a0is in binary format, stored on the server, updated by the instance. When we create a new database we create the spfile from a\u00a0#pfile<\/a><\/p>\n

🔴⏬ The\u00a0#pfile<\/a>\u00a0is a simple text file that lists the instance parameter names and value (and comments). It is also referred to as\u00a0#init<\/a>.ora<\/p>\n

🔴⏬ So, the\u00a0#spfile<\/a>\u00a0or\u00a0#pfile<\/a>\u00a0is the instance metadata used to open the\u00a0#controlfile<\/a>, which is the database metadata, which is used to open the dictionary, which is the user data metadata used to\u2026 but at the root is the\u00a0$ORACLE<\/a>_SID<\/p>\n

🔴⏬\u00a0$ORACLE<\/a>_SID identifies which\u00a0#spfile<\/a>\u00a0or\u00a0#pfile<\/a>\u00a0to read when starting the instance in\u00a0#nomount<\/a>. It is an\u00a0#environment<\/a>\u00a0#variable<\/a><\/p>\n

🔴⏬ The instance will read by default, in\u00a0$ORACLE<\/a>_HOME\/dbs, spfile$ORACLE.SID or init$ORACLE_SID.ora or init.ora when not provided with a specific\u00a0#pfile<\/a><\/p>\n

🔴⏬ That’s for the first to start the\u00a0#instance<\/a>. But when the instance is running we can connect to it by attaching our process to the shared memory structure, called System Global Area:\u00a0#SGA<\/a><\/p>\n

🔴⏬ The\u00a0#SGA<\/a>\u00a0shared memory is identified with a key that is derived from ORACLE_SID and ORACLE_HOME. If no instance was started with the same ORACLE_SID and ORACLE_HOME (literally the same) you get a “connect to idle instance”<\/p>\n

🔴⏬ Of course, connecting by attaching to the SGA is possible only from the same host. This protocol is called\u00a0#bequeath<\/a>\u00a0connection<\/p>\n

🔴⏬ In order to connect remotely, there’s a process running on the server which knows the\u00a0$ORACLE<\/a>_SID and\u00a0$ORACLE<\/a>_HOME. It is the local\u00a0#listener<\/a><\/p>\n

🔴⏬ The local listener listens on a TCP\/IP port for incoming connection and handles the creation of process and attach to the SGA, just by being provided with the desired\u00a0#service_name<\/a><\/p>\n

🔴⏬ So, how does the local listener know which\u00a0#service_name<\/a>\u00a0goes to which instance (and then which database)? It can be listed in the listener’s configuration, that’s\u00a0#static<\/a>\u00a0registration<\/p>\n

🔴⏬ But in High Availability where multiple instances can run one service, it is the instance which tells it’s local listener which service it runs. That’s\u00a0#dynamic<\/a>\u00a0registration<\/p>\n

🔴⏬ Of course, the connection can start a session only when authorized (CREATE SESSION privilege) so the user\/password hash is verified and also the privileges. All this is stored in the dictionary. V$SESSION_CONNECT_INFO shows that as\u00a0#database<\/a>\u00a0#authentication<\/a><\/p>\n

🔴⏬ Database authentication can be done only when the database is opened (access to the dictionary). Not possible in\u00a0#nomount<\/a>\u00a0or\u00a0#mount<\/a>. For these, the system passwords are cached in a\u00a0#password<\/a>\u00a0file<\/p>\n

🔴⏬ The password file is found in\u00a0$ORACLE<\/a>_HOME\/dbs and its name is orapw$ORACLE_SID and, once created, changing of password must be done from the database to be sure it is in sync between dictionary and password file<\/p>\n

🔴⏬ When connecting locally with bequeath protocol, belonging to a privileged system group may be sufficient. The password provided is not even verified in that case. That uses\u00a0#OS<\/a>\u00a0authentication<\/p>\n

🔴⏬\u00a0#OS<\/a>\u00a0authentication is one case of passwordless authentication. By default, the Linux users in group ‘dba’ have passwordless bequeath (i.e local) access with the highest privilege\u00a0#sysdba<\/a><\/p>\n

🔴⏬ I said that data modifications are written to database files, but that would not be efficient when having multiple users because the database is\u00a0#shared<\/a><\/p>\n

🔴⏬ Reading from\u00a0#shared<\/a>\u00a0resources requires only a ‘share’ lock but the only way to write without corruption to a shared resource is with an\u00a0#exclusive<\/a>\u00a0lock<\/p>\n

🔴⏬ Locking a full portion of data to write directly to disk is done only for specific non-concurrent bulk loads (direct-path inserts like with APPEND hint). All conventional modifications are done in memory into shared\u00a0#buffers<\/a><\/p>\n

🔴⏬ Writing the modifications to disk is done asynchronously by a background process, the\u00a0#dbwriter<\/a><\/p>\n

🔴⏬ Reads are also going through the\u00a0#shared<\/a>\u00a0buffers to be sure to see the current version. This is a\u00a0#logical<\/a>\u00a0read<\/p>\n

🔴⏬ If the buffer is not already in memory, then before the logical read, it must be read from disk with a\u00a0#physical<\/a>\u00a0read<\/p>\n

🔴⏬ Keeping many buffers in memory for a while also saves a lot of disk access which is usually latency expensive. This memory is stored in the\u00a0#SGA<\/a>\u00a0as the\u00a0#buffer<\/a>\u00a0cache<\/p>\n

🔴⏬ As the changes are written in memory (buffer cache), they can be lost in case of instance or server crash. To protect for this, all changes are logged to a\u00a0#log<\/a>\u00a0buffer<\/p>\n

🔴⏬ The log buffer is in memory and asynchronously flushed to persistent storage (disk), to the\u00a0#online<\/a>\u00a0redo logs (and, maybe, to some\u00a0#standby<\/a>\u00a0redo logs in remote locations).<\/p>\n

🔴⏬ When a user commits a transaction, the server must be sure that the redo which protects his changes is flushed to disk. If not, before saying ‘commit successful’ it waits on\u00a0#log<\/a>\u00a0file sync<\/p>\n

🔴⏬ When changes are written in memory (#buffer<\/a>\u00a0cache) the\u00a0#redo<\/a>\u00a0that protects it from an instance crash must be written to persistent storage before the change itself. This is\u00a0#WAL<\/a>\u00a0(Write Ahead Logging)<\/p>\n

🔴⏬ This redo is written by\u00a0#logwriter<\/a>. It must be fast because this is where the user may have to wait for physical writes. The advantage is that the writes are sequential, with higher throughput than the\u00a0#dbwriter<\/a>\u00a0which has to do\u00a0#random<\/a>\u00a0writes scattered in all datafiles<\/p>\n

🔴⏬ The\u00a0#redo<\/a>\u00a0log stream can be long as it contains all changes. But for server\/instance recovery we need only the redo for the changes that were not yet flushed to disk by\u00a0#dbwriter<\/a>, in the\u00a0#dirty<\/a>\u00a0blocks<\/p>\n

🔴⏬ The instance ensures that regularly all\u00a0#dirty<\/a>\u00a0buffers are flushed, so that the previous\u00a0#redo<\/a>\u00a0can be discarded. It is known as a\u00a0#checkpoint<\/a><\/p>\n

🔴⏬ That’s sufficient for instance recovery (redo the changes that were made only in memory and lost by the instance crash) but what if we lose or corrupt a\u00a0#datafile<\/a>, like\u00a0#media<\/a>\u00a0failure?<\/p>\n

🔴⏬ As with any\u00a0#persistent<\/a>\u00a0data, we must take backups (copy of files) so that, in case of some loss or corruption, we can\u00a0#restore<\/a>\u00a0in a predictable time.<\/p>\n

🔴⏬ After restoring the backup we need to apply the redo to roll forward the modifications that happened between the beginning of backup until the point of failure. That’s media\u00a0#recovery<\/a><\/p>\n

🔴⏬ The recovery may need more than the online redo logs for the changes between the restored backup and the last checkpoint. This is why before being overwritten, the online redo logs are\u00a0#archived<\/a><\/p>\n

🔴⏬ We always want to protect for instance failure (or all the database is inconsistent) but we can choose not to protect for media failure (and accept outage at backup and transaction loss at restore) when the database is in\u00a0#noarchivelog<\/a>\u00a0mode<\/p>\n

🔴⏬ If the redo cannot be written to disk, the database cannot accept more changes as it cannot ensure the D in ACID: transaction\u00a0#durability<\/a><\/p>\n

🔴⏬ As the online redo logs are allocated and formated at instance startup, they can always be written even if the filesystem is full (except if size of fs. is virtual). But they can be overwritten only when checkpoint made them inactive, or we wait on “checkpoint not complete”<\/p>\n

🔴⏬ In archive log mode, there’s another requirement to overwrite an online redo log: it must have been archived to ensure media recovery. If not yet archived, we wait on “file switch (archiving needed)”.<\/p>\n

🔴⏬ Archived logs are never overwritten. If the destination is full, the instance hangs. You need to move or backup them elsewhere. The most important to monitor is V$RECOVERY_AREA_USAGE so that PERCENT_SPACE_USED – PERCENT_SPACE_RECLAIMABLE never goes to 100% (stuck archiver)<\/p>\n

🔴⏬ How long to keep the archived logs or their backups? You need the redo from the latest backup you may want to restore: the backup retention window. When a database backup is obsolete, the previous archived logs become obsolete. RMAN knows that and you just “delete obsolete”<\/p>\n

🔴⏬ In the recovery area, files are managed by Oracle and you don’t need to “delete obsolete”. Obsolete files are automatically deleted when space is needed (“space pressure”). That’s the PERCENT_SPACE_RECLAIMABLE of V$RECOVERY_AREA_USAGE<\/p>\n

🔴⏬ at the end of recovery, the database state is recovered at the same state as it was at the point-in-time when the last applied redo was generated. Only some uncommitted changes are lost (those that were in log buffer, in memory, and now lost).<\/p>\n

🔴⏬ If the recovery reaches the point of failure, all new changes can continue from there. If not, because we can’t or just because we do a point-in-time recovery, the chain of redo is broken and we\u00a0#resetlogs<\/a>\u00a0to a new\u00a0#incarnation<\/a>.<\/p>\n

🔴⏬ At the end of recovery, the transactions that are not committed cannot continue (we lost the state of the session, probably some redo and block changes, and the connection to the user is lost) and must be un-done with\u00a0#rollback<\/a><\/p>\n

🔴⏬ Oracle does not store directly the\u00a0#rollback<\/a>\u00a0information in the redo stream like other databases, because\u00a0#rollback<\/a>\u00a0is also used for another reason: rollback a transaction or re-build a past version of a block.<\/p>\n

🔴⏬ When data is changed (in a memory buffer) the\u00a0#rollback<\/a>\u00a0information that can be used to build the previous version of the buffer is stored as special system data: the\u00a0#undo<\/a><\/p>\n

🔴⏬ Actually, the\u00a0#rollback<\/a>\u00a0segment is involved for all letters in ACID, mainly: Atomicity (if we cannot commit we must rollback) and Isolation (undo the uncommitted changes made by others)<\/p>\n

🔴⏬ Whether the\u00a0#redo<\/a>\u00a0is primarily optimized for a sequential access on time (replay all changes in the same order), the\u00a0#undo<\/a>\u00a0is optimized to be accessed by\u00a0#transaction<\/a>\u00a0(@jloracle<\/a>\u00a0Why Undo?\u00a0<\/span>https:\/\/jonathanlewis.wordpress.com\/2010\/02\/09\/why<\/span>-undo\/\u00a0\u2026<\/span><\/a>)<\/p>\n

🔴⏬In summary, changes made to data and undo blocks generate the\u00a0#redo<\/a>\u00a0for it, which is applied in memory to the buffer. This redo goes to disk asynchronously. When your changes are committed, the database guarantees that your redo reached the disk so that recovery is possible.<\/p>\n

🔴⏬ The rollforward + rollback is common to many databases, but some are faster than others there. PostgreSQL stores old versions in-place and this rollback phase is immediate. Oracle stores it in UNDO, checkpointed with data, but has to rollback all incomplete transactions.<\/p>\n

🔴⏬ Mysql InnoDB is similar to Oracle. SQL Server stores the undo with the redo, then may have to the transaction log from before the last checkpoint if transactions stay long Then rollforward time can be unpredictable. This changed recently with Accelerated Database Recovery.<\/p>\n

🔴⏬For an in-depth on Oracle recovery internals, there is this old document still around on internet archives. From Oracle7 – 25 years ago! – but the concepts are still valid.
\n\u00a0<\/span>https:\/\/pastebin.com\/n8emqu08<\/span>\u00a0<\/span><\/a>
\n🔴⏫
\nAny questions?<\/p>\n","protected":false},"excerpt":{"rendered":"

I’ve published a while ago a twitter thead on some Oracle recovery concepts. For those who are not following twitter, I’m putting the whole thread here:   🔴⏬ Here I start a thread about some Oracle Database concepts. We will see how far it goes\u200a-\u200aall questions\/comments welcome. 🔴⏬ A database (or DBMS\u200a-\u200adatabase management system) stores […]<\/p>\n","protected":false},"author":27,"featured_media":13592,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[59],"tags":[96,226],"type_dbi":[],"class_list":["post-13591","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oracle","tag-oracle","tag-recovery"],"acf":[],"yoast_head":"\nOracle recovery concepts - dbi Blog<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Oracle recovery concepts\" \/>\n<meta property=\"og:description\" content=\"I’ve published a while ago a twitter thead on some Oracle recovery concepts. For those who are not following twitter, I’m putting the whole thread here:   🔴⏬ Here I start a thread about some Oracle Database concepts. We will see how far it goes\u200a-\u200aall questions\/comments welcome. 🔴⏬ A database (or DBMS\u200a-\u200adatabase management system) stores […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2020-03-29T13:33:56+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/EKZYP9OW4AEEsWC.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1200\" \/>\n\t<meta property=\"og:image:height\" content=\"769\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Oracle Team\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Oracle Team\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"13 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/\"},\"author\":{\"name\":\"Oracle Team\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"headline\":\"Oracle recovery concepts\",\"datePublished\":\"2020-03-29T13:33:56+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/\"},\"wordCount\":2523,\"commentCount\":0,\"image\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/EKZYP9OW4AEEsWC.png\",\"keywords\":[\"Oracle\",\"Recovery\"],\"articleSection\":[\"Oracle\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/\",\"name\":\"Oracle recovery concepts - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/EKZYP9OW4AEEsWC.png\",\"datePublished\":\"2020-03-29T13:33:56+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/#primaryimage\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/EKZYP9OW4AEEsWC.png\",\"contentUrl\":\"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/EKZYP9OW4AEEsWC.png\",\"width\":1200,\"height\":769},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Oracle recovery concepts\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/\",\"name\":\"dbi Blog\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\",\"name\":\"Oracle Team\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g\",\"caption\":\"Oracle Team\"},\"url\":\"https:\/\/www.dbi-services.com\/blog\/author\/oracle-team\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"Oracle recovery concepts - dbi Blog","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/","og_locale":"en_US","og_type":"article","og_title":"Oracle recovery concepts","og_description":"I’ve published a while ago a twitter thead on some Oracle recovery concepts. For those who are not following twitter, I’m putting the whole thread here:   🔴⏬ Here I start a thread about some Oracle Database concepts. We will see how far it goes\u200a-\u200aall questions\/comments welcome. 🔴⏬ A database (or DBMS\u200a-\u200adatabase management system) stores […]","og_url":"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/","og_site_name":"dbi Blog","article_published_time":"2020-03-29T13:33:56+00:00","og_image":[{"width":1200,"height":769,"url":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/EKZYP9OW4AEEsWC.png","type":"image\/png"}],"author":"Oracle Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Oracle Team","Est. reading time":"13 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/"},"author":{"name":"Oracle Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"headline":"Oracle recovery concepts","datePublished":"2020-03-29T13:33:56+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/"},"wordCount":2523,"commentCount":0,"image":{"@id":"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/#primaryimage"},"thumbnailUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/EKZYP9OW4AEEsWC.png","keywords":["Oracle","Recovery"],"articleSection":["Oracle"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/","url":"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/","name":"Oracle recovery concepts - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/#primaryimage"},"image":{"@id":"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/#primaryimage"},"thumbnailUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/EKZYP9OW4AEEsWC.png","datePublished":"2020-03-29T13:33:56+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/#primaryimage","url":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/EKZYP9OW4AEEsWC.png","contentUrl":"https:\/\/www.dbi-services.com\/blog\/wp-content\/uploads\/sites\/2\/2022\/04\/EKZYP9OW4AEEsWC.png","width":1200,"height":769},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/oracle-recovery-concepts\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Oracle recovery concepts"}]},{"@type":"WebSite","@id":"https:\/\/www.dbi-services.com\/blog\/#website","url":"https:\/\/www.dbi-services.com\/blog\/","name":"dbi Blog","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.dbi-services.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee","name":"Oracle Team","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/f711f7cd2c9b09bf2627133755b569fb5be0694810cfd33033bdd095fedba86d?s=96&d=mm&r=g","caption":"Oracle Team"},"url":"https:\/\/www.dbi-services.com\/blog\/author\/oracle-team\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/13591","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/users\/27"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=13591"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/13591\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media\/13592"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=13591"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=13591"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=13591"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=13591"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}