{"id":3670,"date":"2014-03-23T15:04:39","date_gmt":"2014-03-23T14:04:39","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/the-consequences-of-nologging-in-oracle\/"},"modified":"2014-03-23T15:04:39","modified_gmt":"2014-03-23T14:04:39","slug":"the-consequences-of-nologging-in-oracle","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/the-consequences-of-nologging-in-oracle\/","title":{"rendered":"The consequences of NOLOGGING in Oracle"},"content":{"rendered":"<h2>By Franck Pachot<\/h2>\n<p>.<br \/>\nWhile answering to a <a href=\"https:\/\/community.oracle.com\/message\/12335937#12335937\">question<\/a> on Oracle forum about NOLOGGING consequences, I provided a test case that deserves a bit more explanation. Nologging operations are good to generate minimal redo on bulk operations (direct-path inserts, index creation\/rebuild). But in case we have to restore a backup that was made before the nologging operation, we loose data. And even if we can accept that, we have some manual operations to do.<\/p>\n<p>Here is the full testcase.<\/p>\n<p>I create a tablespace and backup it:<\/p>\n<pre><code><samp><\/samp>RMAN&gt;\u00a0create\u00a0tablespace\u00a0demo\u00a0datafile\u00a0'\/tmp\/demo.dbf'\u00a0size\u00a010M; \nStatement\u00a0processed\nRMAN&gt;\u00a0backup\u00a0tablespace\u00a0demo; \nStarting\u00a0backup\u00a0at\u00a023-MAR-14 \nallocated\u00a0channel:\u00a0ORA_DISK_1 \nchannel\u00a0ORA_DISK_1:\u00a0SID=30\u00a0device\u00a0type=DISK \nchannel\u00a0ORA_DISK_1:\u00a0starting\u00a0full\u00a0datafile\u00a0backup\u00a0set \nchannel\u00a0ORA_DISK_1:\u00a0specifying\u00a0datafile(s)\u00a0in\u00a0backup\u00a0set \ninput\u00a0datafile\u00a0file\u00a0number=00005\u00a0name=\/tmp\/demo.dbf \nchannel\u00a0ORA_DISK_1:\u00a0starting\u00a0piece\u00a01\u00a0at\u00a023-MAR-14 \nchannel\u00a0ORA_DISK_1:\u00a0finished\u00a0piece\u00a01\u00a0at\u00a023-MAR-14 \npiece\u00a0handle=\/u01\/app\/oracle\/fast_recovery_area\/U1\/backupset\/2014_03_23\/o1_mf_nnndf_TAG20140323T160453_9lxy0pfb_.bkp\u00a0tag=TAG20140323T160453\u00a0comment=NONE \nchannel\u00a0ORA_DISK_1:\u00a0backup\u00a0set\u00a0complete,\u00a0elapsed\u00a0time:\u00a000:00:01 \nFinished\u00a0backup\u00a0at\u00a023-MAR-14<\/code><\/pre>\n<p>I create a table and an index, both in NOLOGGING<\/p>\n<pre><code><samp><\/samp>RMAN&gt;\u00a0create\u00a0table\u00a0demo\u00a0(\u00a0dummy\u00a0not\u00a0null\u00a0)\u00a0tablespace\u00a0demo\u00a0nologging\u00a0as\u00a0select\u00a0*\u00a0from\u00a0dual\u00a0connect\u00a0by\u00a0level\u00a0Statement\u00a0processed\nRMAN&gt;\u00a0create\u00a0index\u00a0demo\u00a0on\u00a0demo(dummy)\u00a0tablespace\u00a0demo\u00a0nologging; \nStatement\u00a0processed<\/code><\/pre>\n<p>Note how I like 12c for doing anything from RMAN&#8230;<br \/>\nBecause I will need it later, I do a treedump of my index:<\/p>\n<pre><code><samp><\/samp>RMAN&gt;\u00a0begin \n2&gt;\u00a0\u00a0for\u00a0o\u00a0in\u00a0(select\u00a0object_id\u00a0from\u00a0dba_objects\u00a0where\u00a0owner=user\u00a0and\u00a0object_name='DEMO'\u00a0and\u00a0object_type='INDEX') \n3&gt;\u00a0\u00a0\u00a0loop\u00a0execute\u00a0immediate\u00a0'alter\u00a0session\u00a0set\u00a0tracefile_identifier=''treedump''\u00a0events\u00a0''immediate\u00a0trace\u00a0name\u00a0treedump\u00a0level\u00a0'||o.object_id||''''; \n4&gt;\u00a0end\u00a0loop; \n5&gt;\u00a0end; \n6&gt;\u00a0\/ \nStatement\u00a0processed<\/code><\/pre>\n<p>Here is the content of my treedump trace file:<\/p>\n<pre><code><samp><\/samp>-----\u00a0begin\u00a0tree\u00a0dump \nbranch:\u00a00x140008b\u00a020971659\u00a0(0:\u00a0nrow:\u00a02,\u00a0level:\u00a01) \n\u00a0\u00a0\u00a0leaf:\u00a00x140008c\u00a020971660\u00a0(-1:\u00a0nrow:\u00a0552\u00a0rrow:\u00a0552) \n\u00a0\u00a0\u00a0leaf:\u00a00x140008d\u00a020971661\u00a0(0:\u00a0nrow:\u00a0448\u00a0rrow:\u00a0448) \n-----\u00a0end\u00a0tree\u00a0dump<\/code><\/pre>\n<p>Because of the nologging, the tablespace is &#8216;unrecoverable&#8217; and we will see what it means.<\/p>\n<pre><code><samp><\/samp>RMAN&gt;\u00a0report\u00a0unrecoverable; \nReport\u00a0of\u00a0files\u00a0that\u00a0need\u00a0backup\u00a0due\u00a0to\u00a0unrecoverable\u00a0operations \nFile\u00a0Type\u00a0of\u00a0Backup\u00a0Required\u00a0Name \n----\u00a0-----------------------\u00a0----------------------------------- \n5\u00a0\u00a0\u00a0\u00a0full\u00a0or\u00a0incremental\u00a0\u00a0\u00a0\u00a0\u00a0\/tmp\/demo.dbf<\/code><\/pre>\n<p>RMAN tells me that I need to do a backup, which is the right thing to do after nologging operations. But here my goal is to show what happens when we have to restore a backup that was done before the nologging operations.<\/p>\n<p>I want to show that the issue does not only concern the data that I&#8217;ve loaded, but any data that may come later in the blocks that have been formatted by the nologging operation. So I&#8217;m deleteing the rows and inserting a new one.<\/p>\n<pre><code><samp><\/samp>2&gt;\u00a0delete\u00a0from\u00a0demo; \nStatement\u00a0processed\nRMAN&gt;\u00a0insert\u00a0into\u00a0demo\u00a0select\u00a0*\u00a0from\u00a0dual; \nStatement\u00a0processed<\/code><\/pre>\n<p>Time to restore the tablespace from the backup that has been done before the nologging operation:<\/p>\n<pre><code><samp><\/samp>RMAN&gt;\u00a0alter\u00a0tablespace\u00a0demo\u00a0offline; \nStatement\u00a0processed\nRMAN&gt;\u00a0restore\u00a0tablespace\u00a0demo; \nStarting\u00a0restore\u00a0at\u00a023-MAR-14 \nusing\u00a0channel\u00a0ORA_DISK_1\nchannel\u00a0ORA_DISK_1:\u00a0starting\u00a0datafile\u00a0backup\u00a0set\u00a0restore \nchannel\u00a0ORA_DISK_1:\u00a0specifying\u00a0datafile(s)\u00a0to\u00a0restore\u00a0from\u00a0backup\u00a0set \nchannel\u00a0ORA_DISK_1:\u00a0restoring\u00a0datafile\u00a000005\u00a0to\u00a0\/tmp\/demo.dbf \nchannel\u00a0ORA_DISK_1:\u00a0reading\u00a0from\u00a0backup\u00a0piece\u00a0\/u01\/app\/oracle\/fast_recovery_area\/U1\/backupset\/2014_03_23\/o1_mf_nnndf_TAG20140323T160453_9lxy0pfb_.bkp \nchannel\u00a0ORA_DISK_1:\u00a0piece\u00a0handle=\/u01\/app\/oracle\/fast_recovery_area\/U1\/backupset\/2014_03_23\/o1_mf_nnndf_TAG20140323T160453_9lxy0pfb_.bkp\u00a0tag=TAG20140323T160453 \nchannel\u00a0ORA_DISK_1:\u00a0restored\u00a0backup\u00a0piece\u00a01 \nchannel\u00a0ORA_DISK_1:\u00a0restore\u00a0complete,\u00a0elapsed\u00a0time:\u00a000:00:01 \nFinished\u00a0restore\u00a0at\u00a023-MAR-14\nRMAN&gt;\u00a0recover\u00a0tablespace\u00a0demo; \nStarting\u00a0recover\u00a0at\u00a023-MAR-14 \nusing\u00a0channel\u00a0ORA_DISK_1\nstarting\u00a0media\u00a0recovery \nmedia\u00a0recovery\u00a0complete,\u00a0elapsed\u00a0time:\u00a000:00:00\nFinished\u00a0recover\u00a0at\u00a023-MAR-14\nRMAN&gt;\u00a0alter\u00a0tablespace\u00a0demo\u00a0online; \nStatement\u00a0processed<\/code><\/pre>\n<p>We can check the unrecoverable tablespace<\/p>\n<pre><code><samp><\/samp>RMAN&gt;\u00a0report\u00a0unrecoverable; \nReport\u00a0of\u00a0files\u00a0that\u00a0need\u00a0backup\u00a0due\u00a0to\u00a0unrecoverable\u00a0operations \nFile\u00a0Type\u00a0of\u00a0Backup\u00a0Required\u00a0Name \n----\u00a0-----------------------\u00a0----------------------------------- \n5\u00a0\u00a0\u00a0\u00a0full\u00a0or\u00a0incremental\u00a0\u00a0\u00a0\u00a0\u00a0\/tmp\/demo.dbf<\/code><\/pre>\n<p>but we don&#8217;t know which objects are concerned until we try to read from them:<\/p>\n<pre><code><samp><\/samp>RMAN&gt;\u00a0select\u00a0\/*+\u00a0full(demo)\u00a0*\/\u00a0count(*)\u00a0from\u00a0demo; \nRMAN-00571:\u00a0=========================================================== \nRMAN-00569:\u00a0===============\u00a0ERROR\u00a0MESSAGE\u00a0STACK\u00a0FOLLOWS\u00a0=============== \nRMAN-00571:\u00a0=========================================================== \nRMAN-03002:\u00a0failure\u00a0of\u00a0sql\u00a0statement\u00a0command\u00a0at\u00a003\/23\/2014\u00a016:05:03 \nORA-01578:\u00a0ORACLE\u00a0data\u00a0block\u00a0corrupted\u00a0(file\u00a0#\u00a05,\u00a0block\u00a0#\u00a0131) \nORA-01110:\u00a0data\u00a0file\u00a05:\u00a0'\/tmp\/demo.dbf' \nORA-26040:\u00a0Data\u00a0block\u00a0was\u00a0loaded\u00a0using\u00a0the\u00a0NOLOGGING\u00a0option\nRMAN&gt;\u00a0select\u00a0\/*+\u00a0index(demo)\u00a0*\/\u00a0count(*)\u00a0from\u00a0demo; \nRMAN-00571:\u00a0=========================================================== \nRMAN-00569:\u00a0===============\u00a0ERROR\u00a0MESSAGE\u00a0STACK\u00a0FOLLOWS\u00a0=============== \nRMAN-00571:\u00a0=========================================================== \nRMAN-03002:\u00a0failure\u00a0of\u00a0sql\u00a0statement\u00a0command\u00a0at\u00a003\/23\/2014\u00a016:05:04 \nORA-01578:\u00a0ORACLE\u00a0data\u00a0block\u00a0corrupted\u00a0(file\u00a0#\u00a05,\u00a0block\u00a0#\u00a0140) \nORA-01110:\u00a0data\u00a0file\u00a05:\u00a0'\/tmp\/demo.dbf' \nORA-26040:\u00a0Data\u00a0block\u00a0was\u00a0loaded\u00a0using\u00a0the\u00a0NOLOGGING\u00a0option<\/code><\/pre>\n<p>So I can&#8217;t read from the table because of block (file # 5, block # 131) which is corrupted and I can&#8217;t read from the index because of block (file # 5, block # 140) which is corrupted. The reason is that recovery was not possible on them as there was no redo to protect them from the time they were formatted (by the nologging operation).<\/p>\n<p>Let&#8217;s see which blocks were reported:<\/p>\n<pre><code><samp><\/samp>RMAN&gt;\u00a0select\u00a0segment_type,header_file,header_block\u00a0,\u00a0dbms_utility.make_data_block_address(header_file,header_block)\u00a0from\u00a0dba_segments\u00a0where\u00a0owner=user\u00a0and\u00a0segment_name='DEMO'; \nSEGMENT_TYPE\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0HEADER_FILE\u00a0HEADER_BLOCK \n------------------\u00a0-----------\u00a0------------ \nDBMS_UTILITY.MAKE_DATA_BLOCK_ADDRESS(HEADER_FILE,HEADER_BLOCK) \n-------------------------------------------------------------- \nINDEX\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a05\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0138 \n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a020971658\nTABLE\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a05\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0130 \n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a020971650\nRMAN&gt;\u00a0select\u00a0dbms_utility.make_data_block_address(5,\u00a0140)\u00a0from\u00a0dual;\nDBMS_UTILITY.MAKE_DATA_BLOCK_ADDRESS(5,140) \n------------------------------------------- \n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a020971660<\/code><\/pre>\n<p>The full scan failed as soon as it reads the block 131 which is the first one that contains data. The segment header block itself was protected by redo.<\/p>\n<p>For the index the query failed on block 140 which is the first leaf (this is why I did a treedump above). The root branch (which is always the next after the segment header) seem to be protected by redo even for nologging operation. The reason why I checked that is because in the first testcase I posted in the forum, I had a very small table for which the index was so small that it had only one leaf &#8211; which is the root branch as well &#8211; so the index was still recovrable.<\/p>\n<p>The important point to know is that the index is still valid:<\/p>\n<pre><code><samp><\/samp>RMAN&gt;\u00a0select\u00a0status\u00a0from\u00a0all_indexes\u00a0where\u00a0index_name='DEMO'; \nSTATUS\u00a0\u00a0 \n-------- \nVALID<\/code><\/pre>\n<p>And the only solution is to truncate the table:<\/p>\n<pre><code><samp><\/samp>RMAN&gt;\u00a0truncate\u00a0table\u00a0demo; \nStatement\u00a0processed\nRMAN&gt;\u00a0select\u00a0\/*+\u00a0full(demo)\u00a0*\/\u00a0count(*)\u00a0from\u00a0demo; \n\u00a0\u00a0COUNT(*) \n---------- \n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a00\nRMAN&gt;\u00a0select\u00a0\/*+\u00a0index(demo)\u00a0*\/\u00a0count(*)\u00a0from\u00a0demo; \n\u00a0\u00a0COUNT(*) \n---------- \n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a00<\/code><\/pre>\n<p>no corruption anymore, but no data either&#8230;<\/p>\n<p>Last point: if you have only the indexes that are unrecoverable, you can rebuild them. But because the index is valid, Oracle will try to read it in order to rebuild it &#8211; and fail with ORA-26040. You have to make then unusable before.<\/p>\n<p>The core message is:<\/p>\n<ul>\n<li>Use nologging only when you accept to loose data and you accept to have some manual operations to do after recovery (so document it): truncate table, make indexes unusable and rebuild.<\/li>\n<li>Backup the unrecoverable tablespaces as soon as you can after your nologging operations<\/li>\n<li>If you need redo for other goals (such as standby database) use force logging.<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>By Franck Pachot . While answering to a question on Oracle forum about NOLOGGING consequences, I provided a test case that deserves a bit more explanation. Nologging operations are good to generate minimal redo on bulk operations (direct-path inserts, index creation\/rebuild). But in case we have to restore a backup that was made before the [&hellip;]<\/p>\n","protected":false},"author":27,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[198,59],"tags":[96,226],"type_dbi":[],"class_list":["post-3670","post","type-post","status-publish","format-standard","hentry","category-database-management","category-oracle","tag-oracle","tag-recovery"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v27.2 (Yoast SEO v27.4) - https:\/\/yoast.com\/product\/yoast-seo-premium-wordpress\/ -->\n<title>The consequences of NOLOGGING in Oracle - dbi Blog<\/title>\n<meta name=\"description\" content=\"The consequences of nologging operations in Oracle\" \/>\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\/the-consequences-of-nologging-in-oracle\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"The consequences of NOLOGGING in Oracle\" \/>\n<meta property=\"og:description\" content=\"The consequences of nologging operations in Oracle\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/the-consequences-of-nologging-in-oracle\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2014-03-23T14:04:39+00:00\" \/>\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=\"6 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\\\/the-consequences-of-nologging-in-oracle\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/the-consequences-of-nologging-in-oracle\\\/\"},\"author\":{\"name\":\"Oracle Team\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/66ab87129f2d357f09971bc7936a77ee\"},\"headline\":\"The consequences of NOLOGGING in Oracle\",\"datePublished\":\"2014-03-23T14:04:39+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/the-consequences-of-nologging-in-oracle\\\/\"},\"wordCount\":599,\"commentCount\":0,\"keywords\":[\"Oracle\",\"Recovery\"],\"articleSection\":[\"Database management\",\"Oracle\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/the-consequences-of-nologging-in-oracle\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/the-consequences-of-nologging-in-oracle\\\/\",\"url\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/the-consequences-of-nologging-in-oracle\\\/\",\"name\":\"The consequences of NOLOGGING in Oracle - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#website\"},\"datePublished\":\"2014-03-23T14:04:39+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/#\\\/schema\\\/person\\\/66ab87129f2d357f09971bc7936a77ee\"},\"description\":\"The consequences of nologging operations in Oracle\",\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/the-consequences-of-nologging-in-oracle\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/the-consequences-of-nologging-in-oracle\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/the-consequences-of-nologging-in-oracle\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\\\/\\\/www.dbi-services.com\\\/blog\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"The consequences of NOLOGGING in Oracle\"}]},{\"@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":"The consequences of NOLOGGING in Oracle - dbi Blog","description":"The consequences of nologging operations in Oracle","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\/the-consequences-of-nologging-in-oracle\/","og_locale":"en_US","og_type":"article","og_title":"The consequences of NOLOGGING in Oracle","og_description":"The consequences of nologging operations in Oracle","og_url":"https:\/\/www.dbi-services.com\/blog\/the-consequences-of-nologging-in-oracle\/","og_site_name":"dbi Blog","article_published_time":"2014-03-23T14:04:39+00:00","author":"Oracle Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Oracle Team","Est. reading time":"6 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/the-consequences-of-nologging-in-oracle\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/the-consequences-of-nologging-in-oracle\/"},"author":{"name":"Oracle Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"headline":"The consequences of NOLOGGING in Oracle","datePublished":"2014-03-23T14:04:39+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/the-consequences-of-nologging-in-oracle\/"},"wordCount":599,"commentCount":0,"keywords":["Oracle","Recovery"],"articleSection":["Database management","Oracle"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/the-consequences-of-nologging-in-oracle\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/the-consequences-of-nologging-in-oracle\/","url":"https:\/\/www.dbi-services.com\/blog\/the-consequences-of-nologging-in-oracle\/","name":"The consequences of NOLOGGING in Oracle - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2014-03-23T14:04:39+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"description":"The consequences of nologging operations in Oracle","breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/the-consequences-of-nologging-in-oracle\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/the-consequences-of-nologging-in-oracle\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/the-consequences-of-nologging-in-oracle\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"The consequences of NOLOGGING in Oracle"}]},{"@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\/3670","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=3670"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/3670\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=3670"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=3670"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=3670"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=3670"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}