{"id":1612,"date":"2020-06-21T23:08:06","date_gmt":"2020-06-22T02:08:06","guid":{"rendered":"https:\/\/thesqltimes.com\/blog\/?p=1612"},"modified":"2020-06-22T12:20:23","modified_gmt":"2020-06-22T15:20:23","slug":"backup-to-url-tamanho-backup-1","status":"publish","type":"post","link":"https:\/\/thesqltimes.com\/blog\/2020\/06\/21\/backup-to-url-tamanho-backup-1\/","title":{"rendered":"BACKUP TO URL e o Tamanho do Backup &#8211; [1] Teoria&#8230;"},"content":{"rendered":"<div class=\"pld-like-dislike-wrap pld-template-1\">\r\n    <div class=\"pld-like-wrap  pld-common-wrap\">\r\n    <a href=\"javascript:void(0)\" class=\"pld-like-trigger pld-like-dislike-trigger  \" title=\"Muito \u00fatil!\" data-post-id=\"1612\" data-trigger-type=\"like\" data-restriction=\"cookie\" data-already-liked=\"0\">\r\n                        <i class=\"fas fa-thumbs-up\"><\/i>\r\n                <\/a>\r\n    <span class=\"pld-like-count-wrap pld-count-wrap\">    <\/span>\r\n<\/div><\/div><div class=\"seriesmeta\">Post 1\/1. Este post \u00e9 parte da s\u00e9rie: <a href=\"https:\/\/thesqltimes.com\/blog\/series\/backup-to-url-e-o-tamanho-do-backup\/\" class=\"series-348\" title=\"Backup To URL e o Tamanho do Backup\">Backup To URL e o Tamanho do Backup<\/a>\r\n<\/div>\r\n<span class=\"span-reading-time rt-reading-time\" style=\"display: block;\"><span class=\"rt-label rt-prefix\">Tempo de Leitura:<\/span> <span class=\"rt-time\"> 6<\/span> <span class=\"rt-label rt-postfix\">minutos<\/span><\/span><p><\/p>\r\n<p>Neste post vou iniciar mais uma s\u00e9rie que nasceu de mais dia de trabalho na <a href=\"https:\/\/powertuning.com.br\/\">Power Tuning<\/a> (na verdade, uns dois ou tr\u00eas). Cada vez mais empresas cedendo \u00e0s maravilhas da Cloud, especialmente do Azure. No caso do SQL Server, ele tem uma integra\u00e7\u00e3o fant\u00e1stica e nativa: Voc\u00ea pode fazer o backup do seu banco direto pra uma <strong>Storage Account<\/strong>. Em outras palavras, seu backup j\u00e1 vai direto pro Azure (isto \u00e9, n\u00e3o fica local), e nem passa por um filesystem do seu servidor&#8230; Isso protege ainda mais contra ataques, como ransomware&#8230; \u00c9 relativamente simples configurar isso&#8230; Tudo que voc\u00ea precisa \u00e9 configurar um local no Azure e usar o comando <a href=\"https:\/\/docs.microsoft.com\/en-us\/sql\/relational-databases\/backup-restore\/sql-server-backup-to-url?view=sql-server-ver15\">BACKUP &#8230; TO URL<\/a>!<\/p>\r\n<p>Se voc\u00ea \u00e9 um pai de primeira viagem, ou mesmo experiente no assunto, voc\u00ea pode ser pego de surpresa em suas tentativas e se deparar com o seguinte erro ao executar comando BACKUP &#8230; TO URL:<\/p>\r\n<p id=\"VsvQMgR\"><a href=\"https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5eefec66f358d.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone wp-image-1604 size-full\" src=\"https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5eefec66f358d.png\" alt=\"\" width=\"1825\" height=\"282\" srcset=\"https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5eefec66f358d.png 1825w, https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5eefec66f358d-300x46.png 300w, https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5eefec66f358d-1024x158.png 1024w, https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5eefec66f358d-768x119.png 768w, https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5eefec66f358d-1536x237.png 1536w\" sizes=\"auto, (max-width: 1825px) 100vw, 1825px\" \/><\/a><\/p>\r\n<p><span style=\"color: #ff0000;\">Msg 3202, Level 16, State 1, Line 4<\/span><br \/><span style=\"color: #ff0000;\">Write on &#8220;https:\/\/ENDERE\u00c7O-BLOB\/CONTAINER\/.bak&#8221; failed: 1117(The request could not be performed because of an I\/O device error.)<\/span><br \/><span style=\"color: #ff0000;\">Msg 3013, Level 16, State 1, Line 4<\/span><br \/><span style=\"color: #ff0000;\">BACKUP DATABASE is terminating abnormally.<\/span><\/p>\r\n<p>Analisando o error log do SQL Server, voc\u00ea encontra a seguinte mensagem:<\/p>\r\n<p id=\"SdttRmW\"><a href=\"https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5eefecd75094b.png\"><img loading=\"lazy\" decoding=\"async\" class=\"alignnone wp-image-1605 size-full\" src=\"https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5eefecd75094b.png\" alt=\"\" width=\"2369\" height=\"486\" srcset=\"https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5eefecd75094b.png 2369w, https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5eefecd75094b-300x62.png 300w, https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5eefecd75094b-1024x210.png 1024w, https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5eefecd75094b-768x158.png 768w, https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5eefecd75094b-1536x315.png 1536w, https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5eefecd75094b-2048x420.png 2048w\" sizes=\"auto, (max-width: 2369px) 100vw, 2369px\" \/><\/a><\/p>\r\n<p style=\"padding-left: 40px;\">BACKUP DATABASE successfully processed 547 pages in 1.408 seconds (3.032 MB\/sec).<br \/>Error: 3063, Severity: 16, State: 1.<br \/>Write to backup block blob device https:\/\/thest.blob.core.windows.net\/sqlbackup\/BakTest.bak failed. Device <strong>has reached its limit of allowed blocks.<br \/><\/strong><br \/>Error: 3063, Severity: 16, State: 1.<br \/>Write to backup block blob device https:\/\/thest.blob.core.windows.net\/sqlbackup\/BakTest.bak failed. Device <strong>has reached its limit of allowed blocks.<br \/><\/strong><br \/>Error: 3063, Severity: 16, State: 1.<br \/>Write to backup block blob device https:\/\/thest.blob.core.windows.net\/sqlbackup\/BakTest.bak failed. Device <strong>has reached its limit of allowed blocks.<br \/><\/strong><br \/>Error: 3063, Severity: 16, State: 1.<br \/>Write to backup block blob device https:\/\/thest.blob.core.windows.net\/sqlbackup\/BakTest.bak failed. Device <strong>has reached its limit of allowed blocks.<br \/><\/strong><br \/>Error: 3063, Severity: 16, State: 1.<br \/>Write to backup block blob device https:\/\/thest.blob.core.windows.net\/sqlbackup\/BakTest.bak failed. Device<strong> has reached its limit of allowed blocks.<br \/><\/strong><br \/>Error: 18210, Severity: 16, State: 1.<br \/>BackupIoRequest::ReportIoError: write failure on backup device &#8216;https:\/\/thest.blob.core.windows.net\/sqlbackup\/BakTest.bak&#8217;. Operating system error 1117(<strong>The request could not be performed because of an I\/O device error<\/strong>.).<br \/><br \/>Error: 3041, Severity: 16, State: 1.<br \/>BACKUP failed to complete the command BACKUP DATABASE BigBakTest. Check the backup application log for detailed messages.<\/p>\r\n<p>Com algumas pesquisas, voc\u00ea chega <a href=\"https:\/\/techcommunity.microsoft.com\/t5\/datacat\/backing-up-a-vldb-to-azure-blob-storage\/ba-p\/305441\">nesse excelente post do Dimitri Furman<\/a>\u00a0que basicamente resume como o SQL Server se integra com o Azure e como tudo isso funciona! Recomendo muito a leitura. Mas vou facilitar para voc\u00ea:<\/p>\r\n<ul>\r\n<li>Cada arquivo que voc\u00ea especifica no TO URL \u00e9 chamado de <strong>Block Blob<\/strong> (a partir daqui, irei chamar de <em>arquivo ou<\/em>\u00a0<em>block blob<\/em>)<\/li>\r\n<li>Um Block Blob \u00e9 composto por at\u00e9 50 mil blocos.<\/li>\r\n<li>O SQL Server utiliza a <a href=\"https:\/\/docs.microsoft.com\/en-us\/rest\/api\/storageservices\/blob-service-rest-api\">API do Azure<\/a> para escrever os dados (igual ele usa a API do Windows para escrever no disco)\r\n<ul>\r\n<li>\u00a0Cada bloco pode ter at\u00e9 100MB na vers\u00e3o mais nova da API, e at\u00e9 4MB nas vers\u00f5es anteiores a 2016-05-31\u00a0<\/li>\r\n<li>A vers\u00e3o da API que o SQL utiliza \u00e9 anterior a 2016-05-31, ou seja, permite at\u00e9 4MB por bloco<\/li>\r\n<li>Fazendo as contas: Se todos os 50 mil blocos tiverem 4MB, ent\u00e3o, o tamanho m\u00e1ximo que um block blob consegue chegar \u00e9 4MB x 50.000 = ~ 195GB<\/li>\r\n<\/ul>\r\n<\/li>\r\n<li>Por padr\u00e3o, o comando de BACKUP DATABASE escreve 1MB por bloco<br \/>\r\n<ul>\r\n<li>Por isso voc\u00ea recebe o erro acima. Com os valores padr\u00f5es, seu backup com 1 block blob (um TO URL), pode crescer at\u00e9 mais ou menos 48GB (1MB * 50.000 = ~ 48GB)<\/li>\r\n<li>Voc\u00ea pode mudar isso usando a op\u00e7\u00e3o MAXTRANSFERSIZE que controla o tamanho do bloco (<a href=\"https:\/\/docs.microsoft.com\/en-us\/sql\/t-sql\/statements\/backup-transact-sql?view=sql-server-ver15\">segundo a doc<\/a>, tem que ser m\u00faltiplos de 64KB, e um valor m\u00e1ximo de 4194304, isto \u00e9, 4MB)<\/li>\r\n<\/ul>\r\n<\/li>\r\n<\/ul>\r\n<p>Para ilustrar melhor:<\/p>\r\n<figure id=\"attachment_1615\" aria-describedby=\"caption-attachment-1615\" style=\"width: 1254px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5ef00cbb15aac.png\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-1615 size-full\" src=\"https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5ef00cbb15aac.png\" alt=\"Ilustra\u00e7\u00e3o de BACKUP DATABASE e Blobk Blobs\" width=\"1254\" height=\"712\" srcset=\"https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5ef00cbb15aac.png 1254w, https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5ef00cbb15aac-300x170.png 300w, https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5ef00cbb15aac-1024x581.png 1024w, https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5ef00cbb15aac-768x436.png 768w\" sizes=\"auto, (max-width: 1254px) 100vw, 1254px\" \/><\/a><figcaption id=\"caption-attachment-1615\" class=\"wp-caption-text\">Ao usar o comando BACKUP DATABASE, cada &#8220;TO URL&#8221; especificado faz com que seja criado um novo &#8220;Block Blob&#8221;. Cada block blob e constitu\u00eddo de v\u00e1rios blocos (at\u00e9 50 mil blocos), onde cada bloco tem um tamanho m\u00e1ximo de dados que podem ser inseridos nele. A op\u00e7\u00e3o MAXTRANSFERSIZE do comando de backup, controla o m\u00e1ximo que o SQL vai tentar inserir num bloco. Esse tamanho tamb\u00e9m \u00e9 limitado pela API do Azure. No caso do SQL Server, ele utiliza uma vers\u00e3o que permite at\u00e9 4MB! Ou seja, o MAXTRANSFERSIZE deve ser &lt;= 4MB (e em m\u00faltiplis de 64k). Por padr\u00e3o, MAXTRANSFERSIZE \u00e9 1MB!<\/figcaption><\/figure>\r\n<p>&nbsp;<\/p>\r\n<p>Por padr\u00e3o, um backup de um banco com cerca de 6MB, vai ficar assim em um Azure Block Blob:<\/p>\r\n<figure id=\"attachment_1610\" aria-describedby=\"caption-attachment-1610\" style=\"width: 714px\" class=\"wp-caption aligncenter\"><a href=\"https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5ef006467356c.png\"><img loading=\"lazy\" decoding=\"async\" class=\"wp-image-1610 size-full\" src=\"https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5ef006467356c.png\" alt=\"1 Blobk Blob com 6 blocos de 1MB\" width=\"714\" height=\"122\" srcset=\"https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5ef006467356c.png 714w, https:\/\/thesqltimes.com\/blog\/wp-content\/uploads\/2020\/06\/img_5ef006467356c-300x51.png 300w\" sizes=\"auto, (max-width: 714px) 100vw, 714px\" \/><\/a><figcaption id=\"caption-attachment-1610\" class=\"wp-caption-text\">Com as op\u00e7\u00f5es padr\u00f5es, um backup com total de 6MB se pareceria com isso l\u00e1 Azure Block Blob<\/figcaption><\/figure>\r\n<p>Em suma, o erro que o SQL disparou \u00e9 muito claro: Voc\u00ea atingiu o limite desses blocos em alguns dos Blocks Blobs usados! E para resolver isso, voc\u00ea tem algumas op\u00e7\u00f5es:<\/p>\r\n<ul>\r\n<li>ajustar o MAXTRANSFERSIZE para o m\u00e1ximo poss\u00edvel, permitindo que voc\u00ea use o m\u00e1ximo de espa\u00e7o poss\u00edvel em um Block Blob. No caso do SQL Server, o m\u00e1ximo \u00e9 4194304 (4MB). Com 50 mil blocos de limite em cada block blob, o m\u00e1ximo que o SQL Server consegue escrever em um \u00fanico Block Blob do Azure s\u00e3o cerca de 195GB ( 4MB x 50 MIL)&#8230; E \u00e9 por isso que, se voc\u00ea precisa mais do que isso, \u00e9 necess\u00e1rio adicionar mais block blobs, adicionando mais TO URL.<br \/><br \/><\/li>\r\n<li>adicionando mais TO URL<br \/>Se voc\u00ea chegou no limite de um \u00fanico block blob, ent\u00e3o o que resta \u00e9 aumentar a quantidade de block blobs. Voc\u00ea faz isso dividindo o seu backup em mais arquivos. O SQL suporta esse <em>stripping <\/em>do arquivo de backup desde\u00a0 a cl\u00e1usula &#8220;TO DISK&#8221; e &#8220;TO TAPE&#8221;, e com o TO URL n\u00e3o \u00e9 diferente. Ent\u00e3o, n\u00e3o \u00e9 uma novidade isso. Fazendo o SQL usar mais de um \u00fanico block blob, \u00e9 uma maneira de contornar esse limite do Azure<strong>.<\/strong> Por exemplo, um backup cujo tamanho total \u00e9 de 400GB (independente de ser comprimido ou n\u00e3o) n\u00e3o cabe um um \u00fanico Block Blob, e por isso voc\u00ea tem que especificar dois TO URL (e por seguran\u00e7a, tr\u00eas), se estiver usando um MAXTRANSFERSIZE de 4MB. O m\u00e1ximo que voc\u00ea consegue especificar no comando BACKUP DATABASE s\u00e3o 64 &#8220;TO URL&#8221;! Ou seja, considerando o m\u00e1ximo de 4MB por bloco, o seu backup pode chegar at\u00e9: 4MB * 50 mil blocos * 64 block blobs = ~12TB (at\u00e9 o SQL Server 2019 CU4, \u00e9poca em que este post foi escrito, ele ainda usava a API que permite at\u00e9 4MB)<\/li>\r\n<\/ul>\r\n<h2><strong>Na teoria \u00e9 lindo&#8230;<\/strong><\/h2>\r\n<p>Pois \u00e9&#8230; Num caso recente, eu e o <a href=\"https:\/\/www.linkedin.com\/in\/diegobernardesprado\/\">Diego<\/a> nos deparamos com esta mensagem, e mesmo fazendo todos as contas e todos os ajustes, continuamos recebendo esta mensagem. O Banco tinha 1TB de tamanho, desses 1TB, apenas 448GB usados. A edi\u00e7\u00e3o dele n\u00e3o permitia o uso de compress\u00e3o (era um 2019 Web Edition). Ent\u00e3o esse era o tamanho do backup necess\u00e1rio: 448GB! Fazendo a conta:<\/p>\r\n<ul>\r\n<li>1 block blob = 195GB (com blocos de 4MB)<\/li>\r\n<li>2 blocks blobs = 195*2 = 390GB&#8230; Ainda n\u00e3o cabe os 440GB<\/li>\r\n<li>Ent\u00e3o, com 3 = 585GB! Opa, na teoria, tr\u00eas arquivos s\u00e3o suficientes e ainda sobraria!<\/li>\r\n<\/ul>\r\n<p>E ent\u00e3o fiz o backup to URL com tr\u00eas:<\/p>\r\n<pre class=\"lang:tsql decode:true \" title=\"Exemplo de BACKUP TO URL p\/ 448GB\">BACKUP DATABASE Banco448GB TO\r\n\t URL  = 'https:\/\/STORAGEACCOUNT.blob.core.windows.net\/CONTAINER\/Banco448GB.part1.bak'\r\n\t,URL  = 'https:\/\/STORAGEACCOUNT.blob.core.windows.net\/CONTAINER\/Banco448GB.part2.bak'\r\n\t,URL  = 'https:\/\/STORAGEACCOUNT.blob.core.windows.net\/CONTAINER\/Banco448GB.part3.bak'\r\nWITH MAXTRANSFERSIZE = 4194304<\/pre>\r\n<p>E mesmo usando os tr\u00eas arquivos, voltei a receber o mesmo erro do in\u00edcio deste post! Ent\u00e3o, fomos aumentando. Tentamos com 20 arquivos e nada. Com 30&#8230; Sempre que aument\u00e1vamos o n\u00famero de arquivos, o backup demorava mais pra falhar, mas falhava pela mesma raz\u00e3o: atingiu o limite de blocos em dos block blobs. Ent\u00e3o, o Diego sugeriu tentamos com o m\u00e1ximo de 64 block blobs. E finalmente deu certo. Cada blob ficou 7GB! Fazenda a conta: 7*64 = 448GB!<\/p>\r\n<p>Eu achei muito estranho, pois em outro cliente, um backup com um total de 500GB foi feito normalmente com apenas 8 blobs! Ent\u00e3o, diante desses fatos eu resolvi investigar mais a fundo&#8230; E n\u00e3o encontrei nada que explicasse isso&#8230; Depois de algumas investiga\u00e7\u00f5es, cheguei a resposta&#8230; E eu vou contar ao longo dessa s\u00e9rie, pois tem muitas coisas legais que aprendi nesse caminho e ser\u00e3o bem \u00fateis para voc\u00ea entender mais o Backup pro Azure e o como o comando de BACKUP funciona!<\/p>\r\n<p>At\u00e9 a pr\u00f3xima!<\/p>","protected":false},"excerpt":{"rendered":"<div class=\"seriesmeta\">This entry is part 1 of 1 in the series <a href=\"https:\/\/thesqltimes.com\/blog\/series\/backup-to-url-e-o-tamanho-do-backup\/\" class=\"series-348\" title=\"Backup To URL e o Tamanho do Backup\">Backup To URL e o Tamanho do Backup<\/a><\/div><p>Neste post vou iniciar mais uma s\u00e9rie que nasceu de mais dia de trabalho na Power Tuning (na verdade, uns dois ou tr\u00eas). Cada vez mais empresas cedendo \u00e0s maravilhas da Cloud, especialmente do Azure. No caso do SQL Server, ele tem uma integra\u00e7\u00e3o fant\u00e1stica e nativa: Voc\u00ea pode fazer o backup do seu banco&hellip;&nbsp;<a href=\"https:\/\/thesqltimes.com\/blog\/2020\/06\/21\/backup-to-url-tamanho-backup-1\/\" rel=\"bookmark\"><span class=\"screen-reader-text\">BACKUP TO URL e o Tamanho do Backup &#8211; [1] Teoria&#8230;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":1615,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"om_disable_all_campaigns":false,"_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"neve_meta_sidebar":"","neve_meta_container":"","neve_meta_enable_content_width":"","neve_meta_content_width":0,"neve_meta_title_alignment":"","neve_meta_author_avatar":"","neve_post_elements_order":"","neve_meta_disable_header":"","neve_meta_disable_footer":"","neve_meta_disable_title":"","footnotes":""},"categories":[8,277,278,3,7],"tags":[280,174,353,350,352,351,73,349],"series":[348],"class_list":["post-1612","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administracao","category-azure","category-azure-storage","category-banco-de-dados-2","category-sql-server","tag-azure","tag-backup","tag-backup-database","tag-blobk-blob","tag-limite","tag-maxtransfersize","tag-sql-server","tag-url","series-backup-to-url-e-o-tamanho-do-backup"],"_links":{"self":[{"href":"https:\/\/thesqltimes.com\/blog\/wp-json\/wp\/v2\/posts\/1612","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/thesqltimes.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/thesqltimes.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/thesqltimes.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/thesqltimes.com\/blog\/wp-json\/wp\/v2\/comments?post=1612"}],"version-history":[{"count":5,"href":"https:\/\/thesqltimes.com\/blog\/wp-json\/wp\/v2\/posts\/1612\/revisions"}],"predecessor-version":[{"id":1620,"href":"https:\/\/thesqltimes.com\/blog\/wp-json\/wp\/v2\/posts\/1612\/revisions\/1620"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/thesqltimes.com\/blog\/wp-json\/wp\/v2\/media\/1615"}],"wp:attachment":[{"href":"https:\/\/thesqltimes.com\/blog\/wp-json\/wp\/v2\/media?parent=1612"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/thesqltimes.com\/blog\/wp-json\/wp\/v2\/categories?post=1612"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/thesqltimes.com\/blog\/wp-json\/wp\/v2\/tags?post=1612"},{"taxonomy":"series","embeddable":true,"href":"https:\/\/thesqltimes.com\/blog\/wp-json\/wp\/v2\/series?post=1612"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}