{"id":1568,"date":"2010-02-28T12:00:00","date_gmt":"2010-02-28T12:00:00","guid":{"rendered":"http:\/\/orcldoug.com\/blog\/?p=1568"},"modified":"2010-02-28T12:00:00","modified_gmt":"2010-02-28T12:00:00","slug":"statistics-on-partitioned-tables-part-4","status":"publish","type":"post","link":"http:\/\/orcldoug.com\/blog\/2010\/02\/28\/statistics-on-partitioned-tables-part-4\/","title":{"rendered":"Statistics on Partitioned Tables – Part 4"},"content":{"rendered":"

In the last post<\/a> I illustrated the problems you can run into when you rely on Oracle to aggregate statistics on partitions or subpartitions to generate estimated Global Statistics at higher levels of the table. Until there are statistics for all<\/em> of the relevant structures then aggregation won’t take place so, for example, if you have statistics for three out of four subpartitions, there won’t be any aggregated global statistics on the related partition until you gather statistics on the fourth subpartition. Randolf Geist left a comment<\/a> describing how you might avoid problems with this.<\/p>\n

“In order to solve the issue of adding partitions with initially missing
\nstatistics screwing up the aggregated statistics it was taken care that
\nnewly added subpartitions got their statistics immediately updated (with
\n 0 rows in that case) – which didn’t take a lot of time since the
\nsubpartitions were empty and it solved the issue with the aggregated
\nstatistics.<\/em>“<\/p>\n

That’s what our system does, but we introduced a change in the last release that caused the problems that inspired this series of posts …<\/p>\n

First let’s start with an empty table (definition hasn’t changed since the first post)<\/a>. Now, because we are so paranoid about partitions without stats, we’ll gather statistics at the PARTITION level even though the table is empty at the moment. I’m not going to specify a partition name here to cut the text back a bit, but on the real system we would have. Regardless, we’ll still see the same problematic end result.<\/p>\n

SQL> exec dbms_stats.gather_table_stats('TESTUSER', 'TEST_TAB1', GRANULARITY => 'PARTITION');\n\nPL\/SQL procedure successfully completed.\n\nSQL> select     table_name, global_stats, last_analyzed, num_rows\n  2  from dba_tables\n  3  where table_name='TEST_TAB1'\n  4  and owner='TESTUSER'\n  5  order by 1, 2, 4 desc nulls last;\n\nTABLE_NAME                     GLO LAST_ANALYZED          NUM_ROWS\n------------------------------ --- -------------------- ----------\nTEST_TAB1                      NO  28-FEB-2010 08:04:24          0\n<\/pre>\n
OK, so the table statistics aren’t true Global Statistics but that’s ok, we know about that. We also know that there’s no data in the table at this stage so the stats reflect that. When we look at the Partition level stats :-<\/p>\n
SQL> select     table_name, partition_name, global_stats, last_analyzed, num_rows\n  2  from dba_tab_partitions\n  3  where table_name='TEST_TAB1'\n  4  and table_owner='TESTUSER'\n  5  order by 1, 2, 4 desc nulls last;\n\nTABLE_NAME                     PARTITION_NAME                 GLO LAST_ANALYZED          NUM_ROWS\n------------------------------ ------------------------------ --- -------------------- ----------\nTEST_TAB1                      P_20100131                     YES 28-FEB-2010 08:04:24          0\nTEST_TAB1                      P_20100201                     YES 28-FEB-2010 08:04:24          0\nTEST_TAB1                      P_20100202                     YES 28-FEB-2010 08:04:24          0\nTEST_TAB1                      P_20100203                     YES 28-FEB-2010 08:04:24          0\nTEST_TAB1                      P_20100204                     YES 28-FEB-2010 08:04:24          0\nTEST_TAB1                      P_20100205                     YES 28-FEB-2010 08:04:24          0\nTEST_TAB1                      P_20100206                     YES 28-FEB-2010 08:04:24          0\nTEST_TAB1                      P_20100207                     YES 28-FEB-2010 08:04:24          0\n\n8 rows selected.\n<\/pre>\n
They are true global statistics, albeit on no data at this stage, but at least we have some statistics to reflect that. Looking at the Subpartition stats :-<\/p>\n
SQL> select     table_name, subpartition_name, global_stats, last_analyzed, num_rows\n  2  from dba_tab_subpartitions\n  3  where table_name='TEST_TAB1'\n  4  and table_owner='TESTUSER'\n  5  order by 1, 2, 4 desc nulls last;\n\nTABLE_NAME                     SUBPARTITION_NAME              GLO LAST_ANALYZED          NUM_ROWS\n------------------------------ ------------------------------ --- -------------------- ----------\nTEST_TAB1                      P_20100131_GROT                NO\nTEST_TAB1                      P_20100131_HALO                NO\nTEST_TAB1                      P_20100131_JUNE                NO\nTEST_TAB1                      P_20100131_OTHERS              NO\nTEST_TAB1                      P_20100201_GROT                NO\nTEST_TAB1                      P_20100201_HALO                NO\nTEST_TAB1                      P_20100201_JUNE                NO\nTEST_TAB1                      P_20100201_OTHERS              NO\n\n<<output snipped>>\n\nTEST_TAB1                      P_20100206_GROT                NO\nTEST_TAB1                      P_20100206_HALO                NO\nTEST_TAB1                      P_20100206_JUNE                NO\nTEST_TAB1                      P_20100206_OTHERS              NO\nTEST_TAB1                      P_20100207_GROT                NO\nTEST_TAB1                      P_20100207_HALO                NO\nTEST_TAB1                      P_20100207_JUNE                NO\nTEST_TAB1                      P_20100207_OTHERS              NO\n\n32 rows selected.\n<\/pre>\n
No subpartition stats at all at this stage which is expected behaviour and we’ll be gathering them later after we load the data. I’m going to skip the column statistics at this stage because I don’t need them to illustrate the problem. So let’s imagine that on the live system we’ve just created the partitions above and are about to load data into the P_20100206_GROT subpartition.<\/p>\n
SQL> INSERT INTO TEST_TAB1 VALUES (20100206, 'GROT', 100000, 'P');\n\n1 row created.\n\nSQL> INSERT INTO TEST_TAB1 VALUES (20100206, 'GROT', 3000000, 'P');\n\n1 row created.\n\nSQL> INSERT INTO TEST_TAB1 VALUES (20100206, 'GROT', 200000, 'P');\n\n1 row created.\n\nSQL> INSERT INTO TEST_TAB1 VALUES (20100206, 'GROT', 110000, 'P');\n\n1 row created.\n\nSQL> INSERT INTO TEST_TAB1 VALUES (20100206, 'GROT', 240000, 'U');\n\n1 row created.\n\nSQL> COMMIT;\n\nCommit complete.\n<\/pre>\n
Next our normal stats gathering approach is invoked and we gather stats on the subpartition just loaded.<\/p>\n
SQL> exec dbms_stats.gather_table_stats('TESTUSER', 'TEST_TAB1', GRANULARITY => 'SUBPARTITION', \n                                         PARTNAME => 'P_20100206_GROT');\n\nPL\/SQL procedure successfully completed.\n<\/pre>\n
N.B. It’s probably worth pointing out at this stage that I put a short pause
\n in the test script between the original stats gathering on the empty
\ntable and the INSERTs and gather on the newly-loaded subpartition so you might want
\nto pay attention to the LAST_ANALYZED values here.<\/p>\n
So how do the stats look?<\/p>\n
SQL> select     table_name, global_stats, last_analyzed, num_rows\n  2  from dba_tables\n  3  where table_name='TEST_TAB1'\n  4  and owner='TESTUSER'\n  5  order by 1, 2, 4 desc nulls last;\n\nTABLE_NAME                     GLO LAST_ANALYZED          NUM_ROWS\n------------------------------ --- -------------------- ----------\nTEST_TAB1                      NO  28-FEB-2010 08:06:25          0\n<\/pre>\n
Mmmmmm …. I can see that the LAST_ANALYZED time has been updated, but NUM_ROWS is still 0 at the table level. How about the partitions?<\/p>\n
SQL> select     table_name, partition_name, global_stats, last_analyzed, num_rows\n  2  from dba_tab_partitions\n  3  where table_name='TEST_TAB1'\n  4  and table_owner='TESTUSER'\n  5  order by 1, 2, 4 desc nulls last;\n\nTABLE_NAME                     PARTITION_NAME                 GLO LAST_ANALYZED          NUM_ROWS\n------------------------------ ------------------------------ --- -------------------- ----------\nTEST_TAB1                      P_20100131                     YES 28-FEB-2010 08:04:24          0\nTEST_TAB1                      P_20100201                     YES 28-FEB-2010 08:04:24          0\nTEST_TAB1                      P_20100202                     YES 28-FEB-2010 08:04:24          0\nTEST_TAB1                      P_20100203                     YES 28-FEB-2010 08:04:24          0\nTEST_TAB1                      P_20100204                     YES 28-FEB-2010 08:04:24          0\nTEST_TAB1                      P_20100205                     YES 28-FEB-2010 08:04:24          0\nTEST_TAB1                      P_20100206                     YES 28-FEB-2010 08:04:24          0\nTEST_TAB1                      P_20100207                     YES 28-FEB-2010 08:04:24          0\n\n8 rows selected.\n<\/pre>\n
So, as far as the Table and Partition Statistics look, this table is still empty! That’s not good and I can imagine a near future of execution plans with CARDINALITY=1 and MERGE JOIN CARTESIAN. Looking at the LAST_ANALYSED values on the Partitions, I can see that the timestamp hasn’t changed, which is another sign that something is wrong.<\/p>\n
I’ll check that the subpartition stats were gathered correctly.<\/p>\n
SQL> select     table_name, subpartition_name, global_stats, last_analyzed, num_rows\n  2  from dba_tab_subpartitions\n  3  where table_name='TEST_TAB1'\n  4  and table_owner='TESTUSER'\n  5  order by 1, 2, 4 desc nulls last;\n\nTABLE_NAME                     SUBPARTITION_NAME              GLO LAST_ANALYZED          NUM_ROWS\n------------------------------ ------------------------------ --- -------------------- ----------\nTEST_TAB1                      P_20100131_GROT                NO\nTEST_TAB1                      P_20100131_HALO                NO\nTEST_TAB1                      P_20100131_JUNE                NO\nTEST_TAB1                      P_20100131_OTHERS              NO\nTEST_TAB1                      P_20100201_GROT                NO\nTEST_TAB1                      P_20100201_HALO                NO\nTEST_TAB1                      P_20100201_JUNE                NO\nTEST_TAB1                      P_20100201_OTHERS              NO\n\n<<output snipped>>\n\nTEST_TAB1                      P_20100206_GROT                YES 28-FEB-2010 08:06:25          5\nTEST_TAB1                      P_20100206_HALO                NO\nTEST_TAB1                      P_20100206_JUNE                NO\nTEST_TAB1                      P_20100206_OTHERS              NO\nTEST_TAB1                      P_20100207_GROT                NO\nTEST_TAB1                      P_20100207_HALO                NO\nTEST_TAB1                      P_20100207_JUNE                NO\nTEST_TAB1                      P_20100207_OTHERS              NO\n\n32 rows selected.\n<\/pre>\n
Ah, perhaps that’s what the problem is. Only one of the P_20100206 subpartitions has valid stats so Oracle can not generate aggregated Global Stats at the higher levels\u00a0 of the table. So I’ll try to fix that by gathering statistic on all of the subpartitions in the table. (In fact, I only really need to gather stats on the remaining P_20100206 subpartitions but I’ll use this approach for brevity)<\/p>\n
SQL> exec dbms_stats.gather_table_stats('TESTUSER', 'TEST_TAB1', GRANULARITY => 'SUBPARTITION');\n\nPL\/SQL procedure successfully completed.\n<\/pre>\n
Let’s check that all of the subpartitions have valid statistics now.<\/p>\n
SQL> select     table_name, subpartition_name, global_stats, last_analyzed, num_rows\n  2  from dba_tab_subpartitions\n  3  where table_name='TEST_TAB1'\n  4  and table_owner='TESTUSER'\n  5  order by 1, 2, 4 desc nulls last;\n\nTABLE_NAME                     SUBPARTITION_NAME              GLO LAST_ANALYZED          NUM_ROWS\n------------------------------ ------------------------------ --- -------------------- ----------\nTEST_TAB1                      P_20100131_GROT                YES 28-FEB-2010 08:06:25          0\nTEST_TAB1                      P_20100131_HALO                YES 28-FEB-2010 08:06:25          0\nTEST_TAB1                      P_20100131_JUNE                YES 28-FEB-2010 08:06:25          0\nTEST_TAB1                      P_20100131_OTHERS              YES 28-FEB-2010 08:06:25          0\nTEST_TAB1                      P_20100201_GROT                YES 28-FEB-2010 08:06:25          0\nTEST_TAB1                      P_20100201_HALO                YES 28-FEB-2010 08:06:25          0\nTEST_TAB1                      P_20100201_JUNE                YES 28-FEB-2010 08:06:25          0\nTEST_TAB1                      P_20100201_OTHERS              YES 28-FEB-2010 08:06:25          0\n\n<<output snipped>>\n\nTEST_TAB1                      P_20100206_GROT                YES 28-FEB-2010 08:06:25          5\nTEST_TAB1                      P_20100206_HALO                YES 28-FEB-2010 08:06:25          0\nTEST_TAB1                      P_20100206_JUNE                YES 28-FEB-2010 08:06:25          0\nTEST_TAB1                      P_20100206_OTHERS              YES 28-FEB-2010 08:06:25          0\nTEST_TAB1                      P_20100207_GROT                YES 28-FEB-2010 08:06:25          0\nTEST_TAB1                      P_20100207_HALO                YES 28-FEB-2010 08:06:25          0\nTEST_TAB1                      P_20100207_JUNE                YES 28-FEB-2010 08:06:25          0\nTEST_TAB1                      P_20100207_OTHERS              YES 28-FEB-2010 08:06:25          0\n\n32 rows selected.\n\n<\/pre>\n
OK, so Oracle should have aggregated the subpartition stats to generate global stats on the partitions and table.<\/p>\n
SQL> select     table_name, global_stats, last_analyzed, num_rows\n  2  from dba_tables\n  3  where table_name='TEST_TAB1'\n  4  and owner='TESTUSER'\n  5  order by 1, 2, 4 desc nulls last;\n\nTABLE_NAME                     GLO LAST_ANALYZED          NUM_ROWS\n------------------------------ --- -------------------- ----------\nTEST_TAB1                      NO  28-FEB-2010 08:06:25          0\n\nSQL> \nSQL> select     table_name, partition_name, global_stats, last_analyzed, num_rows\n  2  from dba_tab_partitions\n  3  where table_name='TEST_TAB1'\n  4  and table_owner='TESTUSER'\n  5  order by 1, 2, 4 desc nulls last;\n\nTABLE_NAME                     PARTITION_NAME                 GLO LAST_ANALYZED          NUM_ROWS\n------------------------------ ------------------------------ --- -------------------- ----------\nTEST_TAB1                      P_20100131                     YES 28-FEB-2010 08:04:24          0\nTEST_TAB1                      P_20100201                     YES 28-FEB-2010 08:04:24          0\nTEST_TAB1                      P_20100202                     YES 28-FEB-2010 08:04:24          0\nTEST_TAB1                      P_20100203                     YES 28-FEB-2010 08:04:24          0\nTEST_TAB1                      P_20100204                     YES 28-FEB-2010 08:04:24          0\nTEST_TAB1                      P_20100205                     YES 28-FEB-2010 08:04:24          0\nTEST_TAB1                      P_20100206                     YES 28-FEB-2010 08:04:24          0\nTEST_TAB1                      P_20100207                     YES 28-FEB-2010 08:04:24          0\n\n8 rows selected.\n<\/pre>\n
So, according to the table and the partition stats, the table is still<\/em> empty and those partition statistics still<\/em> haven’t been updated!<\/p>\n
The problem here is that Oracle won’t overwrite true global stats with aggregated global stats. When you think about it, that’s a sensible approach because if I have a strategy of collecting Table and Partition stats (i.e. the Oracle-recommended strategy covered in the first post) then the last thing I want is those global stats constantly being overwritten by aggregated stats (with incorrect NDVs) when stats are gathered on subpartitions!<\/p>\n
Our mistake here could be viewed as a combination of a) not following Oracle recommendations (because if we did, we’d also be gathering global stats on the Table and Partitions using a seperate task and b) once we depart from that strategy, gathering stats at the incorrect level. Those Partition stats that we gathered can never be over-written except by gathering stats again on the Partitions, which would then be aggregated up to the table level.<\/p>\n
Allowing for the fact we want to (have to?), use our current approach, we should only ever gather stats at the SUBPARTITION level which will then be aggregated up to the Table and the Partition level. <\/p>\n
As for the fix, we deleted the existing stats, to rid the partitions of their global stats and then regathered at the SUBPARTITION level as a one-off exercise. <\/p>\n
SQL> exec dbms_stats.delete_table_stats('TESTUSER', 'TEST_TAB1')\n\nPL\/SQL procedure successfully completed.\n\nSQL> exec dbms_stats.gather_table_stats('TESTUSER', 'TEST_TAB1', GRANULARITY => 'SUBPARTITION');\n\nPL\/SQL procedure successfully completed.\n<\/pre>\n
The important change is that we now have aggregated stats at both the Table and Partition levels which can then be updated by the aggregation process as we gather stats on new SUBPARTITIONS. Checking the statistics on the Table and Partitions …<\/p>\n
SQL> select     table_name, global_stats, last_analyzed, num_rows\n  2  from dba_tables\n  3  where table_name='TEST_TAB1'\n  4  and owner='TESTUSER'\n  5  order by 1, 2, 4 desc nulls last;\n\nTABLE_NAME                     GLO LAST_ANALYZED          NUM_ROWS\n------------------------------ --- -------------------- ----------\nTEST_TAB1                      NO  28-FEB-2010 08:06:26          5\n\nSQL> \nSQL> select     table_name, partition_name, global_stats, last_analyzed, num_rows\n  2  from dba_tab_partitions\n  3  where table_name='TEST_TAB1'\n  4  and table_owner='TESTUSER'\n  5  order by 1, 2, 4 desc nulls last;\n\nTABLE_NAME                     PARTITION_NAME                 GLO LAST_ANALYZED          NUM_ROWS\n------------------------------ ------------------------------ --- -------------------- ----------\nTEST_TAB1                      P_20100131                     NO  28-FEB-2010 08:06:26          0\nTEST_TAB1                      P_20100201                     NO  28-FEB-2010 08:06:26          0\nTEST_TAB1                      P_20100202                     NO  28-FEB-2010 08:06:26          0\nTEST_TAB1                      P_20100203                     NO  28-FEB-2010 08:06:26          0\nTEST_TAB1                      P_20100204                     NO  28-FEB-2010 08:06:26          0\nTEST_TAB1                      P_20100205                     NO  28-FEB-2010 08:06:26          0\nTEST_TAB1                      P_20100206                     NO  28-FEB-2010 08:06:26          5\nTEST_TAB1                      P_20100207                     NO  28-FEB-2010 08:06:26          0\n\n8 rows selected\n<\/pre>\n
All of the partition stats have been updated and are now aggregated<\/em> rather than true global stats. A modification to the metadata that our stats process uses to change the
\n granularity from PARTITION to SUBPARTITION will ensure stats are always gathered at the subpartition level and stop the problem from
\nre-occuring.<\/p>\n
You could argue that we could have avoided all of this by just using the default stats gathering strategy and not try to be too clever, but we would really struggle to support the required additional workload. Oh, and this example makes the problem obvious because the stats were
\ngathered on empty partitions, we knew we’d done so and it was relatively easy to spot zero-row partitions, but imagine if
\nsomeone gathered statistics on your partitions manually for some reason
\n(it wouldn’t be difficult to decide that seemed sensible) and the row counts for partitions are several million or so, frozen and
\nstuck that way forever until someone decides to repeat the process? Would you really notice the aggregation process
\nwasn’t working for some reason?<\/p>\n
Regardless of whether the problem is self-inflicted, as soon as we
\nspotted this mistake, I could imagine others making the same mistake if
\n they don’t understand the aggregation process fully. <\/p>\n
In the next few posts I’ll look at some of the new approaches Oracle has introduced which we’ve investigated, to see if they can help us to gather better global statistics and\/or reduce our stats-gathering workload.<\/p>\n","protected":false},"excerpt":{"rendered":"
In the last post I illustrated the problems you can run into when you rely on Oracle to aggregate statistics on partitions or subpartitions to generate estimated Global Statistics at higher levels of the table. Until there are statistics for all of the relevant structures then aggregation won’t take place so, for example, if you… Continue reading Statistics on Partitioned Tables – Part 4<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1568","post","type-post","status-publish","format-standard","hentry","category-uncategorized","entry"],"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":1632,"url":"http:\/\/orcldoug.com\/blog\/2011\/03\/12\/symposium-2011-my-presentation\/","url_meta":{"origin":1568,"position":0},"title":"Symposium 2011 – My Presentation","date":"March 12, 2011","format":false,"excerpt":"I think the best approach here is to focus on the technical details of the mistake first and then follow with any whining, self-justification or philosophy. The mistake I made in my presentation was to suggest at least twice that simply adding a new partition to a composite partitioned object\u2026","rel":"","context":"With 4 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1563,"url":"http:\/\/orcldoug.com\/blog\/2010\/02\/22\/statistics-on-partitioned-tables-part-2\/","url_meta":{"origin":1568,"position":1},"title":"Statistics on Partitioned Tables – Part 2","date":"February 22, 2010","format":false,"excerpt":"In the last part, I asked you to trust me that true Global Stats are a good thing so in this post I hope to show you why they are, to make sure you don't kid yourself that you can avoid them. (Updated later - this is all on 10.2.0.4)Why\u2026","rel":"","context":"With 6 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1570,"url":"http:\/\/orcldoug.com\/blog\/2010\/02\/28\/statistics-on-partitioned-tables-part-5\/","url_meta":{"origin":1568,"position":2},"title":"Statistics on Partitioned Tables – Part 5","date":"February 28, 2010","format":false,"excerpt":"Actually, before looking at any recent features, let me introduce one more aspect of the existing aggregation approach used by Oracle. The examples used to date have been based on INSERTing new rows into subpartitions and, although that's the approach used for some of our tables and will suit some\u2026","rel":"","context":"With 18 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1562,"url":"http:\/\/orcldoug.com\/blog\/2010\/02\/17\/statistics-on-partitioned-tables-part-1\/","url_meta":{"origin":1568,"position":3},"title":"Statistics on Partitioned Tables – Part 1","date":"February 17, 2010","format":false,"excerpt":"If you've ever worked on large databases that use partitioned and subpartitioned tables, you'll be aware that there are significant challenges in maintaining up-to-date\/appropriate statistics. We've encountered a few problems at work recently and I decided it would be an idea to put together a series of posts covering the\u2026","rel":"","context":"With 11 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1596,"url":"http:\/\/orcldoug.com\/blog\/2010\/04\/22\/statistics-on-partitioned-tables-part-6a-copy_table_stats-intro\/","url_meta":{"origin":1568,"position":4},"title":"Statistics on Partitioned Tables – Part 6a – COPY_TABLE_STATS – Intro","date":"April 22, 2010","format":false,"excerpt":"[Phew. At last. The first draft of this was dated more than two weeks ago .... One of the problems with blogging about copying stats was the balance between explaining it and pointing out some of the problems I've encountered. So I've broken up this post, with a little explanation\u2026","rel":"","context":"With 4 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]},{"id":1565,"url":"http:\/\/orcldoug.com\/blog\/2010\/02\/23\/statistics-on-partitioned-tables-part-3\/","url_meta":{"origin":1568,"position":5},"title":"Statistics on Partitioned Tables – Part 3","date":"February 23, 2010","format":false,"excerpt":"As soon as I'd committed my last post, I knew it wasn't what I'd hoped for and said as much to a couple of people before they'd read it. I knew it would probably just add to any confusion people already had about this subject (something I'm particularly keen to\u2026","rel":"","context":"With 11 comments","img":{"alt_text":"","src":"","width":0,"height":0},"classes":[]}],"_links":{"self":[{"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/posts\/1568","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/comments?post=1568"}],"version-history":[{"count":0,"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/posts\/1568\/revisions"}],"wp:attachment":[{"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/media?parent=1568"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/categories?post=1568"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/orcldoug.com\/blog\/wp-json\/wp\/v2\/tags?post=1568"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}