{"id":8824,"date":"2016-09-06T21:07:44","date_gmt":"2016-09-06T19:07:44","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/"},"modified":"2016-09-06T21:07:44","modified_gmt":"2016-09-06T19:07:44","slug":"multitenant-thin-provisioning-pdb-snapshots-on-acfs","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/","title":{"rendered":"Multitenant thin provisioning: PDB snapshots on ACFS"},"content":{"rendered":"<h2>By Franck Pachot<\/h2>\n<p>.<br \/>\nDatabase on ACFS is a long story. At first, the main reason for ASM was to bypass a filesystem layer that is not required by the database. ACFS was for the non-database files that had to be accessed by all cluster nodes. But then, storage vendors and other providers came with snapshots, compression and thin provisioning and Oracle had to answer: they implemented those storage features in ACFS and allowed database files on it.<br \/>\n<!--more--><br \/>\nWhen you create a database on an ODA X5, datafiles are created on an ACFS mount. There is only one ACFS mount for many databases. You probably want to snapshot at database level, but ACFS snapshots are only at filesystem level. To avoid that any write on the filesystem is copied when you need the snapshot for a single database, they implemented this way: At installation, the ACFS mount is created and a snapshot is taken when empty. Then each database created will create a snapshot. This means that in each snapshot you access only to one database. There is no overhead and no additional copies because the master is empty.<br \/>\nThen came multitenant where you can snapshot at PDB level for thin cloning (create PDB from &#8230; snapshot copy). But multitenant cannot be created on a snapshot. CDB must be at root level on ACFS. In ODA X6, an ACFS filesystem is created for each database. But then, when you thin clone a PDB, a snapshot is taken for the whole database. But this one is not empty: any write will have additional copy and overhead.<\/p>\n<p>There&#8217;s more info about ACFS, copy-on-write which is not copy-on-write but redirect-on-write, and performance overhead in the excellent <a href=\"http:\/\/www.ludovicocaldara.net\/dba\/oracle-database-on-acfs-a-perfect-marriage\/\" target=\"_blank\" rel=\"noopener noreferrer\">presentation and demo<\/a> from Ludovico Caldara. Here I&#8217;ll show the snapshot overhead in multitenant when writing to the master, the clone, and the others.<\/p>\n<h3>PDB snapshots on ACFS<\/h3>\n<p>I start with a brand new CDB on ACFS with no snapshots:<\/p>\n<pre><code>[oracle@rac1 ~]$ df -h\nFilesystem         Size  Used Avail Use% Mounted on\n\/dev\/xvdb3          16G  5.0G  9.9G  34% \/\ntmpfs              7.3G  631M  6.7G   9% \/dev\/shm\n\/dev\/xvdb1         477M  118M  330M  27% \/boot\n\/dev\/xvdc1          69G   22G   44G  34% \/u01\n\/dev\/asm\/data-52    25G  6.6G   19G  27% \/u02\n\/dev\/asm\/fra-401    18G  3.4G   15G  19% \/u03\n\/dev\/asm\/redo-358   19G  8.2G   11G  44% \/u04<\/code><\/pre>\n<pre><code>[oracle@rac1 ~]$ acfsutil snap info \/u02\n    number of snapshots:  0\n    snapshot space usage: 0  ( 0.00 )<\/code><\/pre>\n<p>This is what is created by the Oracle Public Cloud for a RAC DBaaS.<\/p>\n<p>I have a PDB1 pluggable database.<\/p>\n<p>I create another one, PDBx, which will be totally independent.<\/p>\n<pre><code>SQL&gt; create pluggable database PDBx admin user admin identified by \"Ach1z0#d\";\nPluggable database created.\nSQL&gt; alter pluggable database PDBx open;\nPluggable Database opened<\/code><\/pre>\n<p>I create a thin clone pluggable database database PDB2,using PDB1 as the master:<\/p>\n<pre><code>SQL&gt; create pluggable database PDB2 from PDB1 snapshot copy;\nPluggable database created.\nSQL&gt; alter pluggable database PDB2 open;\nPluggable Database opened<\/code><\/pre>\n<p>Here are my pluggable databases:<\/p>\n<pre><code>SQL&gt; select pdb_name,GUID from dba_pdbs;\n&nbsp;\nPDB_NAME GUID\n-------- --------------------------------\nPDB$SEED 3360B2A306C60098E053276DD60A9928\nPDB1     3BDAA124651F103DE0531ADBC40A5DD3\nPDBX     3BDCCBE4C1B64A5AE0531ADBC40ADBB7\nPDB2     3BDCCBE4C1B74A5AE0531ADBC40ADBB7<\/code><\/pre>\n<p>The PDB2 being a snapshot clone, it has created a snapshot on the \/u02 which is the ACFS filesystem where datafiles are:<\/p>\n<pre><code>[oracle@rac1 ~]$ acfsutil snap info \/u02\nsnapshot name:               3BDCCBE4C1B74A5AE0531ADBC40ADBB7\nsnapshot location:           \/u02\/.ACFS\/snaps\/3BDCCBE4C1B74A5AE0531ADBC40ADBB7\nRO snapshot or RW snapshot:  RW\nparent name:                 \/u02\nsnapshot creation time:      Tue Sep  6 19:28:35 2016\n&nbsp;\n    number of snapshots:  1\n    snapshot space usage: 3588096  (   3.42 MB )<\/code><\/pre>\n<p>Space usage is minimal here as no write happened yet.<\/p>\n<h3>datafiles<\/h3>\n<p>Here are the datafiles of my CDB to see if PDB2 are on the snapshot:<\/p>\n<pre><code>RMAN&gt; report schema;\n&nbsp;\nList of Permanent Datafiles\n===========================\nFile Size(MB) Tablespace           RB segs Datafile Name\n---- -------- -------------------- ------- ------------------------\n1    780      SYSTEM               YES     \/u02\/app\/oracle\/oradata\/ORCL\/datafile\/o1_mf_system_cwxwcgz4_.dbf\n2    260      PDB$SEED:SYSTEM      NO      \/u02\/app\/oracle\/oradata\/ORCL\/3360B2A306C60098E053276DD60A9928\/datafile\/o1_mf_system_cwxwbzrd_.dbf\n3    1030     SYSAUX               NO      \/u02\/app\/oracle\/oradata\/ORCL\/datafile\/o1_mf_sysaux_cwxw98jl_.dbf\n4    760      PDB$SEED:SYSAUX      NO      \/u02\/app\/oracle\/oradata\/ORCL\/3360B2A306C60098E053276DD60A9928\/datafile\/o1_mf_sysaux_cwxwdof3_.dbf\n7    545      UNDOTBS1             YES     \/u02\/app\/oracle\/oradata\/ORCL\/datafile\/o1_mf_undotbs1_cwxwdl6s_.dbf\n8    200      UNDOTBS2             YES     \/u02\/app\/oracle\/oradata\/ORCL\/datafile\/o1_mf_undotbs2_cwxwrw7y_.dbf\n9    370      PDB1:SYSTEM          NO      \/u02\/app\/oracle\/oradata\/ORCL\/3BDAA124651F103DE0531ADBC40A5DD3\/datafile\/o1_mf_system_cwxx3fb0_.dbf\n10   800      PDB1:SYSAUX          NO      \/u02\/app\/oracle\/oradata\/ORCL\/3BDAA124651F103DE0531ADBC40A5DD3\/datafile\/o1_mf_sysaux_cwxx3fbl_.dbf\n11   5        USERS                NO      \/u02\/app\/oracle\/oradata\/ORCL\/datafile\/o1_mf_users_cwxxop2q_.dbf\n12   5        PDB1:USERS           NO      \/u02\/app\/oracle\/oradata\/ORCL\/3BDAA124651F103DE0531ADBC40A5DD3\/datafile\/o1_mf_users_cwxxopm9_.dbf\n49   370      PDBX:SYSTEM          NO      \/u02\/app\/oracle\/oradata\/ORCL\/3BDCCBE4C1B64A5AE0531ADBC40ADBB7\/datafile\/o1_mf_system_cwy6688l_.dbf\n50   800      PDBX:SYSAUX          NO      \/u02\/app\/oracle\/oradata\/ORCL\/3BDCCBE4C1B64A5AE0531ADBC40ADBB7\/datafile\/o1_mf_sysaux_cwy6688r_.dbf\n51   5        PDBX:USERS           NO      \/u02\/app\/oracle\/oradata\/ORCL\/3BDCCBE4C1B64A5AE0531ADBC40ADBB7\/datafile\/o1_mf_users_cwy6688z_.dbf\n52   370      PDB2:SYSTEM          NO      \/u02\/app\/oracle\/oradata\/ORCL\/3BDCCBE4C1B74A5AE0531ADBC40ADBB7\/datafile\/o1_mf_system_cwy6725s_.dbf\n53   800      PDB2:SYSAUX          NO      \/u02\/app\/oracle\/oradata\/ORCL\/3BDCCBE4C1B74A5AE0531ADBC40ADBB7\/datafile\/o1_mf_sysaux_cwy67261_.dbf\n54   5        PDB2:USERS           NO      \/u02\/app\/oracle\/oradata\/ORCL\/3BDCCBE4C1B74A5AE0531ADBC40ADBB7\/datafile\/o1_mf_users_cwy67268_.dbf<\/code><\/pre>\n<p>The PDB2 datafiles are actually symbolic links to the snapshot:<\/p>\n<pre><code>\n[oracle@rac1 ~]$ ls -l \/u02\/app\/oracle\/oradata\/ORCL\/3BDCCBE4C1B74A5AE0531ADBC40ADBB7\/datafile\n\/u02\/app\/oracle\/oradata\/ORCL\/3BDCCBE4C1B74A5AE0531ADBC40ADBB7\/datafile:\ntotal 62484\nlrwxrwxrwx 1 oracle oinstall      142 Sep  6 19:28 o1_mf_sysaux_cwy67261_.dbf -&gt; \/u02\/.ACFS\/snaps\/3BDCCBE4C1B74A5AE0531ADBC40ADBB7\/app\/oracle\/oradata\/ORCL\/3BDAA124651F103DE0531ADBC40A5DD3\/datafile\/o1_mf_sysaux_cwxx3fbl_.dbf\nlrwxrwxrwx 1 oracle oinstall      142 Sep  6 19:28 o1_mf_system_cwy6725s_.dbf -&gt; \/u02\/.ACFS\/snaps\/3BDCCBE4C1B74A5AE0531ADBC40ADBB7\/app\/oracle\/oradata\/ORCL\/3BDAA124651F103DE0531ADBC40A5DD3\/datafile\/o1_mf_system_cwxx3fb0_.dbf\n-rw-r----- 1 oracle oinstall 63971328 Sep  6 19:28 o1_mf_temp_cwy67267_.dbf\nlrwxrwxrwx 1 oracle oinstall      141 Sep  6 19:28 o1_mf_users_cwy67268_.dbf -&gt; \/u02\/.ACFS\/snaps\/3BDCCBE4C1B74A5AE0531ADBC40ADBB7\/app\/oracle\/oradata\/ORCL\/3BDAA124651F103DE0531ADBC40A5DD3\/datafile\/o1_mf_users_cwxxopm9_.dbf<\/code><\/pre>\n<p>So, you have a snapshot on the\/u02 which contains all the CDB datafiles but only the PDB2 datafiles will be read\/written on the snapshot (though the symbolic links). The other CDB files are included in the snapshot, but without any reason. Nothing will read or write them. They are there only because ACFS cannot snapshot a folder or a set of file. It&#8217;s only a filesystem level. <\/p>\n<h3>write on master<\/h3>\n<p>For the moment, the snapshot is small: the blocks are shared.<\/p>\n<p>If I write 100MB on the master (PDB1), those blocks will be copied in order to persist the old image for the snapshot:<\/p>\n<pre><code>SQL&gt; alter session set container=PDB1\nSession altered.\nSQL&gt; truncate table DEMO;\nTable truncated.\nSQL&gt; insert \/*+ append *\/into DEMO select lpad('b',900,'b') x from xmltable('1 to 100000');\n100000 rows created.\n<\/code><\/pre>\n<pre><code>[oracle@rac1 ~]$ acfsutil snap info \/u02\nsnapshot name:               3BDCCBE4C1B74A5AE0531ADBC40ADBB7\nsnapshot location:           \/u02\/.ACFS\/snaps\/3BDCCBE4C1B74A5AE0531ADBC40ADBB7\nRO snapshot or RW snapshot:  RW\nparent name:                 \/u02\nsnapshot creation time:      Tue Sep  6 19:28:35 2016\n&nbsp;\n    number of snapshots:  1\n    snapshot space usage: 105025536  ( 100.16 MB )<\/code><\/pre>\n<p>Snapshot size increased by the volume that has been written, which is expected: old image is required by PDB2.<\/p>\n<h3>write on thin clone<\/h3>\n<p>If I write to the clone, copy has to happen as well:<\/p>\n<pre><code>SQL&gt; alter session set container=PDB2\nSession altered.\nSQL&gt; truncate table DEMO;\nTable truncated.\nSQL&gt; insert \/*+ append *\/into DEMO select lpad('b',900,'b') x from xmltable('1 to 100000');\n100000 rows created.<\/code><\/pre>\n<pre><code>[oracle@rac1 ~]$ acfsutil snap info \/u02\nsnapshot name:               3BDCCBE4C1B74A5AE0531ADBC40ADBB7\nsnapshot location:           \/u02\/.ACFS\/snaps\/3BDCCBE4C1B74A5AE0531ADBC40ADBB7\nRO snapshot or RW snapshot:  RW\nparent name:                 \/u02\nsnapshot creation time:      Tue Sep  6 19:28:35 2016\n&nbsp;\n    number of snapshots:  1\n    snapshot space usage: 211275776  ( 201.48 MB )<\/code><\/pre>\n<p>So, because I&#8217;ve written 200MB to blocks involved in the snapshots, the snapshot size is now 200MB.<\/p>\n<p>However, look at the way I did it with truncate and insert. I&#8217;m writing on the same blocks as I did when writing on PDB1. To be sure I checked it from DBA_EXTENTS and had the same result in both pdbs:<\/p>\n<pre><code>SQL&gt; select file_id,listagg(block_id,',')within group(order by block_id),blocks from dba_extents where segment_name='DEMO' and segment_type='TABLE' group by file_id,blocks;\n&nbsp;\n   FILE_ID LISTAGG(BLOCK_ID,',')WITHINGROUP(ORDERBYBLOCK_ID)                                                                                                          BLOCKS\n---------- ------------------------------------------------------------------------------------------------------------------------------------------------------ ----------\n        64 33024,33032,33040,33048,33056,33064,33072,33080,33088,33096,33104,33112,33120,33128,33136,33144                                                                 8\n        64 33152,33280,33408,33536,33664,33792,33920,34048,34176,34304,34432,34560,34688,34816,34944,35072,35200,35328,35456,35584,35712,35840,35968,36096,36224,        128\n           36352,36480,36608,36736,36864,36992,37120,37248,37376,37504,37632,37760,37888,38016,38144,38272,38400,38528,38656,38784,38912,39040,39168,39296,39424,\n           39552,39680,39808,39936,40064,40192,40320,40448,40576,40704,40832,40960,41088                                                                                1024\n        64 41216,42240,43264,44288,45312 <\/code><\/pre>\n<p>So why do I have additional 100MB on my snapshots? Writing to the original blocks would be sufficient as they have been redirected to new ones by the write from PDB1? But because the ACFS snapshot, the previous image is kept. In addition to the current state of PDB1 and PDB2, the snapshot also keeps the blocks from PDB1 as they were at the time of the PDB2 clone. Who needs it?<\/p>\n<p>Ok. This is not a big issue if we consider that you usually don&#8217;t write on the master, because it&#8217;s the master.<\/p>\n<h3>write on other PDB<\/h3>\n<p>Remember that multitenant is for consolidation. You don&#8217;t use a CDB only for the master and its clones. You may want to host other PDBs. If we had a snapshot for PDB1 and PDB2, writes to other files should not be concerned: no write overhead and no additional storage. However, because the snapshot was made on the whole filesystem, any write to it will copy the blocks, even those that are not concerned by the thin cloned PDB. Here I&#8217;m writing 100MB to PDBx which has nothing in common with PDB1 nor PDB2:<\/p>\n<pre><code>SQL&gt; alter session set container=PDBx\nSession altered.\nSQL&gt; truncate table DEMO;\nTable truncated.\nSQL&gt; insert \/*+ append *\/into DEMO select lpad('b',900,'b') x from xmltable('1 to 100000');\n100000 rows created.<\/code><\/pre>\n<pre><code>[oracle@rac1 ~]$ acfsutil snap info \/u02\nsnapshot name:               3BDCCBE4C1B74A5AE0531ADBC40ADBB7\nsnapshot location:           \/u02\/.ACFS\/snaps\/3BDCCBE4C1B74A5AE0531ADBC40ADBB7\nRO snapshot or RW snapshot:  RW\nparent name:                 \/u02\nsnapshot creation time:      Tue Sep  6 19:28:35 2016\n&nbsp;\n    number of snapshots:  1\n    snapshot space usage: 311214080  ( 296.79 MB )<\/code><\/pre>\n<p>This is an additional 100MB. Before image of PDBx has been saved, for no reason because we will never read this previous image.<\/p>\n<h3>snapshot keeps growing<\/h3>\n<p>after a few minutes without any user activity, snapshot has grown further:<\/p>\n<pre><code>[oracle@rac1 ~]$ acfsutil snap info \/u02\nsnapshot name:               3BDCCBE4C1B74A5AE0531ADBC40ADBB7\nsnapshot location:           \/u02\/.ACFS\/snaps\/3BDCCBE4C1B74A5AE0531ADBC40ADBB7\nRO snapshot or RW snapshot:  RW\nparent name:                 \/u02\nsnapshot creation time:      Tue Sep  6 19:28:35 2016\n&nbsp;\n    number of snapshots:  1\n    snapshot space usage: 332947456  ( 317.52 MB )<\/code><\/pre>\n<p>On the \/u02 filesystem, there is all the CDB files, SYSTEM, UNDO, controlfile, etc. They have activity and they are copied when written, once again for no reason.<\/p>\n<h3>drop thin clone<\/h3>\n<p>Only when I drop the PDB2 this space is released:<\/p>\n<pre><code>SQL&gt; alter pluggable database pdb2 close;\nPluggable database altered.\nSQL&gt; drop pluggable database pdb2 including datafiles;\nPluggable database dropped.<\/code><\/pre>\n<pre><code>[oracle@rac1 ~]$ acfsutil snap info \/u02\n    number of snapshots:  0\n    snapshot space usage: 0  ( 0.00 )<\/code><\/pre>\n<h3>So what?<\/h3>\n<p>There&#8217;s no bug here. It works as designed because ACFS snapshot is at filesystem level. If you want to use multitenant thin provisioning, the recommendation is to dedicate a CDB for the master and its clones. Any other PDB will have their writes copied to the snapshot for no reason. Writes to common files: UNDO (in 12.1), SYSTEM, SYSAUX will also be concerned. The duration of the clones should be short life, refreshed frequently. And of course, thin cloning is not for production. Very few snapshot\/compression\/clone technologies can be used in production. Look at storage vendors solutions for that (<a href=\"http:\/\/www.emc.com\/collateral\/white-papers\/h14485-xtremio-snapshot-refresh-oracle-databases.pdf\" target=\"_blank\" rel=\"noopener noreferrer\">XtremIO<\/a> for example).<\/p>\n","protected":false},"excerpt":{"rendered":"<p>By Franck Pachot . Database on ACFS is a long story. At first, the main reason for ASM was to bypass a filesystem layer that is not required by the database. ACFS was for the non-database files that had to be accessed by all cluster nodes. But then, storage vendors and other providers came with [&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":[229],"tags":[600,220,64,209,875,66,223],"type_dbi":[],"class_list":["post-8824","post","type-post","status-publish","format-standard","hentry","category-database-administration-monitoring","tag-acfs","tag-cdb","tag-multitenant","tag-oracle-12c","tag-oracle-multitenant","tag-pdb","tag-pluggable-databases"],"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>Multitenant thin provisioning: PDB snapshots on ACFS - 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\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Multitenant thin provisioning: PDB snapshots on ACFS\" \/>\n<meta property=\"og:description\" content=\"By Franck Pachot . Database on ACFS is a long story. At first, the main reason for ASM was to bypass a filesystem layer that is not required by the database. ACFS was for the non-database files that had to be accessed by all cluster nodes. But then, storage vendors and other providers came with [&hellip;]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2016-09-06T19:07:44+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=\"10 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\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/\"},\"author\":{\"name\":\"Oracle Team\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"headline\":\"Multitenant thin provisioning: PDB snapshots on ACFS\",\"datePublished\":\"2016-09-06T19:07:44+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/\"},\"wordCount\":1020,\"commentCount\":0,\"keywords\":[\"ACFS\",\"CDB\",\"multitenant\",\"Oracle 12c\",\"Oracle Multitenant\",\"PDB\",\"Pluggable Databases\"],\"articleSection\":[\"Database Administration &amp; Monitoring\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/\",\"name\":\"Multitenant thin provisioning: PDB snapshots on ACFS - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"datePublished\":\"2016-09-06T19:07:44+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Multitenant thin provisioning: PDB snapshots on ACFS\"}]},{\"@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":"Multitenant thin provisioning: PDB snapshots on ACFS - 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\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/","og_locale":"en_US","og_type":"article","og_title":"Multitenant thin provisioning: PDB snapshots on ACFS","og_description":"By Franck Pachot . Database on ACFS is a long story. At first, the main reason for ASM was to bypass a filesystem layer that is not required by the database. ACFS was for the non-database files that had to be accessed by all cluster nodes. But then, storage vendors and other providers came with [&hellip;]","og_url":"https:\/\/www.dbi-services.com\/blog\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/","og_site_name":"dbi Blog","article_published_time":"2016-09-06T19:07:44+00:00","author":"Oracle Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Oracle Team","Est. reading time":"10 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/"},"author":{"name":"Oracle Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"headline":"Multitenant thin provisioning: PDB snapshots on ACFS","datePublished":"2016-09-06T19:07:44+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/"},"wordCount":1020,"commentCount":0,"keywords":["ACFS","CDB","multitenant","Oracle 12c","Oracle Multitenant","PDB","Pluggable Databases"],"articleSection":["Database Administration &amp; Monitoring"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/","url":"https:\/\/www.dbi-services.com\/blog\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/","name":"Multitenant thin provisioning: PDB snapshots on ACFS - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2016-09-06T19:07:44+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Multitenant thin provisioning: PDB snapshots on ACFS"}]},{"@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\/8824","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=8824"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/8824\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=8824"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=8824"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=8824"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=8824"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}