{"id":14351,"date":"2020-07-03T12:19:24","date_gmt":"2020-07-03T10:19:24","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/oracle-acfs-du-df\/"},"modified":"2020-07-03T12:19:24","modified_gmt":"2020-07-03T10:19:24","slug":"oracle-acfs-du-df","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/oracle-acfs-du-df\/","title":{"rendered":"Oracle ACFS: &#8220;du&#8221; vs. &#8220;df&#8221; and &#8220;acfsutil info&#8221;"},"content":{"rendered":"<h2>By Franck Pachot<\/h2>\n<p>.<br \/>\nThis is a demo about Oracle ACFS snapshots, and how to understand the used and free space, as displayed by &#8220;df&#8221;, when there are modifications in the base parent or the snapshot children. The important concept to understand is that, when you take a snapshot, any modification to the child or parent will<\/p>\n<pre><code>\n[grid@cloud ~]$ asmcmd lsdg DATAC1\n\n<u>State    Type  Rebal  Sector  Logical_Sector  Block       AU   Total_MB    Free_MB  Req_mir_free_MB  Usable_file_MB  Offline_disks  Voting_files  Name<\/u>\nMOUNTED  HIGH  N         512             512   4096  4194304  214991104  191881152         11943936        59979016              0             Y  DATAC1\/\n<\/code><\/pre>\n<p>On a database machine in the Oracle Cloud I have a diskgroup with lot of free space. I&#8217;ll use this DATAC1 diskgroup to store my ACFS filesystem. the size in MegaByte is not easy to read.<br \/>\nI can have a friendly overview from acfsutil with human readable sizes (in TeraByte there).<\/p>\n<pre><code>\n[grid@cloud ~]$ acfsutil info storage -u TB -l DATAC1\n\nDiskgroup: DATAC1 (83% free)\n  total disk space:         205.03\n  ASM file space:            22.04\n  total free space:         182.99\n  net free with mirroring:   60.99\n  usable after reservation:  57.20\n  redundancy type:          HIGH\n\n    Total space used by ASM non-volume files:\n      used:                     19.03\n      mirror used:               6.34\n\n    volume: \/dev\/asm\/dump-19\n      total:                     1.00\n      free:                      0.22\n      redundancy type:         high\n      file system:             \/u03\/dump\n----\nunit of measurement: TB\n<\/code><\/pre>\n<p>There&#8217;s already a volume here (\/dev\/asm\/dump-19) which is named &#8216;DUMP&#8217; and mounted as an ACFS filesystem (\/u03\/dump) but I&#8217;ll create a now one for this demo and will remove.<\/p>\n<h3>Logical volume: asmcmd volcreate<\/h3>\n<p>I have a diskgroup which exposes disk space to ASM. The first thing to do, in order to build a filesystem on it, is to create a logical volume, which is called ADVM for &#8220;ASM Dynamic Volume Manager&#8221;.<\/p>\n<pre><code>\n[grid@cloud ~]$ asmcmd volcreate -G DATAC1 -s 100G MYADVM\n<\/code><\/pre>\n<p>I&#8217;m creating a 100GB new volume, identified by its name (MYADVM) within the diskgroup (DATAC1). The output is not verbose at all but I can check it with volinfo.<\/p>\n<pre><code>\n[grid@cloud ~]$ asmcmd volinfo -G DATAC1 -a\n\nDiskgroup Name: DATAC1\n\n         Volume Name: DUMP\n         Volume Device: \/dev\/asm\/dump-19\n         State: ENABLED\n         Size (MB): 1048576\n         Resize Unit (MB): 512\n         Redundancy: HIGH\n         Stripe Columns: 8\n         Stripe Width (K): 1024\n         Usage: ACFS\n         Mountpath: \/u03\/dump\n\n         Volume Name: MYADVM\n         Volume Device: \/dev\/asm\/myadvm-19\n         State: ENABLED\n         Size (MB): 102400\n         Resize Unit (MB): 512\n         Redundancy: HIGH\n         Stripe Columns: 8\n         Stripe Width (K): 1024\n         Usage:\n         Mountpath:\n<\/code><\/pre>\n<p>With &#8220;-a&#8221; I show all volumes on the diskgroup, but I could have mentioned the volume name. This is what we will do later.<\/p>\n<p>&#8220;Usage&#8221; is empty because there&#8217;s no filesystem created yet, and &#8220;Mountpath&#8221; is empty because it is not mounted. The information I need is the Volume Device (\/dev\/asm\/myadvm-19) as I&#8217;ll have access to it from the OS.<\/p>\n<pre><code>\n[grid@cloud ~]$ lsblk -a \/dev\/asm\/myadvm-19\n\nNAME          MAJ:MIN  RM  SIZE RO TYPE MOUNTPOINT\nasm!myadvm-19 248:9731  0  100G  0 disk\n\n[grid@cloud ~]$ lsblk -t \/dev\/asm\/myadvm-19\n\nNAME          ALIGNMENT MIN-IO OPT-IO PHY-SEC LOG-SEC ROTA SCHED    RQ-SIZE   RA\nasm!myadvm-19         0    512      0     512     512    1 deadline     128  128\n\n[grid@cloud ~]$ fdisk -l \/dev\/asm\/myadvm-19\n\nDisk \/dev\/asm\/myadvm-19: 107.4 GB, 107374182400 bytes\n255 heads, 63 sectors\/track, 13054 cylinders\nUnits = cylinders of 16065 * 512 = 8225280 bytes\nSector size (logical\/physical): 512 bytes \/ 512 bytes\nI\/O size (minimum\/optimal): 512 bytes \/ 512 bytes\nDisk identifier: 0x00000000\n<\/code><\/pre>\n<p>Visible from the OS, I have a 100GB volume with nothing there: I need to format it.<\/p>\n<h3>Filesystem: Linux mkfs<\/h3>\n<pre><code>\n[grid@cloud ~]$ grep -v nodev \/proc\/filesystems\n\n        iso9660\n        ext4\n        fuseblk\n        acfs\n<\/code><\/pre>\n<p>ACFS is a filesystem supported by the kernel. I can use &#8220;mkfs&#8221; to format the volume to ACFS.<\/p>\n<pre><code>\n[grid@cloud ~]$ mkfs.acfs -f \/dev\/asm\/myadvm-19\n\nmkfs.acfs: version                   = 18.0.0.0.0\nmkfs.acfs: on-disk version           = 46.0\nmkfs.acfs: volume                    = \/dev\/asm\/myadvm-19\nmkfs.acfs: volume size               = 107374182400  ( 100.00 GB )\nmkfs.acfs: Format complete.\n<\/code><\/pre>\n<p>I used &#8220;-f&#8221; because my volume was already formatted from a previous test. I have now a 100GB filesystem on this volume.<\/p>\n<pre><code>\n[grid@cloud ~]$ asmcmd volinfo -G DATAC1 MYADVM\n\nDiskgroup Name: DATAC1\n\n         Volume Name: MYADVM\n         Volume Device: \/dev\/asm\/myadvm-19\n         State: ENABLED\n         Size (MB): 102400\n         Resize Unit (MB): 512\n         Redundancy: HIGH\n         Stripe Columns: 8\n         Stripe Width (K): 1024\n         Usage: ACFS\n         Mountpath:\n<\/code><\/pre>\n<p>The &#8220;Usage&#8221; shows that ASM knows that the ADVM volume holds an ACFS filesystem.<\/p>\n<pre><code>\n[opc@cloud ~]$ sudo mkdir -p \/myacfs\n<\/code><\/pre>\n<p>I&#8217;ll mount this filesystem to \/myacfs<\/p>\n<pre><code>\n[opc@cloud ~]$ sudo mount -t acfs \/dev\/asm\/myadvm-19 \/myacfs\n\n[opc@cloud ~]$ mount | grep \/myacfs\n\n\/dev\/asm\/myadvm-19 on \/myacfs type acfs (rw)\n\n[opc@cloud ~]$ df -Th \/myacfs\n\nFilesystem         Type  Size  Used Avail Use% Mounted on\n\/dev\/asm\/myadvm-19 acfs  100G  448M  100G   1% \/myacfs\n\n[opc@cloud ~]$ ls -alrt \/myacfs\n\ntotal 100\ndrwxr-xr-x 30 root root  4096 Jun 23 10:40 ..\ndrwxr-xr-x  4 root root 32768 Jun 23 15:48 .\ndrwx------  2 root root 65536 Jun 23 15:48 lost+found\n\n[opc@cloud ~]$ sudo umount \/myacfs\n<\/code><\/pre>\n<p>I wanted to show that you can mount it from the OS but, as we have Grid Infrastructure, we usually want to manage it as a cluster resource.<\/p>\n<pre><code>\n[opc@cloud ~]$ sudo acfsutil registry -a \/dev\/asm\/myadvm-19 \/myacfs -u grid\n\nacfsutil registry: mount point \/myacfs successfully added to Oracle Registry\n\n[opc@cloud ~]$ ls -alrt \/myacfs\n\ntotal 100\ndrwxr-xr-x 30 root root      4096 Jun 23 10:40 ..\ndrwxr-xr-x  4 grid oinstall 32768 Jun 23 15:48 .\ndrwx------  2 root root     65536 Jun 23 15:48 lost+found\n<\/code><\/pre>\n<p>The difference here is that I&#8217;ve set the owner of the filesystem to &#8220;grid&#8221; as that&#8217;s the user I&#8217;ll use for the demo.<\/p>\n<h3>Used and free space<\/h3>\n<pre><code>\n[grid@cloud ~]$ asmcmd volinfo -G DATAC1 MYADVM\n\nDiskgroup Name: DATAC1\n\n         Volume Name: MYADVM\n         Volume Device: \/dev\/asm\/myadvm-19\n         State: ENABLED\n         Size (MB): 102400\n         Resize Unit (MB): 512\n         Redundancy: HIGH\n         Stripe Columns: 8\n         Stripe Width (K): 1024\n         Usage: ACFS\n         Mountpath: \/myacfs\n<\/code><\/pre>\n<p>ADVM has the information about the mount path but now to interact with it I&#8217;ll use &#8220;acfsutil&#8221; for ACFS features or the standard Linux commands on filesystems.<\/p>\n<pre><code>\n[grid@cloud ~]$ du -ah \/myacfs\n\n64K     \/myacfs\/lost+found\n96K     \/myacfs\n<\/code><\/pre>\n<p>I have no files there: only 96 KB used.<\/p>\n<pre><code>\n[grid@cloud ~]$ df -Th \/myacfs\n\nFilesystem         Type  Size  Used Avail Use% Mounted on\n\/dev\/asm\/myadvm-19 acfs  100G  688M  100G   1% \/myacfs\n<\/code><\/pre>\n<p>the whole size of 100GB is available.<\/p>\n<pre><code>\n[grid@cloud ~]$ acfsutil info storage -u GB -l DATAC1\n\nDiskgroup: DATAC1 (83% free)\n  total disk space:         209952.25\n  ASM file space:           22864.75\n  total free space:         187083.87\n  net free with mirroring:  62361.29\n  usable after reservation: 58473.23\n  redundancy type:          HIGH\n\n    Total space used by ASM non-volume files:\n      used:                    19488.04\n      mirror used:             6496.01\n\n    volume: \/dev\/asm\/myadvm-19\n      total:                   100.00\n      free:                     99.33\n      redundancy type:         high\n      file system:             \/myacfs\n...\n----\nunit of measurement: GB\n<\/code><\/pre>\n<p>&#8220;acfs info storage&#8221; shows all volumes in the diskgroup (I removed the output for the &#8216;DUMP&#8217; one here)<\/p>\n<pre><code>\n[grid@cloud ~]$ acfsutil info fs \/myacfs\n\/myacfs\n    ACFS Version: 18.0.0.0.0\n    on-disk version:       47.0\n    compatible.advm:       18.0.0.0.0\n    ACFS compatibility:    18.0.0.0.0\n    flags:        MountPoint,Available\n    mount time:   Tue Jun 23 15:52:35 2020\n    mount sequence number: 8\n    allocation unit:       4096\n    metadata block size:   4096\n    volumes:      1\n    total size:   107374182400  ( 100.00 GB )\n    total free:   106652823552  (  99.33 GB )\n    file entry table allocation: 393216\n    primary volume: \/dev\/asm\/myadvm-19\n        label:\n        state:                 Available\n        major, minor:          248, 9731\n        logical sector size:   512\n        size:                  107374182400  ( 100.00 GB )\n        free:                  106652823552  (  99.33 GB )\n        metadata read I\/O count:         1203\n        metadata write I\/O count:        10\n        total metadata bytes read:       4927488  (   4.70 MB )\n        total metadata bytes written:    40960  (  40.00 KB )\n        ADVM diskgroup:        DATAC1\n        ADVM resize increment: 536870912\n        ADVM redundancy:       high\n        ADVM stripe columns:   8\n        ADVM stripe width:     1048576\n    number of snapshots:  0\n    snapshot space usage: 0  ( 0.00 )\n    replication status: DISABLED\n    compression status: DISABLED\n<\/code><\/pre>\n<p>&#8220;acfsutil info fs&#8221; is the best way to have all information and here it shows the same as what we see from the OS: size=100GB and free=99.33GB<\/p>\n<h3>Add a file<\/h3>\n<pre><code>\n[grid@cloud ~]$ dd of=\/myacfs\/file.tmp if=\/dev\/zero bs=1G count=42\n\n42+0 records in\n42+0 records out\n45097156608 bytes (45 GB) copied, 157.281 s, 287 MB\/s\n<\/code><\/pre>\n<p>I have created a 42 GB file in my filesystem. And now will compare the size info.<\/p>\n<pre><code>\n[grid@cloud ~]$ du -ah \/myacfs\n\n64K     \/myacfs\/lost+found\n43G     \/myacfs\/file.tmp\n43G     \/myacfs\n<\/code><\/pre>\n<p>I see one additional file with 43GB<\/p>\n<pre><code>\n[grid@cloud ~]$ df -Th \/myacfs\n\nFilesystem         Type  Size  Used Avail Use% Mounted on\n\/dev\/asm\/myadvm-19 acfs  100G   43G   58G  43% \/myacfs\n<\/code><\/pre>\n<p>The used space that was 688 MB is now 43GB, the free space which was 100 GB is now 58 GB and the 1% usage is now 43% &#8211; this is the exact math (rounded to next GB) as my file had to allocate extents for all its data.<\/p>\n<pre><code>\n[grid@cloud ~]$ acfsutil info storage -u GB -l DATAC1\n\nDiskgroup: DATAC1 (83% free)\n  total disk space:         209952.25\n  ASM file space:           22864.75\n  total free space:         187083.87\n  net free with mirroring:  62361.29\n  usable after reservation: 58473.23\n  redundancy type:          HIGH\n\n    Total space used by ASM non-volume files:\n      used:                    19488.04\n      mirror used:             6496.01\n\n    volume: \/dev\/asm\/myadvm-19\n      total:                   100.00\n      free:                     57.29\n      redundancy type:         high\n      file system:             \/myacfs\n<\/code><\/pre>\n<p>Here the &#8220;free:&#8221; that was 99.33 GB before is now 57.29 GB which matches what we see from df.<br \/>\ntotal free: 106652823552 ( 99.33 GB )<\/p>\n<pre><code>\n[grid@cloud ~]$ acfsutil info fs \/myacfs\n\n\/myacfs\n    ACFS Version: 18.0.0.0.0\n    on-disk version:       47.0\n    compatible.advm:       18.0.0.0.0\n    ACFS compatibility:    18.0.0.0.0\n    flags:        MountPoint,Available\n    mount time:   Tue Jun 23 15:52:35 2020\n    mount sequence number: 8\n    allocation unit:       4096\n    metadata block size:   4096\n    volumes:      1\n    total size:   107374182400  ( 100.00 GB )\n    total free:   61513723904  (  57.29 GB )\n    file entry table allocation: 393216\n    primary volume: \/dev\/asm\/myadvm-19\n        label:\n        state:                 Available\n        major, minor:          248, 9731\n        logical sector size:   512\n        size:                  107374182400  ( 100.00 GB )\n        free:                  61513723904  (  57.29 GB )\n        metadata read I\/O count:         1686\n        metadata write I\/O count:        130\n        total metadata bytes read:       8687616  (   8.29 MB )\n        total metadata bytes written:    3555328  (   3.39 MB )\n        ADVM diskgroup:        DATAC1\n        ADVM resize increment: 536870912\n        ADVM redundancy:       high\n        ADVM stripe columns:   8\n        ADVM stripe width:     1048576\n    number of snapshots:  0\n    snapshot space usage: 0  ( 0.00 )\n    replication status: DISABLED\n    compression status: DISABLED\n<\/code><\/pre>\n<p>What has changed here is only the &#8220;total free:&#8221; from 99.33 GB to 57.29 GB<\/p>\n<h3>Create a snapshot<\/h3>\n<p>For the moment, with no snapshot and no compression, the size allocated in the filesystem (as the &#8220;df&#8221; used) is the same as the size of the files (as the &#8220;du&#8221; file size).<\/p>\n<pre><code>\n[grid@cloud ~]$ acfsutil snap info \/myacfs\n\n    number of snapshots:  0\n    snapshot space usage: 0  ( 0.00 )\n<\/code><\/pre>\n<p>The &#8220;acfsutil info fs&#8221; shows no snapshots, and &#8220;acfsutil snap info&#8221; shows the same but will give more details where I&#8217;ll have created snapshots.<\/p>\n<pre><code>\n[grid@cloud ~]$ acfsutil snap create -w S1 \/myacfs\n\nacfsutil snap create: Snapshot operation is complete.\n<\/code><\/pre>\n<p>This has created a read-write snapshot of the filesystem.<\/p>\n<pre><code>\n[grid@cloud ~]$ du -ah \/myacfs\n\n64K     \/myacfs\/lost+found\n43G     \/myacfs\/file.tmp\n43G     \/myacfs\n<\/code><\/pre>\n<p>Nothing different here as this shows only the base. The snapshots are in a hidden .ACFS that is not listed but can be accessed when mentioning the path.<\/p>\n<pre><code>\n[grid@cloud ~]$ du -ah \/myacfs\/.ACFS\n\n32K     \/myacfs\/.ACFS\/.fileid\n32K     \/myacfs\/.ACFS\/repl\n43G     \/myacfs\/.ACFS\/snaps\/S1\/file.tmp\n43G     \/myacfs\/.ACFS\/snaps\/S1\n43G     \/myacfs\/.ACFS\/snaps\n43G     \/myacfs\/.ACFS\n<\/code><\/pre>\n<p>Here I see my 42 GB file in the snapshot. But, as I did no modifications there, it shares the same extents on disk. This means that even if I see two files of 42 GB there is only 42 GB allocated for those two virtual copies.<\/p>\n<pre><code>\n[grid@cloud ~]$ df -Th \/myacfs\n\nFilesystem         Type  Size  Used Avail Use% Mounted on\n\n\/dev\/asm\/myadvm-19 acfs  100G   43G   58G  43% \/myacfs\n<\/code><\/pre>\n<p>As there are no additional extents allocated for this snapshot, &#8220;df&#8221; shows the same as before. Here we start to see a difference between the physical &#8220;df&#8221; size and the virtual &#8220;du&#8221; size.<\/p>\n<pre><code>\n[grid@cloud ~]$ acfsutil info storage -u GB -l DATAC1\n\nDiskgroup: DATAC1 (83% free)\n  total disk space:         209952.25\n  ASM file space:           22864.75\n  total free space:         187083.87\n  net free with mirroring:  62361.29\n  usable after reservation: 58473.23\n  redundancy type:          HIGH\n\n    Total space used by ASM non-volume files:\n      used:                    19488.04\n      mirror used:             6496.01\n\n    volume: \/dev\/asm\/myadvm-19\n      total:                   100.00\n      free:                     57.29\n      redundancy type:         high\n      file system:             \/myacfs\n        snapshot: S1 (\/myacfs\/.ACFS\/snaps\/S1)\n          used:          0.00\n          quota limit:   none\n...\n----\nunit of measurement: GB\n<\/code><\/pre>\n<p>Here I have additional information for my snapshot: &#8220;snapshot: S1 (\/myacfs\/.ACFS\/snaps\/S1)&#8221; with 0 GB used because I did not modify anything in the snapshot yet. The volume still has the same free space.<\/p>\n<pre><code>\n[grid@cloud ~]$ acfsutil snap info \/myacfs\n    number of snapshots:  1\n    snapshot space usage: 393216  ( 384.00 KB )\n<\/code><\/pre>\n<p>The new thing here is &#8220;number of snapshots: 1&#8221; with nearly no space usage (384 KB)<\/p>\n<pre><code>\n[grid@cloud ~]$ acfsutil info fs \/myacfs\n\/myacfs\n    ACFS Version: 18.0.0.0.0\n    on-disk version:       47.0\n    compatible.advm:       18.0.0.0.0\n    ACFS compatibility:    18.0.0.0.0\n    flags:        MountPoint,Available\n    mount time:   Tue Jun 23 15:52:35 2020\n    mount sequence number: 8\n    allocation unit:       4096\n    metadata block size:   4096\n    volumes:      1\n    total size:   107374182400  ( 100.00 GB )\n    total free:   61513723904  (  57.29 GB )\n    file entry table allocation: 393216\n    primary volume: \/dev\/asm\/myadvm-19\n        label:\n        state:                 Available\n        major, minor:          248, 9731\n        logical sector size:   512\n        size:                  107374182400  ( 100.00 GB )\n        free:                  61513723904  (  57.29 GB )\n        metadata read I\/O count:         4492\n        metadata write I\/O count:        236\n        total metadata bytes read:       24363008  (  23.23 MB )\n        total metadata bytes written:    12165120  (  11.60 MB )\n        ADVM diskgroup:        DATAC1\n        ADVM resize increment: 536870912\n        ADVM redundancy:       high\n        ADVM stripe columns:   8\n        ADVM stripe width:     1048576\n    number of snapshots:  1\n    snapshot space usage: 393216  ( 384.00 KB )\n    replication status: DISABLED\n    compression status: DISABLED\n\n<\/code><\/pre>\n<p>Here I have more detail: those 384 KB are for the file allocation table only.<\/p>\n<h3>Write on snapshot<\/h3>\n<p>My snapshot shows no additional space but that will not stay as the goal is to do some modifications, within the same file, like a database would do on its datafiles as soon as it is opened read-write.<\/p>\n<pre><code>\n[grid@cloud ~]$ dd of=\/myacfs\/.ACFS\/snaps\/S1\/file.tmp if=\/dev\/zero bs=1G count=10 conv=notrunc\n\n10+0 records in\n10+0 records out\n10737418240 bytes (11 GB) copied, 58.2101 s, 184 MB\/s\n\n<\/code><\/pre>\n<p>I&#8217;ve overwritten 10GB within the 42 GB file but the remaining 32 are still the same (that&#8217;s what the conv=notrunc is doing &#8211; not truncating the end of file).<\/p>\n<pre><code>\n[grid@cloud ~]$ du -ah \/myacfs\n\n64K     \/myacfs\/lost+found\n43G     \/myacfs\/file.tmp\n43G     \/myacfs\n<\/code><\/pre>\n<p>Nothing has changed at the base level because I modified only the file in the snapshot.<\/p>\n<pre><code>\n\n[grid@cloud ~]$ du -ah \/myacfs\/.ACFS\n\n32K     \/myacfs\/.ACFS\/.fileid\n32K     \/myacfs\/.ACFS\/repl\n43G     \/myacfs\/.ACFS\/snaps\/S1\/file.tmp\n43G     \/myacfs\/.ACFS\/snaps\/S1\n43G     \/myacfs\/.ACFS\/snaps\n43G     \/myacfs\/.ACFS\n<\/code><\/pre>\n<p>Nothing has changed either in the snapshot because the file is still the same size.<\/p>\n<pre><code>\n[grid@cloud ~]$ df -Th \/myacfs\n\nFilesystem         Type  Size  Used Avail Use% Mounted on\n\/dev\/asm\/myadvm-19 acfs  100G   53G   48G  53% \/myacfs\n<\/code><\/pre>\n<p>The filesystem, has increased by the amount I modified in the snapshot: I had 58GB available and now only 48GB. Because the 10GB of extents that were shared between the shanpshot child and the base (the snapshot parent) are not the same anymore and new extents had to be allocated for the snapshot. This is similar to copy-on-write.<\/p>\n<p>That&#8217;s the main point of this blog post: you don&#8217;t see this new allocation with &#8220;ls&#8221; or &#8220;du&#8221; but only with &#8220;df&#8221; or the filesystem specific tools.<\/p>\n<pre><code>\n[grid@cloud ~]$ acfsutil info storage -u GB -l DATAC1\n\nDiskgroup: DATAC1 (83% free)\n  total disk space:         209952.25\n  ASM file space:           22864.75\n  total free space:         187083.87\n  net free with mirroring:  62361.29\n  usable after reservation: 58473.23\n  redundancy type:          HIGH\n\n    Total space used by ASM non-volume files:\n      used:                    19488.04\n      mirror used:             6496.01\n\n    volume: \/dev\/asm\/myadvm-19\n      total:                   100.00\n      free:                     47.09\n      redundancy type:         high\n      file system:             \/myacfs\n        snapshot: S1 (\/myacfs\/.ACFS\/snaps\/S1)\n          used:         10.10\n          quota limit:   none\n\n----\nunit of measurement: GB\n<\/code><\/pre>\n<p>the volume free space has decreased fro 57.29 to 47.09 GB<\/p>\n<pre><code>\n[grid@cloud ~]$ acfsutil snap info \/myacfs\nsnapshot name:               S1\nsnapshot location:           \/myacfs\/.ACFS\/snaps\/S1\nRO snapshot or RW snapshot:  RW\nparent name:                 \/myacfs\nsnapshot creation time:      Fri Jul  3 08:01:52 2020\nfile entry table allocation: 393216   ( 384.00 KB )\nstorage added to snapshot:   10846875648   (  10.10 GB )\n\n    number of snapshots:  1\n    snapshot space usage: 10846875648  (  10.10 GB )\n<\/code><\/pre>\n<p>10 GB has been added to the snapshot for the extents that are different than the parent.<\/p>\n<pre><code>\n[grid@cloud ~]$ acfsutil info fs \/myacfs\n\n\/myacfs\n    ACFS Version: 18.0.0.0.0\n    on-disk version:       47.0\n    compatible.advm:       18.0.0.0.0\n    ACFS compatibility:    18.0.0.0.0\n    flags:        MountPoint,Available\n    mount time:   Fri Jul  3 07:33:19 2020\n    mount sequence number: 6\n    allocation unit:       4096\n    metadata block size:   4096\n    volumes:      1\n    total size:   107374182400  ( 100.00 GB )\n    total free:   50566590464  (  47.09 GB )\n    file entry table allocation: 393216\n    primary volume: \/dev\/asm\/myadvm-19\n        label:\n        state:                 Available\n        major, minor:          248, 9731\n        logical sector size:   512\n        size:                  107374182400  ( 100.00 GB )\n        free:                  50566590464  (  47.09 GB )\n        metadata read I\/O count:         9447\n        metadata write I\/O count:        1030\n        total metadata bytes read:       82587648  (  78.76 MB )\n        total metadata bytes written:    89440256  (  85.30 MB )\n        ADVM diskgroup:        DATAC1\n        ADVM resize increment: 536870912\n        ADVM redundancy:       high\n        ADVM stripe columns:   8\n        ADVM stripe width:     1048576\n    number of snapshots:  1\n    snapshot space usage: 10846875648  (  10.10 GB )\n    replication status: DISABLED\n<\/code><\/pre>\n<p>The file entry table allocation has not changed. It was pointing to the parent for all extents before. Now, 10GB of extents are pointing to the snapshot child ones.<\/p>\n<h3>Write on parent<\/h3>\n<p>If I overwrite a different part on the parent, it will need to allocate new extents as those extents are share with the snapshot.<\/p>\n<pre><code>\n[grid@cloud ~]$ dd of=\/myacfs\/file.tmp if=\/dev\/zero bs=1G count=10 conv=notrunc seek=20\n\n10+0 records in\n10+0 records out\n10737418240 bytes (11 GB) copied, 35.938 s, 299 MB\/s\n<\/code><\/pre>\n<p>this has written 10GB again, but at the 20GB offset, not overlapping the range of extents modified in the snapshot.<\/p>\n<pre><code>\n[grid@cloud ~]$ df -Th \/myacfs\nFilesystem         Type  Size  Used Avail Use% Mounted on\n\/dev\/asm\/myadvm-19 acfs  100G   63G   38G  63% \/myacfs\n<\/code><\/pre>\n<p>Obviously 10GB had to be allocated for those new extents.<\/p>\n<pre><code>\n[grid@cloud ~]$ acfsutil snap info \/myacfs\nsnapshot name:               S1\nsnapshot location:           \/myacfs\/.ACFS\/snaps\/S1\nRO snapshot or RW snapshot:  RW\nparent name:                 \/myacfs\nsnapshot creation time:      Fri Jul  3 09:17:10 2020\nfile entry table allocation: 393216   ( 384.00 KB )\nstorage added to snapshot:   10846875648   (  10.10 GB )\n\n\n    number of snapshots:  1\n    snapshot space usage: 21718523904  (  20.23 GB )\n<\/code><\/pre>\n<p>Those 10GB modified on the base are allocated for the snapshot, because what was a pointer to the parent is now a copy of extents in the state they were before the write.<\/p>\n<p>I&#8217;m not going into details of copy-on-write or redirect-on-write. You can see that at file level with &#8220;acfsutil info file&#8221; and Ludovico Caldara made a great demo of it a few years ago:<br \/>\n<iframe loading=\"lazy\" title=\"ACFS Copy\/Redirect on Write (No audio)\" width=\"500\" height=\"281\" src=\"https:\/\/www.youtube.com\/embed\/jyHgpw2ZI5E?start=44&#038;feature=oembed\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share\" referrerpolicy=\"strict-origin-when-cross-origin\" allowfullscreen><\/iframe><\/p>\n<p>Now what happens if I modify, in the parent, the same extents that have been modified in the snapshot? I don&#8217;t need a copy of the previous version of them, right?<\/p>\n<pre><code>\n[grid@cloud ~]$ dd of=\/myacfs\/file.tmp if=\/dev\/zero bs=1G count=10 conv=notrunc\n\n10+0 records in\n10+0 records out\n10737418240 bytes (11 GB) copied, 34.9208 s, 307 MB\/s\n<\/code><\/pre>\n<p>The first 10GB of this file, since the snapshot was taken, have now been modified in the base and in all snapshots (only one here).<\/p>\n<pre><code>\n[grid@cloud ~]$ df -Th \/myacfs\nFilesystem         Type  Size  Used Avail Use% Mounted on\n\/dev\/asm\/myadvm-19 acfs  100G   74G   27G  74% \/myacfs\n<\/code><\/pre>\n<p>I had 10GB allocated again for this.<\/p>\n<pre><code>\n[grid@cloud ~]$ acfsutil snap info \/myacfs\nsnapshot name:               S1\nsnapshot location:           \/myacfs\/.ACFS\/snaps\/S1\nRO snapshot or RW snapshot:  RW\nparent name:                 \/myacfs\nsnapshot creation time:      Fri Jul  3 09:17:10 2020\nfile entry table allocation: 393216   ( 384.00 KB )\nstorage added to snapshot:   10846875648   (  10.10 GB )\n\n    number of snapshots:  1\n    snapshot space usage: 32564994048  (  30.33 GB )\n<\/code><\/pre>\n<pre><code>\n[grid@cloud ~]$ acfsutil info file \/myacfs\/.ACFS\/snaps\/S1\/file.tmp -u |\n                awk '\/(Yes|No)$\/{ if ( $7!=l ) o=$1 ; s[o]=s[o]+$2 ; i[o]=$7 ; l=$7} END{ for (o in s) printf \"offset: %4dGB size: %4dGB Inherited: %3sn\",o\/1024\/1024\/1024,s[o]\/1024\/1024\/1024,i[o]}' | sort\noffset:    0GB size:   10GB Inherited:  No\noffset:   10GB size:   31GB Inherited: Yes\n<\/code><\/pre>\n<p>I have aggregated, with awk, the range of snapshot extents that are inherited from the parent. The first 10GB are those that I modified in the snapshot. The others, above 10GB are from the S1 snapshot.<\/p>\n<pre><code>\n[grid@cloud ~]$ acfsutil info file \/myacfs\/file.tmp -u | \n                awk '\/(Yes|No)$\/{ if ( $7!=l ) o=$1 ; s[o]=s[o]+$2 ; i[o]=$7 ; l=$7} END{ for (o in s) printf \"offset: %4dGB size: %4dGB Inherited: %3s %sn\",o\/1024\/1024\/1024,s[o]\/1024\/1024\/1024,i[o],x[o]}' | sort\noffset:    0GB size:   10GB Inherited:  No\noffset:   10GB size:    9GB Inherited: Yes\noffset:   19GB size:   10GB Inherited:  No\noffset:   30GB size:   11GB Inherited: Yes\n<\/code><\/pre>\n<p>Here in the base snapshot I see as inherited, between parent and child, the two ranges that I modified: 10GB from offset 0GB and 10 GB from offset 20GB<\/p>\n<p>That&#8217;s the important point: when you take a snapshot, the modifications on the parent, as well as the modifications in the snapshot, will allocate new extents to add to the snapshot.<\/p>\n<h3>Why is this important?<\/h3>\n<p>This explains why, on ODA, all non-CDB databases are created on a snapshot that has been taken when the filesystem was empty.<\/p>\n<p>Read-write snapshots are really cool, especially with multitenant as they are automated with the CRATE PLUGGABLE DATABASE &#8230; SNAPSHOT COPY. But you must keep in mind that the snapshot is made at filesystem level (this may change in 20c with <a href=\"https:\/\/docs.oracle.com\/en\/database\/oracle\/oracle-database\/20\/acfsg\/acfs-commands-utilities.html#GUID-D8A5327F-E90D-43DC-978B-AB32C610A8ED\" target=\"_blank\" rel=\"noopener noreferrer\">File-Based Snapshots<\/a>). Any change to the master will allocate space, whether used or not in the snapshot copy.<\/p>\n<p>I blogged about that in the past: <a href=\"https:\/\/www.dbi-services.com\/blog\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/\" target=\"_blank\" rel=\"noopener noreferrer\">https:\/\/www.dbi-services.com\/blog\/multitenant-thin-provisioning-pdb-snapshots-on-acfs\/<\/a><\/p>\n<p>Here I just wanted to clarify what you see with &#8220;ls&#8221; and &#8220;du&#8221; vs. &#8220;df&#8221; or &#8220;acfsutil info&#8221;. &#8220;ls&#8221; and &#8220;du&#8221; show the virtual size of the files. &#8220;df&#8221; shows the extents allocated in the filesystem as base extents or snapshot copies. &#8220;acfsutil info&#8221; shows those extents allocated as &#8220;storage added to snapshot&#8221; whether they were allocated for modifications on the parent or child.<\/p>\n<pre><code>\n[grid@cloud ~]$ acfsutil info file \/myacfs\/.ACFS\/snaps\/S1\/file.tmp -u\n\/myacfs\/.ACFS\/snaps\/S1\/file.tmp\n\n    flags:        File\n    inode:        18014398509482026\n    owner:        grid\n    group:        oinstall\n    size:         45097156608  (  42.00 GB )\n    allocated:    45105545216  (  42.01 GB )\n    hardlinks:    1\n    device index: 1\n    major, minor: 248,9731\n    create time:  Fri Jul  3 07:36:45 2020\n    access time:  Fri Jul  3 07:36:45 2020\n    modify time:  Fri Jul  3 09:18:25 2020\n    change time:  Fri Jul  3 09:18:25 2020\n    extents:\n        -----offset ----length | -dev --------offset | inherited\n                  0  109051904 |    1    67511517184 | No\n          109051904  134217728 |    1    67620569088 | No\n          243269632  134217728 |    1    67754786816 | No\n          377487360  134217728 |    1    67889004544 | No\n          511705088  134217728 |    1    68023222272 | No\n          645922816  134217728 |    1    68157440000 | No\n          780140544  134217728 |    1    68291657728 | No\n          914358272  134217728 |    1    68425875456 | No\n         1048576000  134217728 |    1    68560093184 | No\n         1182793728  134217728 |    1    68694310912 | No\n...\n<\/code><\/pre>\n<p>The difference between &#8220;du&#8221; and &#8220;df&#8221;, which is also the &#8220;storage added to snapshot&#8221; displayed by &#8220;acfsutil snap info&#8221;, is what you see as &#8220;inherited&#8221;=No in &#8220;acfsutil info file -u&#8221; on all files, parent and child. Note that I didn&#8217;t use compression here, which is another reason for the difference between &#8220;du&#8221; and &#8220;df&#8221;.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>By Franck Pachot . This is a demo about Oracle ACFS snapshots, and how to understand the used and free space, as displayed by &#8220;df&#8221;, when there are modifications in the base parent or the snapshot children. The important concept to understand is that, when you take a snapshot, any modification to the child or [&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":[59],"tags":[1763,600,220,2003,2004,2005,64,96,458,66,223,237],"type_dbi":[],"class_list":["post-14351","post","type-post","status-publish","format-standard","hentry","category-oracle","tag-20c","tag-acfs","tag-cdb","tag-df","tag-du","tag-file-based","tag-multitenant","tag-oracle","tag-oracle-20c","tag-pdb","tag-pluggable-databases","tag-snapshot"],"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>Oracle ACFS: &quot;du&quot; vs. &quot;df&quot; and &quot;acfsutil info&quot; - 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-acfs-du-df\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Oracle ACFS: &quot;du&quot; vs. &quot;df&quot; and &quot;acfsutil info&quot;\" \/>\n<meta property=\"og:description\" content=\"By Franck Pachot . This is a demo about Oracle ACFS snapshots, and how to understand the used and free space, as displayed by &#8220;df&#8221;, when there are modifications in the base parent or the snapshot children. The important concept to understand is that, when you take a snapshot, any modification to the child or [&hellip;]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/oracle-acfs-du-df\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2020-07-03T10:19:24+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=\"17 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-acfs-du-df\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/oracle-acfs-du-df\/\"},\"author\":{\"name\":\"Oracle Team\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"headline\":\"Oracle ACFS: &#8220;du&#8221; vs. &#8220;df&#8221; and &#8220;acfsutil info&#8221;\",\"datePublished\":\"2020-07-03T10:19:24+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/oracle-acfs-du-df\/\"},\"wordCount\":1606,\"commentCount\":0,\"keywords\":[\"20c\",\"ACFS\",\"CDB\",\"df\",\"du\",\"file-based\",\"multitenant\",\"Oracle\",\"Oracle 20c\",\"PDB\",\"Pluggable Databases\",\"Snapshot\"],\"articleSection\":[\"Oracle\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/oracle-acfs-du-df\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/oracle-acfs-du-df\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/oracle-acfs-du-df\/\",\"name\":\"Oracle ACFS: \\\"du\\\" vs. \\\"df\\\" and \\\"acfsutil info\\\" - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"datePublished\":\"2020-07-03T10:19:24+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/oracle-acfs-du-df\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/oracle-acfs-du-df\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/oracle-acfs-du-df\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Oracle ACFS: &#8220;du&#8221; vs. &#8220;df&#8221; and &#8220;acfsutil info&#8221;\"}]},{\"@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 ACFS: \"du\" vs. \"df\" and \"acfsutil info\" - 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-acfs-du-df\/","og_locale":"en_US","og_type":"article","og_title":"Oracle ACFS: \"du\" vs. \"df\" and \"acfsutil info\"","og_description":"By Franck Pachot . This is a demo about Oracle ACFS snapshots, and how to understand the used and free space, as displayed by &#8220;df&#8221;, when there are modifications in the base parent or the snapshot children. The important concept to understand is that, when you take a snapshot, any modification to the child or [&hellip;]","og_url":"https:\/\/www.dbi-services.com\/blog\/oracle-acfs-du-df\/","og_site_name":"dbi Blog","article_published_time":"2020-07-03T10:19:24+00:00","author":"Oracle Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Oracle Team","Est. reading time":"17 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/oracle-acfs-du-df\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/oracle-acfs-du-df\/"},"author":{"name":"Oracle Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"headline":"Oracle ACFS: &#8220;du&#8221; vs. &#8220;df&#8221; and &#8220;acfsutil info&#8221;","datePublished":"2020-07-03T10:19:24+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/oracle-acfs-du-df\/"},"wordCount":1606,"commentCount":0,"keywords":["20c","ACFS","CDB","df","du","file-based","multitenant","Oracle","Oracle 20c","PDB","Pluggable Databases","Snapshot"],"articleSection":["Oracle"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/oracle-acfs-du-df\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/oracle-acfs-du-df\/","url":"https:\/\/www.dbi-services.com\/blog\/oracle-acfs-du-df\/","name":"Oracle ACFS: \"du\" vs. \"df\" and \"acfsutil info\" - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2020-07-03T10:19:24+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/oracle-acfs-du-df\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/oracle-acfs-du-df\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/oracle-acfs-du-df\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Oracle ACFS: &#8220;du&#8221; vs. &#8220;df&#8221; and &#8220;acfsutil info&#8221;"}]},{"@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\/14351","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=14351"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/14351\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=14351"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=14351"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=14351"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=14351"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}