{"id":9978,"date":"2017-04-25T20:24:14","date_gmt":"2017-04-25T18:24:14","guid":{"rendered":"https:\/\/www.dbi-services.com\/blog\/listener-and-virtual-ip\/"},"modified":"2017-04-25T20:24:14","modified_gmt":"2017-04-25T18:24:14","slug":"listener-and-virtual-ip","status":"publish","type":"post","link":"https:\/\/www.dbi-services.com\/blog\/listener-and-virtual-ip\/","title":{"rendered":"Listener and Virtual IP"},"content":{"rendered":"

By Franck Pachot<\/h2>\n

.
\nWhen you configure a standby database, you want the application to transparently connect to the primary database, wherever it is. That’s the role of Transparent Application Failover, but this requires configuration on the client side. If you can’t configure TAF, you can use a virtual IP address. But then the question is how to configure the listener.ora to handle connections to this VIP.
\n
\nDon’t worry, if you configured everything as recommended, with the hostname declared in \/etc\/hosts, and listener.ora referencing this host name, then you can simply ignore the VIP for your configuration. The reason is that when the host specified in the listener.ora resolves to the same IP address as the hostname of the server, then Oracle listener binds the port on all interfaces, and this includes the VIP.<\/p>\n

However, if you mentioned an IP address in the listener.ora, or if you mentioned a host that resolves to a different IP than the hostname, then it listens only tho this interface.<\/p>\n

Why not just listen to the VIP? There are two reasons for that. First, you will need to listen to the host IP anyway for the dynamic registration of instances. You don’t want the standby database to contact the listener on the primary server. The second reason is that you cannot start the listener if the IP is not up. Then, if you want to explicitly listen to the VIP you will need two listeners, some security rules to allow only local registration and to manage the start of the listener, monitoring, etc.<\/p>\n

The simplest configuration is to have one listener configured on the server hostname, then it listens on all interfaces and clients can connect with the VIP (for the application) or with the server IP (for Data Guard broker, backups, monitoring, administration).<\/p>\n

The behaviour is described in How The Listener Binds On TCP Protocol Addresses (Doc ID 421305.1)<\/a><\/p>\n

Examples<\/h3>\n

I have two network interfaces on my system, the loopback (lo) and Ethernet (enp0s3). This interface has the IP 192.168.78.104 and I have added a virtual IP 192.168.66.102 with:<\/p>\n

 ip a add 192.168.66.102\/24 dev enp0s3<\/code><\/pre>\n
Here is the list of interfaces:<\/p>\n
[oracle@VM104 tmp]$ ip a\n1: lo:  mtu 65536 qdisc noqueue state UNKNOWN\n    link\/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00\n    inet 127.0.0.1\/8 scope host lo\n    inet6 ::1\/128 scope host\n       valid_lft forever preferred_lft forever\n2: enp0s3:  mtu 1500 qdisc pfifo_fast state UP qlen 1000\n    link\/ether 08:00:cc:00:4e:68 brd ff:ff:ff:ff:ff:ff\n    inet 192.168.78.104\/24 brd 192.168.78.255 scope global enp0s3\n    inet 192.168.66.102\/24 scope global enp0s3\n    inet6 fe80::a00:ccff:fe00:4e68\/64 scope link\n       valid_lft forever preferred_lft forever\n<\/code><\/pre>\n
Here is the content of my \/etc\/hosts where I have two names that resolve to my server IP address 192.168.78.104<\/p>\n
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4\n::1         localhost localhost.localdomain localhost6 localhost6.localdomain6\n192.168.78.104 VM104 myhost\n<\/code><\/pre>\n
One of these names is my server hostname:<\/p>\n
\n[oracle@VM104 tmp]$ hostname\nVM104\n<\/code><\/pre>\n
I’ll try different configuration of my listener.ora<\/p>\n
(HOST=127.0.0.1)<\/h3>\n
I mentioned the IP address of the loopback interface<\/p>\n
\nListening Endpoints Summary...\n  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=6666)))\n<\/code><\/pre>\n
The listener listens to this address only:<\/p>\n
\n[oracle@VM104 tmp]$ ss -elpunt | grep -E \"^Net|tnslsnr\"\nNetid  State      Recv-Q Send-Q     Local Address:Port       Peer Address:Port\ntcp    LISTEN     0      128            127.0.0.1:6666                  *:*      users:((\"tnslsnr\",4685,8))\n<\/code><\/pre>\n
With this configuration, I’m able to connect only through the mentioned address, 127.0.0.1<\/p>\n
\nAttempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.78.104)(PORT=6666)))\nTNS-12541: TNS:no listener\nAttempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.66.102)(PORT=6666)))\nTNS-12541: TNS:no listener\nAttempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP)(HOST=127.0.0.1)(PORT=6666)))\nOK (10 msec)\n<\/code><\/pre>\n
(HOST=localhost)<\/h3>\n
I mentioned the loopback interface by a host name<\/p>\n
\nListening Endpoints Summary...\n  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=6666)))\n<\/code><\/pre>\n
This is actually the same as above: the host mentioned has been resolved at listener startup.<\/p>\n
(HOST=1192.168.78.104)<\/h3>\n
I mentioned the IP address of the host interface<\/p>\n
\nListening Endpoints Summary...\n  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.78.104)(PORT=6666)))\n<\/code><\/pre>\n
The listener listens to this address only:<\/p>\n
\n[oracle@VM104 tmp]$ ss -elpunt | grep -E \"^Net|tnslsnr\"\nNetid  State      Recv-Q Send-Q     Local Address:Port       Peer Address:Port\ntcp    LISTEN     0      128       192.168.78.104:6666                  *:*      users:((\"tnslsnr\",4735,8))\n<\/code><\/pre>\n
With this configuration, I’m able to connect only through the mentioned address, not the virtual IP, not other interfaces:<\/p>\n
\nAttempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.78.104)(PORT=6666)))\nOK (0 msec)\nAttempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.66.102)(PORT=6666)))\nTNS-12541: TNS:no listener\nAttempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP)(HOST=127.0.0.1)(PORT=6666)))\nTNS-12541: TNS:no listener\n<\/code><\/pre>\n
(HOST=localhost)<\/h3>\n
I mentioned the loopback interface by a host name<\/p>\n
\nListening Endpoints Summary...\n  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=127.0.0.1)(PORT=6666)))\n<\/code><\/pre>\n
This is actually the same as above: the host mentioned has been resolved at listener startup.<\/p>\n
(HOST=VM104)<\/h3>\n
I mentioned the host name which resolves to the IP address of the host interface – this is the default when creating with DBCA, and the recommended configuration.<\/p>\n
\nListening Endpoints Summary...\n  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=VM104)(PORT=6666)))\n<\/code><\/pre>\n
The listener socket do not mention the IP address:<\/p>\n
\n[oracle@VM104 tmp]$ ss -elpunt | grep -E \"^Net|tnslsnr\"\nNetid  State      Recv-Q Send-Q     Local Address:Port       Peer Address:Port\ntcp    LISTEN     0      128                   :::6666                 :::*      users:((\"tnslsnr\",4760,8))\n<\/code><\/pre>\n
We see something different here as there’s no mention of a local address in :::6666<\/p>\n
With this configuration, I’m able to connect through any IP address, including the virtual IP<\/p>\n
\nAttempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.78.104)(PORT=6666)))\nOK (0 msec)\nAttempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP)(HOST=192.168.66.102)(PORT=6666)))\nOK (10 msec)\nAttempting to contact (DESCRIPTION=(CONNECT_DATA=(SERVICE_NAME=))(ADDRESS=(PROTOCOL=TCP)(HOST=127.0.0.1)(PORT=6666)))\nOK (10 msec)\n<\/code><\/pre>\n
(HOST=myhost)<\/h3>\n
I mentioned another host name which resolves to the IP address of the host interface (see the \/etc\/hosts above). It is not the hostname returned by $(hostname) but it resolve to same IP.<\/p>\n
\nListening Endpoints Summary...\n  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=VM104)(PORT=6666)))\n<\/code><\/pre>\n
The listener has resolved the address through \/etc\/hosts and then, because the IP matches the resolution of $(hostname), has used the $(hostname). We are then in the same situation as above where we can connect through any interface:<\/p>\n
\n[oracle@VM104 tmp]$ ss -elpunt | grep -E \"^Net|tnslsnr\"\nNetid  State      Recv-Q Send-Q     Local Address:Port       Peer Address:Port\ntcp    LISTEN     0      128                   :::6666                 :::*      users:((\"tnslsnr\",4760,8))\n<\/code><\/pre>\n
(HOST=0.0.0.0)<\/h3>\n
Finally, when you want to listen on all interfaces, why not configure the host to 0.0.0.0<\/p>\n
\nListening Endpoints Summary...\n  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=VM104)(PORT=6666)))\n<\/code><\/pre>\n
We are again in the same situation here and the listener has replaced it with the hostname. This may be convenient when you want to use the same listener.ora for different hosts. However, as it finally show the hostname, better to avoid confusion and have it in the listener.ora<\/p>\n
(HOST=VM104)(IP=FIRST)<\/h3>\n
This is the way to bypass the ‘listen on all interfaces’ rule, even when you resolve to the hostname.<\/p>\n
\nListening Endpoints Summary...\n  (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=192.168.78.104)(PORT=6666)))\n<\/code><\/pre>\n
Because of (IP=FIRST) the listener listens to the first IP address returned by gethostbyname()<\/p>\n
Conclusion<\/h3>\n
It is easy to know if the listener listens on one specific IP address, or on all interfaces. You get the hostname and the listener endpoints<\/p>\n
\nhostname\nlsnrctl status\n<\/code><\/pre>\n
If the ‘HOST=’ matches the hostname, then it listens to all interfaces. If the ‘HOST=’ mentions an IP address, then it listens on this IP only. If it mentions a name which is not the hostname, then maybe someone has changed the hostname after the listener was started?<\/p>\n
The other way is to look at the socket information with:<\/p>\n
\nnetstat -elpunt\nss -elpunt\n<\/code><\/pre>\n
If you think that it is a security problem to listen to all interfaces, then you should understand that the listener is not a firewall. It is just a convenient way to route connections by service name to the right instance. But remember that you can even connect to the database without the listener (read https:\/\/amitzil.wordpress.com\/2015\/10\/19\/bypassing-the-listener\/<\/a>), just connecting to the dispatcher:<\/p>\n
\nAttempting to contact (DESCRIPTION=(CONNECT_DATA=(SID=CDB1))(ADDRESS=(PROTOCOL=TCP)(HOST=127.0.0.1)(PORT=30229)))\nOK (0 msec)\n<\/code><\/pre>\n
And this one listens to  all interfaces:<\/p>\n
\n[oracle@VM104 tmp]$ ss -elpunt | grep -E \"(^Net|ora_d)\"\nNetid  State      Recv-Q Send-Q     Local Address:Port       Peer Address:Port\ntcp    LISTEN     0      128                   :::30229                :::*      users:((\"ora_d000_cdb1\",1362,8)) uid:54321 ino:20635 sk:ffff880117900800 \ntcp    LISTEN     0      128                   :::32316                :::*      users:((\"ora_d000_cdb2\",1729,8)) uid:54321 ino:20958 sk:ffff880117900040 \n<\/code><\/pre>\n
Security is done by firewall rules. Listener is there only to help, so keep it simple.<\/p>\n","protected":false},"excerpt":{"rendered":"
By Franck Pachot . When you configure a standby database, you want the application to transparently connect to the primary database, wherever it is. That’s the role of Transparent Application Failover, but this requires configuration on the client side. If you can’t configure TAF, you can use a virtual IP address. But then the question […]<\/p>\n","protected":false},"author":27,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[198],"tags":[221,43,96,1078],"type_dbi":[],"class_list":["post-9978","post","type-post","status-publish","format-standard","hentry","category-database-management","tag-data-guard","tag-listener","tag-oracle","tag-vip"],"acf":[],"yoast_head":"\nListener and Virtual IP - 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\/listener-and-virtual-ip\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Listener and Virtual IP\" \/>\n<meta property=\"og:description\" content=\"By Franck Pachot . When you configure a standby database, you want the application to transparently connect to the primary database, wherever it is. That’s the role of Transparent Application Failover, but this requires configuration on the client side. If you can’t configure TAF, you can use a virtual IP address. But then the question […]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.dbi-services.com\/blog\/listener-and-virtual-ip\/\" \/>\n<meta property=\"og:site_name\" content=\"dbi Blog\" \/>\n<meta property=\"article:published_time\" content=\"2017-04-25T18:24:14+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=\"7 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\/listener-and-virtual-ip\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/listener-and-virtual-ip\/\"},\"author\":{\"name\":\"Oracle Team\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"headline\":\"Listener and Virtual IP\",\"datePublished\":\"2017-04-25T18:24:14+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/listener-and-virtual-ip\/\"},\"wordCount\":944,\"commentCount\":0,\"keywords\":[\"Data Guard\",\"Listener\",\"Oracle\",\"VIP\"],\"articleSection\":[\"Database management\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/listener-and-virtual-ip\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/listener-and-virtual-ip\/\",\"url\":\"https:\/\/www.dbi-services.com\/blog\/listener-and-virtual-ip\/\",\"name\":\"Listener and Virtual IP - dbi Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#website\"},\"datePublished\":\"2017-04-25T18:24:14+00:00\",\"author\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee\"},\"breadcrumb\":{\"@id\":\"https:\/\/www.dbi-services.com\/blog\/listener-and-virtual-ip\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.dbi-services.com\/blog\/listener-and-virtual-ip\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.dbi-services.com\/blog\/listener-and-virtual-ip\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Accueil\",\"item\":\"https:\/\/www.dbi-services.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Listener and Virtual IP\"}]},{\"@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":"Listener and Virtual IP - 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\/listener-and-virtual-ip\/","og_locale":"en_US","og_type":"article","og_title":"Listener and Virtual IP","og_description":"By Franck Pachot . When you configure a standby database, you want the application to transparently connect to the primary database, wherever it is. That’s the role of Transparent Application Failover, but this requires configuration on the client side. If you can’t configure TAF, you can use a virtual IP address. But then the question […]","og_url":"https:\/\/www.dbi-services.com\/blog\/listener-and-virtual-ip\/","og_site_name":"dbi Blog","article_published_time":"2017-04-25T18:24:14+00:00","author":"Oracle Team","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Oracle Team","Est. reading time":"7 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.dbi-services.com\/blog\/listener-and-virtual-ip\/#article","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/listener-and-virtual-ip\/"},"author":{"name":"Oracle Team","@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"headline":"Listener and Virtual IP","datePublished":"2017-04-25T18:24:14+00:00","mainEntityOfPage":{"@id":"https:\/\/www.dbi-services.com\/blog\/listener-and-virtual-ip\/"},"wordCount":944,"commentCount":0,"keywords":["Data Guard","Listener","Oracle","VIP"],"articleSection":["Database management"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/www.dbi-services.com\/blog\/listener-and-virtual-ip\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/www.dbi-services.com\/blog\/listener-and-virtual-ip\/","url":"https:\/\/www.dbi-services.com\/blog\/listener-and-virtual-ip\/","name":"Listener and Virtual IP - dbi Blog","isPartOf":{"@id":"https:\/\/www.dbi-services.com\/blog\/#website"},"datePublished":"2017-04-25T18:24:14+00:00","author":{"@id":"https:\/\/www.dbi-services.com\/blog\/#\/schema\/person\/66ab87129f2d357f09971bc7936a77ee"},"breadcrumb":{"@id":"https:\/\/www.dbi-services.com\/blog\/listener-and-virtual-ip\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.dbi-services.com\/blog\/listener-and-virtual-ip\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.dbi-services.com\/blog\/listener-and-virtual-ip\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Accueil","item":"https:\/\/www.dbi-services.com\/blog\/"},{"@type":"ListItem","position":2,"name":"Listener and Virtual IP"}]},{"@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\/9978","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=9978"}],"version-history":[{"count":0,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/posts\/9978\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/media?parent=9978"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/categories?post=9978"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/tags?post=9978"},{"taxonomy":"type","embeddable":true,"href":"https:\/\/www.dbi-services.com\/blog\/wp-json\/wp\/v2\/type_dbi?post=9978"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}