{"id":5261,"date":"2015-08-25T14:53:31","date_gmt":"2015-08-25T12:53:31","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/fra-full-alerts-flood-alert-log\/"},"modified":"2015-08-25T14:53:31","modified_gmt":"2015-08-25T12:53:31","slug":"fra-full-alerts-flood-alert-log","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/fra-full-alerts-flood-alert-log\/","title":{"rendered":"&#8220;FRA full&#8221; alerts flood the Alert Log"},"content":{"rendered":"<p>We\u00a0discovered a strange behavior in the Alert Log\u00a0when the Fast Recovery Area (FRA) is full and the database wants to write something inside it (for example an archivelog).\u00a0This case concern <span style=\"text-decoration: underline\">Oracle 11.2.0.3 databases and higher<\/span>.<\/p>\n<p>Here is a demo with a 12c database (12.1.0.2) :<br \/>\nFirst, to reproduce the behavior, I set a very small size to the FRA :<\/p>\n<pre class=\"brush: sql; gutter: true; first-line: 1\">SQL&gt; alter system set db_recovery_file_dest_size = 1M;\n\nSystem altered.\n\nSQL&gt;<\/pre>\n<p>As you can see, the FRA is full :<\/p>\n<pre class=\"brush: sql; gutter: true; first-line: 1\">SQL&gt; select * from v$flash_recovery_area_usage;\n\nFILE_TYPE               PERCENT_SPACE_USED PERCENT_SPACE_RECLAIMABLE NUMBER_OF_FILES     CON_ID\n----------------------- ------------------ ------------------------- --------------- ----------\nCONTROL FILE                             0                         0               0          0\nREDO LOG                                 0                         0               0          0\nARCHIVED LOG                      15871.24                         0              41          0\nBACKUP PIECE                             0                         0               0          0\nIMAGE COPY                               0                         0               0          0\nFLASHBACK LOG                            0                         0               0          0\nFOREIGN ARCHIVED LOG                     0                         0               0          0\nAUXILIARY DATAFILE COPY                  0                         0               0          0\n\n8 rows selected.\n\nSQL&gt;<\/pre>\n<p>Next, I execute\u00a0a &#8220;switch logfile&#8221; to force a writing of an archive inside the FRA :<\/p>\n<pre class=\"brush: sql; gutter: true; first-line: 1\">SQL&gt; alter system switch logfile;\n\nSystem altered.\n\nSQL&gt;<\/pre>\n<p>The command works fine but a lot of trace files are generated on the <em>diag_dest<\/em> and&#8230; take a look in the alert.log ! :<\/p>\n<pre class=\"brush: actionscript3; gutter: true; first-line: 1\">...\n...\n...\nTue Aug 25 16:56:34 2015\n************************************************************************\nYou have following choices to free up space from recovery area:\n1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,\n   then consider changing RMAN ARCHIVELOG DELETION POLICY.\n2. Back up files to tertiary device such as tape using RMAN\n   BACKUP RECOVERY AREA command.\n3. Add disk space and increase db_recovery_file_dest_size parameter to\n   reflect the new space.\n4. Delete unnecessary files using RMAN DELETE command. If an operating\n   system command was used to delete files, then use RMAN CROSSCHECK and\n   DELETE EXPIRED commands.\n************************************************************************\nTue Aug 25 16:56:34 2015\nErrors in file \/u01\/app\/oracle\/diag\/rdbms\/jocdb1_site1\/JOCDB1\/trace\/JOCDB1_arc1_2767.trc:\nORA-19809: limit exceeded for recovery files\nORA-19804: cannot reclaim 20405760 bytes disk space from 1048576 limit\nARC1: Error 19809 Creating archive log file to '\/u90\/fast_recovery_area\/JOCDB1_SITE1\/archivelog\/2015_08_25\/o1_mf_1_268_%u_.arc'\nTue Aug 25 16:56:34 2015\nErrors in file \/u01\/app\/oracle\/diag\/rdbms\/jocdb1_site1\/JOCDB1\/trace\/JOCDB1_arc3_2771.trc:\nORA-19815: WARNING: db_recovery_file_dest_size of 1048576 bytes is 100.00% used, and has 0 remaining bytes available.\nTue Aug 25 16:56:34 2015\n************************************************************************\nYou have following choices to free up space from recovery area:\n1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,\n   then consider changing RMAN ARCHIVELOG DELETION POLICY.\n2. Back up files to tertiary device such as tape using RMAN\n   BACKUP RECOVERY AREA command.\n3. Add disk space and increase db_recovery_file_dest_size parameter to\n   reflect the new space.\n4. Delete unnecessary files using RMAN DELETE command. If an operating\n   system command was used to delete files, then use RMAN CROSSCHECK and\n   DELETE EXPIRED commands.\n************************************************************************\nTue Aug 25 16:56:34 2015\nErrors in file \/u01\/app\/oracle\/diag\/rdbms\/jocdb1_site1\/JOCDB1\/trace\/JOCDB1_arc3_2771.trc:\nORA-19809: limit exceeded for recovery files\nORA-19804: cannot reclaim 20405760 bytes disk space from 1048576 limit\nARC3: Error 19809 Creating archive log file to '\/u90\/fast_recovery_area\/JOCDB1_SITE1\/archivelog\/2015_08_25\/o1_mf_1_268_%u_.arc'\nTue Aug 25 16:56:34 2015\nErrors in file \/u01\/app\/oracle\/diag\/rdbms\/jocdb1_site1\/JOCDB1\/trace\/JOCDB1_arc0_2765.trc:\nORA-19815: WARNING: db_recovery_file_dest_size of 1048576 bytes is 100.00% used, and has 0 remaining bytes available.\nTue Aug 25 16:56:34 2015\n************************************************************************\nYou have following choices to free up space from recovery area:\n1. Consider changing RMAN RETENTION POLICY. If you are using Data Guard,\n   then consider changing RMAN ARCHIVELOG DELETION POLICY.\n2. Back up files to tertiary device such as tape using RMAN\n   BACKUP RECOVERY AREA command.\n3. Add disk space and increase db_recovery_file_dest_size parameter to\n   reflect the new space.\n4. Delete unnecessary files using RMAN DELETE command. If an operating\n   system command was used to delete files, then use RMAN CROSSCHECK and\n   DELETE EXPIRED commands.\n************************************************************************\nTue Aug 25 16:56:34 2015\nErrors in file \/u01\/app\/oracle\/diag\/rdbms\/jocdb1_site1\/JOCDB1\/trace\/JOCDB1_arc0_2765.trc:\nORA-19809: limit exceeded for recovery files\nORA-19804: cannot reclaim 20405760 bytes disk space from 1048576 limit\nARC0: Error 19809 Creating archive log file to '\/u90\/fast_recovery_area\/JOCDB1_SITE1\/archivelog\/2015_08_25\/o1_mf_1_268_%u_.arc'\nTue Aug 25 16:56:34 2015\nErrors in file \/u01\/app\/oracle\/diag\/rdbms\/jocdb1_site1\/JOCDB1\/trace\/JOCDB1_arc1_2767.trc:\nORA-19815: WARNING: db_recovery_file_dest_size of 1048576 bytes is 100.00% used, and has 0 remaining bytes available.\n...\n...\n...<\/pre>\n<p>As you can see, the &#8220;FRA full&#8221; message is written a lot of times per SECONDS !<br \/>\nThis behavior can have important consequences :<\/p>\n<ul>\n<li>Because of the high frequency of trace files generation (and in the same time the filling of the alert.log), the file system where the <em>diag_dest<\/em> is (here \/u01 in my demo) can be full before that the DBA have time to clean up or resize the FRA.<\/li>\n<li>Most of the time the <em>diag_dest<\/em> is in the same file system that the databases. And if this file system is full, databases will no longer run \ud83d\ude41<\/li>\n<\/ul>\n<p>Below, you can see the size evolution of the <em>alert<\/em>\u00a0and <em>trace<\/em>\u00a0folders after 15 seconds of &#8220;FRA full&#8221; :<\/p>\n<p><span style=\"text-decoration: underline\">Before<\/span> :<\/p>\n<pre class=\"brush: bash; gutter: true; first-line: 1\">oracle@srvtest:\/u01\/app\/oracle\/diag\/rdbms\/jocdb1_site1\/JOCDB1\/ [JOCDB1] du -sh alert trace\n12K alert\n5.4M trace<\/pre>\n<p><span style=\"text-decoration: underline\">After 15 seconds<\/span> :<\/p>\n<pre class=\"brush: bash; gutter: true; first-line: 1\">oracle@srvtest:\/u01\/app\/oracle\/diag\/rdbms\/jocdb1_site1\/JOCDB1\/ [JOCDB1] du -sh alert trace\n5.6M alert\n7.2M trace<\/pre>\n<p>I also monitored the system calls of the Arc process (with <em>strace<\/em>, during 2 minutes) :<\/p>\n<pre class=\"brush: bash; gutter: true; first-line: 1\">oracle@srvtest:\/home\/oracle\/ [JOCDB1] ps -aef | grep ora | grep arc\noracle    2783     1  1 10:03 ?        00:00:17 ora_arc0_JOCDB1\noracle    2785     1  0 10:03 ?        00:00:10 ora_arc1_JOCDB1\noracle    2787     1  0 10:03 ?        00:00:00 ora_arc2_JOCDB1\noracle    2789     1  0 10:03 ?        00:00:10 ora_arc3_JOCDB1\noracle    4014  3232  0 10:22 pts\/0    00:00:00 grep arc\noracle@srvtest:\/home\/oracle\/ [JOCDB1] strace -o strace.trc -tt -p 2783\nProcess 2783 attached - interrupt to quit\n^CProcess 2783 detached\noracle@srvtest:\/home\/oracle\/ [JOCDB1]<\/pre>\n<p>As you can see bellow, the ora_arc0 process writes approximately <span style=\"text-decoration: underline\">every 57 milliseconds<\/span> :<\/p>\n<pre class=\"brush: bash; gutter: true; first-line: 1\">oracle@srvtest:\/home\/oracle\/ [JOCDB1] cat strace.trc | grep ORA-19815\n10:12:01.884104 write(7, \"ORA-19815: WARNING: db_recovery_\"..., 117) = 117\n10:12:01.939699 write(7, \"ORA-19815: WARNING: db_recovery_\"..., 117) = 117\n10:12:02.000230 write(7, \"ORA-19815: WARNING: db_recovery_\"..., 117) = 117\n10:12:02.060336 write(7, \"ORA-19815: WARNING: db_recovery_\"..., 117) = 117\n10:12:02.120346 write(7, \"ORA-19815: WARNING: db_recovery_\"..., 117) = 117\n...\n...<\/pre>\n<p>After discovering this &#8220;bug&#8221; I tried to reproduce it on a 11.2.0.2 database and I noticed that this problem\u00a0doesn&#8217;t exist with this version.<br \/>\nI also tested this case on a Windows environment with a 12.1.0.1 database and this time the &#8220;bug&#8221;\u00a0is the same as on a Linux system.<\/p>\n<p>I created an\u00a0Oracle Service Request and Oracle decided to open a bug (currently under development).<\/p>\n<p>A solution is to create a separate file system on the server for the <em>diag_dest<\/em> of each database.<br \/>\nIndeed, if a database can&#8217;t write on his alert.log because of the alert.log of an other database filled the file system, some critical errors will not be detected.<\/p>\n<p>P.S : many thanks to <a title=\"Franck Pachot\" href=\"http:\/\/dbi-services.com\/blog\/author\/franck-pachot\/\" target=\"_blank\" rel=\"noopener\">Franck Pachot<\/a> for his help and advises.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>We\u00a0discovered a strange behavior in the Alert Log\u00a0when the Fast Recovery Area (FRA) is full and the database wants to write something inside it (for example an archivelog).\u00a0This case concern Oracle 11.2.0.3 databases and higher. Here is a demo with a 12c database (12.1.0.2) : First, to reproduce the behavior, I set a very small [&hellip;]<\/p>\n","protected":false},"author":30,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[229],"tags":[610,228,611,17,209],"type_dbi":[],"class_list":["post-5261","post","type-post","status-publish","format-standard","hentry","category-database-administration-monitoring","tag-alert-log","tag-fast-recovery-area","tag-filesytem","tag-oracle-11g","tag-oracle-12c"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO Premium plugin v27.2 (Yoast SEO v27.2) - https:\/\/yoast.com\/product\/yoast-seo-premium-wordpress\/ -->\n<title>&quot;FRA full&quot; alerts flood the Alert Log - 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\/fra-full-alerts-flood-alert-log\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"&quot;FRA full&quot; alerts flood the Alert Log\" \/>\n<meta property=\"og:description\" content=\"We\u00a0discovered a strange behavior in the Alert Log\u00a0when the Fast Recovery Area (FRA) is full and the database wants to write something inside it (for example an archivelog).\u00a0This case concern Oracle 11.2.0.3 databases and higher. Here is a demo with a 12c database (12.1.0.2) : First, to reproduce the behavior, I set a very small [&hellip;]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/fra-full-alerts-flood-alert-log\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2015-08-25T12:53:31+00:00\" \/>\n<meta name=\"author\" content=\"Jo\u00ebl Cattin\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Jo\u00ebl Cattin\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"5 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\/fra-full-alerts-flood-alert-log\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/fra-full-alerts-flood-alert-log\/\"},\"author\":{\"name\":\"Jo\u00ebl Cattin\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/2c774f00321ee734515f0c2f6a96b780\"},\"headline\":\"&#8220;FRA full&#8221; alerts flood the Alert Log\",\"datePublished\":\"2015-08-25T12:53:31+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/fra-full-alerts-flood-alert-log\/\"},\"wordCount\":389,\"commentCount\":0,\"keywords\":[\"alert.log\",\"Fast Recovery Area\",\"filesytem\",\"Oracle 11g\",\"Oracle 12c\"],\"articleSection\":[\"Database Administration &amp; Monitoring\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/fra-full-alerts-flood-alert-log\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/fra-full-alerts-flood-alert-log\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/fra-full-alerts-flood-alert-log\/\",\"name\":\"\\\"FRA full\\\" alerts flood the Alert Log - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"datePublished\":\"2015-08-25T12:53:31+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/2c774f00321ee734515f0c2f6a96b780\"},\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/fra-full-alerts-flood-alert-log\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/fra-full-alerts-flood-alert-log\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/fra-full-alerts-flood-alert-log\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"&#8220;FRA full&#8221; alerts flood the Alert Log\"}]},{\"@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\/2c774f00321ee734515f0c2f6a96b780\",\"name\":\"Jo\u00ebl Cattin\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/secure.gravatar.com\/avatar\/a4271811924694263d4de5a469f8bd4a90b14d3d90e6ad819b9e2e5ac035a2dc?s=96&d=mm&r=g\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/a4271811924694263d4de5a469f8bd4a90b14d3d90e6ad819b9e2e5ac035a2dc?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/a4271811924694263d4de5a469f8bd4a90b14d3d90e6ad819b9e2e5ac035a2dc?s=96&d=mm&r=g\",\"caption\":\"Jo\u00ebl Cattin\"},\"description\":\"Jo\u00ebl Cattin has more than three years of experience in databases management. He is specialized in Oracle solutions such as Data Guard and RMAN and has a good background knowledge of Oracle Database Appliance (ODA), Real Application Cluster (RAC) and applications development on APEX. Jo\u00ebl Cattin\u2019s experience includes other RDBMS, such as PostgreSQL and MySQL. He is Oracle Database 12c Administrator Certified Professional, EDB Postgres Advanced Server 9.5 Certified Professional, RedHat Certified System Administrator and ITILv3 Foundation for Service Management Certified. Jo\u00ebl Cattin holds a degree from the \u00c9cole Sup\u00e9rieure d\u2019Informatique de Gestion (ESIG) in Del\u00e9mont and a Federal Certificate of Proficiency in Computer Science (Certificat f\u00e9d\u00e9ral de Capacit\u00e9 \u2013 CFC).\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/author\/joel-cattin\/\"}]}<\/script>\n<!-- \/ Yoast SEO Premium plugin. -->","yoast_head_json":{"title":"\"FRA full\" alerts flood the Alert Log - 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\/fra-full-alerts-flood-alert-log\/","og_locale":"en_US","og_type":"article","og_title":"\"FRA full\" alerts flood the Alert Log","og_description":"We\u00a0discovered a strange behavior in the Alert Log\u00a0when the Fast Recovery Area (FRA) is full and the database wants to write something inside it (for example an archivelog).\u00a0This case concern Oracle 11.2.0.3 databases and higher. Here is a demo with a 12c database (12.1.0.2) : First, to reproduce the behavior, I set a very small [&hellip;]","og_url":"https:\/\/www.dbi-services.com\/blog\/fra-full-alerts-flood-alert-log\/","og_site_name":"dbi Blog","article_published_time":"2015-08-25T12:53:31+00:00","author":"Jo\u00ebl Cattin","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Jo\u00ebl Cattin","Est. reading time":"5 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/fra-full-alerts-flood-alert-log\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/fra-full-alerts-flood-alert-log\/"},"author":{"name":"Jo\u00ebl Cattin","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/2c774f00321ee734515f0c2f6a96b780"},"headline":"&#8220;FRA full&#8221; alerts flood the Alert Log","datePublished":"2015-08-25T12:53:31+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/fra-full-alerts-flood-alert-log\/"},"wordCount":389,"commentCount":0,"keywords":["alert.log","Fast Recovery Area","filesytem","Oracle 11g","Oracle 12c"],"articleSection":["Database Administration &amp; Monitoring"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/fra-full-alerts-flood-alert-log\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/fra-full-alerts-flood-alert-log\/","url":"https:\/\/www.dbi-services.com\/blog\/fra-full-alerts-flood-alert-log\/","name":"\"FRA full\" alerts flood the Alert Log - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2015-08-25T12:53:31+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/2c774f00321ee734515f0c2f6a96b780"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/fra-full-alerts-flood-alert-log\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/fra-full-alerts-flood-alert-log\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/fra-full-alerts-flood-alert-log\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"&#8220;FRA full&#8221; alerts flood the Alert Log"}]},{"@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\/2c774f00321ee734515f0c2f6a96b780","name":"Jo\u00ebl Cattin","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/a4271811924694263d4de5a469f8bd4a90b14d3d90e6ad819b9e2e5ac035a2dc?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/a4271811924694263d4de5a469f8bd4a90b14d3d90e6ad819b9e2e5ac035a2dc?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/a4271811924694263d4de5a469f8bd4a90b14d3d90e6ad819b9e2e5ac035a2dc?s=96&d=mm&r=g","caption":"Jo\u00ebl Cattin"},"description":"Jo\u00ebl Cattin has more than three years of experience in databases management. He is specialized in Oracle solutions such as Data Guard and RMAN and has a good background knowledge of Oracle Database Appliance (ODA), Real Application Cluster (RAC) and applications development on APEX. Jo\u00ebl Cattin\u2019s experience includes other RDBMS, such as PostgreSQL and MySQL. He is Oracle Database 12c Administrator Certified Professional, EDB Postgres Advanced Server 9.5 Certified Professional, RedHat Certified System Administrator and ITILv3 Foundation for Service Management Certified. Jo\u00ebl Cattin holds a degree from the \u00c9cole Sup\u00e9rieure d\u2019Informatique de Gestion (ESIG) in Del\u00e9mont and a Federal Certificate of Proficiency in Computer Science (Certificat f\u00e9d\u00e9ral de Capacit\u00e9 \u2013 CFC).","url":"https:\/\/www.dbi-services.com\/blog\/author\/joel-cattin\/"}]}},"_links":{"self":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/5261","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\/30"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/comments?post=5261"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/5261\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=5261"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=5261"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=5261"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=5261"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}