{"id":8457,"date":"2026-05-27T14:24:13","date_gmt":"2026-05-27T17:24:13","guid":{"rendered":"https:\/\/powertuning.com.br\/blog\/?p=8457"},"modified":"2026-05-27T14:24:13","modified_gmt":"2026-05-27T17:24:13","slug":"protheus-lento-4-cases-reais-de-cliente-que-provam-o-caminho-mais-rapido-e-barato-e-o-banco-de-dados","status":"publish","type":"post","link":"https:\/\/powertuning.com.br\/blog\/protheus-lento-4-cases-reais-de-cliente-que-provam-o-caminho-mais-rapido-e-barato-e-o-banco-de-dados\/","title":{"rendered":"Protheus lento? 4 cases reais de cliente que provam: o caminho mais r\u00e1pido e barato \u00e9 o banco de dados"},"content":{"rendered":"

<\/p>\n

\n

<\/p>\n

\n
\n
\ud83c\udfa7 Resumo de Live<\/span><\/div>\n

Otimiza\u00e7\u00e3o de Banco de Dados Protheus (SQL Server)<\/h1>\n

Fabr\u00edcio Lima<\/a><\/span> \u00a0\u00b7\u00a0 Abril 2026<\/p>\n

Live original: <\/span>1h 30min<\/span> \u00a0\u00b7\u00a0 Leitura deste resumo: <\/span>10 min<\/span><\/div>\n<\/div>\n<\/div>\n

<\/p>\n

\n

Apresentador<\/p>\n

Fabr\u00edcio Lima<\/strong> \u00a0\u00b7\u00a0 LinkedIn \u2197<\/a> \u00a0\u00b7\u00a0 YouTube \u2197<\/a><\/p>\n<\/div>\n

<\/p>\n

\n

Sobre o que \u00e9<\/p>\n

Uma live t\u00e9cnica sobre como resolver lentid\u00e3o no ERP Protheus atuando diretamente no banco de dados SQL Server. Cobre a arquitetura de \u00edndices, an\u00e1lise de queries reais, compress\u00e3o de dados (com redu\u00e7\u00f5es de 60% a 80%) e rotinas essenciais para o DBA manter o ambiente saud\u00e1vel.<\/p>\n<\/div>\n

<\/p>\n

\n

\ud83d\udca1 Principais Insights<\/h2>\n
\n

Banco de dados \u00e9 o caminho mais r\u00e1pido e barato<\/h3>\n

Quando o Protheus fica lento, as empresas geralmente tentam comprar mais hardware ou reescrever c\u00f3digo AdvPL. Ambos s\u00e3o caros e demorados. A atua\u00e7\u00e3o no banco de dados \u2014 principalmente cria\u00e7\u00e3o e otimiza\u00e7\u00e3o de \u00edndices \u2014 resolve lentid\u00f5es pontuais de forma r\u00e1pida, barata e eficiente.<\/p>\n<\/div>\n

\n

SELECT * \u00e9 o inimigo n\u00famero 1<\/h3>\n

Quando se solicita todas as colunas de uma tabela gigante, o SQL Server \u00e9 for\u00e7ado a fazer Key Lookup para cada linha. Com milhares de linhas, o otimizador desiste do \u00edndice e faz Table Scan \u2014 lendo a tabela toda. A li\u00e7\u00e3o: solicite apenas as colunas estritamente necess\u00e1rias.<\/p>\n<\/div>\n

\n

Compress\u00e3o: de 242GB para 50GB<\/h3>\n

O Protheus preenche colunas vazias com espa\u00e7os em branco em vez de NULL, desperdi\u00e7ando espa\u00e7o massivamente. A compress\u00e3o nativa do SQL Server elimina esses vazios, reduzindo bancos entre 60% e 80%. O benef\u00edcio vai al\u00e9m do disco: mais dados cabem na RAM, e leitura em mem\u00f3ria \u00e9 ordens de grandeza mais r\u00e1pida que em disco.<\/p>\n<\/div>\n

\n

\u00cdndices no JOIN, n\u00e3o s\u00f3 no WHERE<\/h3>\n

Ao juntar tabelas gigantes do Protheus (como SC5 e SC6), n\u00e3o basta ter \u00edndices nos filtros do WHERE. \u00c9 crucial garantir \u00edndices nas colunas de jun\u00e7\u00e3o (cl\u00e1usula ON\/JOIN), como Filial e N\u00famero do Pedido.<\/p>\n<\/div>\n

\n

Updates\/Deletes em massa: sempre em lotes<\/h3>\n

Nunca execute comandos que afetem milh\u00f5es de linhas de uma vez. Isso trava a tabela, expande o LDF descontroladamente e, se cancelado, o rollback pode levar horas. A pr\u00e1tica correta: fazer em lotes menores (loops).<\/p>\n<\/div>\n

\n

Power Alerts + Tuning: a dupla que resolve<\/h3>\n

Sem monitoramento voc\u00ea est\u00e1 no escuro \u2014 esperando o usu\u00e1rio reclamar. O Power Alerts identifica queries lentas, locks, sess\u00f5es sleeping e acompanha rotinas cr\u00edticas como custo m\u00e9dio, saldo cont\u00e1bil e faturamento. Power Alerts + Tuning de queries \u00e9 a solu\u00e7\u00e3o mais r\u00e1pida e barata para lentid\u00e3o no Protheus \u2014 muito melhor que comprar mais infra.<\/p>\n<\/div>\n<\/div>\n

<\/p>\n

\n

\ud83d\udcac Frases que Marcaram<\/h2>\n
\u275d “SELECT * \u00e9 o inimigo n\u00famero um da performance.”<\/div>\n
\u275d “Compress\u00e3o no Protheus \u00e9 mandat\u00f3ria. N\u00e3o \u00e9 opcional.”<\/div>\n
\u275d “Atuar no banco de dados \u00e9 a forma mais r\u00e1pida, barata e eficiente de resolver lentid\u00e3o.”<\/div>\n<\/div>\n

<\/p>\n

\n

\ud83d\udcd6 Resumo Detalhado<\/h2>\n

O Problema da Lentid\u00e3o: 3 Caminhos<\/h3>\n

Quando o Protheus fica lento, as empresas tentam resolver de tr\u00eas formas diferentes. Cada uma com custo, prazo e efetividade muito distintos:<\/p>\n\n\n<\/p>\n
\n

Caminho 1<\/p>\n

\ud83d\udcca Hardware<\/p>\n

Mais CPU, mem\u00f3ria, SSD<\/p>\n

Custo<\/p>\n

Alto<\/p>\n

Prazo<\/p>\n

Semanas a meses<\/p>\n

\u26a0 Problema costuma voltar conforme o banco cresce<\/p>\n<\/td>\n

<\/p>\n

\n

Caminho 2<\/p>\n

\ud83d\udcdd AdvPL<\/p>\n

Reescrever c\u00f3digo do ERP<\/p>\n

Custo<\/p>\n

M\u00e9dio-alto<\/p>\n

Prazo<\/p>\n

Demorado<\/p>\n

\u26a0 Cria depend\u00eancia de terceiros<\/p>\n<\/td>\n

<\/p>\n

\u2605 FOCO DA LIVE<\/span><\/p>\n

Caminho 3<\/p>\n

\ud83d\udcbe Banco de Dados<\/p>\n

\u00cdndices, compress\u00e3o, queries<\/p>\n

Custo<\/p>\n

Baixo<\/p>\n

Prazo<\/p>\n

Minutos a horas<\/p>\n

\u2705 Resolve a causa, sem mexer no ERP<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

A terceira via \u00e9 o foco da live: atuar no banco de dados \u00e9 a forma mais r\u00e1pida, barata e eficiente de resolver lentid\u00f5es pontuais \u2014 principalmente atrav\u00e9s da cria\u00e7\u00e3o e otimiza\u00e7\u00e3o de \u00edndices.<\/p>\n

A Arquitetura e a M\u00e1gica dos \u00cdndices<\/h3>\n

O n\u00facleo da otimiza\u00e7\u00e3o reside no uso adequado de \u00edndices, divididos em duas categorias:<\/p>\n

\n

\u00cdndice Clustered (F\u00edsico)<\/p>\n

A pr\u00f3pria tabela organizada em formato de \u00e1rvore. No Protheus, \u00e9 sempre a coluna R_E_C_N_O_. S\u00f3 pode existir um por tabela \u2014 ele define a ordem f\u00edsica dos dados no disco.<\/p>\n<\/div>\n

\n

\u00cdndices Nonclustered (L\u00f3gicos)<\/p>\n

Estruturas de \u00e1rvore separadas para facilitar buscas por outras colunas (Nome, Data, Filial). O Protheus possui dezenas desses \u00edndices por tabela.<\/p>\n<\/div>\n

Tr\u00eas conceitos fundamentais de leitura:<\/p>\n

\n

\u26a0 Scan (pior cen\u00e1rio)<\/strong><\/p>\n

SQL l\u00ea a tabela inteira para encontrar um dado. Como ler um livro inteiro para achar uma palavra.<\/p>\n<\/div>\n

\n

\u2705 Seek (cen\u00e1rio ideal)<\/strong><\/p>\n

SQL vai direto ao ponto usando a \u00e1rvore do \u00edndice. M\u00e1xima performance.<\/p>\n<\/div>\n

\n

\u26a0 Key Lookup (intermedi\u00e1rio)<\/strong><\/p>\n

SQL encontra a linha pelo \u00edndice nonclustered, mas precisa “pular” para o clustered para buscar colunas adicionais n\u00e3o presentes no \u00edndice.<\/p>\n<\/div>\n

O Perigo do SELECT *<\/h3>\n

Quando se solicita todas as colunas de uma tabela gigante, o SQL Server faz Key Lookup para cada linha encontrada. Com milhares de linhas, o otimizador percebe que milhares de lookups \u00e9 excessivo e decide ignorar o \u00edndice \u2014 optando por um Table Scan, que l\u00ea a tabela toda e degrada severamente a performance. Li\u00e7\u00e3o fundamental: solicite apenas as colunas estritamente necess\u00e1rias.<\/strong><\/p>\n

\u00cdndices nos JOINs, N\u00e3o S\u00f3 no WHERE<\/h3>\n

Ao juntar tabelas gigantes do Protheus (como SC5 e SC6), n\u00e3o basta ter \u00edndices nos filtros do WHERE. \u00c9 crucial garantir \u00edndices nas colunas de jun\u00e7\u00e3o (cl\u00e1usula ON\/JOIN), como Filial e N\u00famero do Pedido. Sem esses \u00edndices, o SQL Server \u00e9 for\u00e7ado a fazer Scans em tabelas enormes.<\/p>\n

Ordem das Colunas no \u00cdndice Composto<\/h3>\n

A ordem importa muito. A regra geral: a coluna mais seletiva (que filtra mais dados, como C\u00f3digo do Produto) deve vir antes de colunas menos seletivas (como Filial, que tem muitos valores repetidos).<\/p>\n

Compress\u00e3o de Dados: O Segundo Trunfo<\/h3>\n

O Protheus preenche colunas vazias com espa\u00e7os em branco em vez de NULL \u2014 desperdi\u00e7ando espa\u00e7o massivamente. A compress\u00e3o nativa do SQL Server elimina esses vazios, com redu\u00e7\u00f5es reais entre 60% e 80%:<\/p>\n

\n

Casos reais de compress\u00e3o:<\/p>\n

\u25cf 242 GB \u2192 50 GB<\/strong> (redu\u00e7\u00e3o de 79%)<\/p>\n

\u25cf 565 GB \u2192 181 GB<\/strong> (redu\u00e7\u00e3o de 68%)<\/p>\n<\/div>\n

O benef\u00edcio vai al\u00e9m do disco: com o banco menor, muito mais dados cabem na RAM (Buffer Pool). Leitura em mem\u00f3ria \u00e9 ordens de grandeza mais r\u00e1pida que em disco \u2014 a performance geral d\u00e1 um salto gigantesco.<\/p>\n

Rotinas Essenciais para o DBA<\/h3>\n

Queries Sleeping:<\/strong> Consultas que o sistema “esqueceu” abertas e que ficam segurando Locks (travando tabelas). Devem ser monitoradas e encerradas para evitar travamentos em cadeia.<\/p>\n

Updates\/Deletes em massa:<\/strong> Nunca execute comandos que afetem milh\u00f5es de linhas de uma vez. Isso trava a tabela, expande o LDF descontroladamente e, se cancelado, o rollback pode levar horas. Fa\u00e7a sempre em lotes (loops).<\/p>\n

Collation:<\/strong> No contexto do Protheus, a collation Latin1_General_BIN \u00e9 significativamente mais r\u00e1pida que as op\u00e7\u00f5es padr\u00e3o, pois o SQL n\u00e3o precisa validar acentua\u00e7\u00e3o e diferen\u00e7as entre mai\u00fasculas\/min\u00fasculas nas compara\u00e7\u00f5es de strings.<\/p>\n

Monitoramento: Saia do Escuro com o Power Alerts<\/h3>\n

Tuning sem monitoramento \u00e9 tiro no escuro. Antes de otimizar qualquer coisa, voc\u00ea precisa enxergar<\/strong> o que est\u00e1 acontecendo no ambiente. O Power Alerts<\/strong> \u00e9 fundamental para ambientes Protheus porque entrega exatamente essa visibilidade:<\/p>\n

\n

\ud83d\udd0d Queries mais demoradas<\/strong><\/p>\n

Identifica automaticamente as consultas que mais consomem CPU, fazem mais leituras e as que mais se repetem. \u00c9 assim que voc\u00ea encontra as queries para otimizar.<\/p>\n<\/div>\n

\n

\ud83d\udd12 Locks e sess\u00f5es sleeping<\/strong><\/p>\n

Monitora travamentos em tempo real e identifica sess\u00f5es esquecidas abertas que est\u00e3o segurando locks desnecessariamente.<\/p>\n<\/div>\n

\n

\u2699 Rotinas cr\u00edticas do Protheus<\/strong><\/p>\n

Acompanha a performance de rotinas como custo m\u00e9dio, saldo cont\u00e1bil, faturamento e outras \u2014 alertando quando algo sai do padr\u00e3o.<\/p>\n<\/div>\n

\n

Power Alerts + Tuning de queries \u00e9 a solu\u00e7\u00e3o mais r\u00e1pida e barata para lentid\u00e3o em ambiente Protheus.<\/span> Muito melhor que comprar mais infraestrutura \u2014 e sem ficar no escuro esperando o usu\u00e1rio reclamar.<\/p>\n<\/div>\n<\/div>\n

<\/p>\n

\n

\ud83d\udcc8 Cases Reais: O Poder de um \u00cdndice<\/h2>\n

Pra ilustrar o impacto real dessas t\u00e9cnicas, separei 4 cases de clientes reais demonstrados na live. Em todos, a otimiza\u00e7\u00e3o levou minutos \u2014 o impacto, anos de tranquilidade pra equipe de TI.<\/p>\n


\n
\n<\/p>\n

\n

Case 1 \u00b7 CT2010 (48 milh\u00f5es de registros)<\/p>\n

O \u00edndice sugerido nem sempre \u00e9 o melhor<\/h3>\n

Query filtrava por CT2_CREDIT. O SQL Server sugeriu um \u00edndice gigante com muitas colunas no INCLUDE \u2014 seria caro de manter numa tabela desse tamanho. A solu\u00e7\u00e3o: um \u00edndice menor, apenas pela coluna seletiva CT2_CREDIT (420MB, criado em 5 minutos).<\/p>\n

<\/p>\n\n\n\n
\n

\u274c Antes<\/p>\n

5,7s<\/p>\n

91.143 leituras \u00b7 CPU 10.531ms<\/p>\n<\/td>\n

\n

\u2705 Depois<\/p>\n

0,07s<\/p>\n

4 leituras \u00b7 CPU 0ms<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

\ud83d\udca1 Li\u00e7\u00e3o:<\/strong> \u00edndice menor e mais seletivo pode ser melhor que o sugerido pelo SQL.<\/p>\n<\/div>\n


\n
\n<\/p>\n

\n

Case 2 \u00b7 SD2010 (86M de leituras no tempdb)<\/p>\n

6 subqueries id\u00eanticas + TempDB massivo<\/h3>\n

Query com 6 subqueries id\u00eanticas no CASE e no WHERE, todas buscando na SD2010 sem \u00edndice por D2_COD. O operador Spool gerava 86 milh\u00f5es de leituras no tempdb. A solu\u00e7\u00e3o: 1 \u00fanico \u00edndice estrat\u00e9gico cobrindo o padr\u00e3o das subqueries.<\/p>\n\n\n\n
\n

\u274c Antes<\/p>\n

4m 05s<\/p>\n

86M tempdb \u00b7 CPU 362s<\/p>\n<\/td>\n

\n

\u2705 Depois<\/p>\n

3s<\/p>\n

4.504 tempdb \u00b7 CPU 12,6s<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

\ud83d\udca1 Li\u00e7\u00e3o:<\/strong> um \u00edndice bem posicionado resolve m\u00faltiplas subqueries de uma vez.<\/p>\n<\/div>\n


\n
\n<\/p>\n

\n

Case 3 \u00b7 SC5 + SC6 + SC9 (Pedidos)<\/p>\n

481 milh\u00f5es de leituras + Locks travando o banco<\/h3>\n

Query com m\u00faltiplos JOINs entre Pedidos (SC5), Itens (SC6) e Composi\u00e7\u00e3o (SC9). Realizava 481 milh\u00f5es de leituras na SC9 e \u2014 o pior \u2014 causava Locks que travavam outros processos do banco inteiro. Solu\u00e7\u00e3o “sniper”: 3 \u00edndices estrat\u00e9gicos focados nas colunas de filtro e JOIN.<\/p>\n\n\n\n
\n

\u274c Antes<\/p>\n

2m 40s<\/p>\n

481M leituras \u00b7 CPU 1.183s<\/p>\n<\/td>\n

\n

\u2705 Depois<\/p>\n

4s<\/p>\n

Locks eliminados<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

\ud83d\udca1 Li\u00e7\u00e3o:<\/strong> \u00edndices nos JOINs s\u00e3o t\u00e3o importantes quanto nos filtros WHERE.<\/p>\n<\/div>\n


\n
\n<\/p>\n

\n

Case 4 \u00b7 SCT3W0 (15 minutos de execu\u00e7\u00e3o)<\/p>\n

SUBSTRING no WHERE mata o \u00edndice<\/h3>\n

O filtro usava SUBSTRING(CT_DATA, 1, 6) = ‘202101’. Quando voc\u00ea aplica uma fun\u00e7\u00e3o numa coluna do WHERE, o SQL n\u00e3o consegue usar \u00edndice \u2014 precisa aplicar a fun\u00e7\u00e3o em CADA linha. Resultado: Table Scan completo. Solu\u00e7\u00e3o: reescrever o filtro sem fun\u00e7\u00e3o (CT_DATA >= ‘20210101’ AND CT_DATA < ‘20210201’) + \u00edndice otimizado.<\/p>\n\n\n\n
\n

\u274c Antes<\/p>\n

15 min<\/p>\n

Table Scan completo<\/p>\n<\/td>\n

\n

\u2705 Depois<\/p>\n

segundos<\/p>\n

Seek eficiente no \u00edndice<\/p>\n<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

\ud83d\udca1 Li\u00e7\u00e3o:<\/strong> NUNCA use fun\u00e7\u00f5es em colunas do WHERE. Reescreva o filtro.<\/p>\n<\/div>\n

<\/p>\n

\n

\ud83d\udd17 Quer ver mais?<\/strong> Estes 4 s\u00e3o uma amostra. Veja o post completo com 10 cases reais de melhoria de performance no Protheus \u2192<\/a><\/p>\n<\/div>\n<\/div>\n

<\/p>\n

\n

\ud83c\udfaf Pra quem \u00e9 essa live?<\/h2>\n

DBAs que administram ambientes Protheus e precisam melhorar performance. Analistas de infraestrutura que recebem chamados de lentid\u00e3o do ERP. Desenvolvedores AdvPL que querem entender como o banco processa suas queries. E gestores de TI avaliando se devem investir em hardware ou em otimiza\u00e7\u00e3o.<\/p>\n<\/div>\n

<\/p>\n

\n

\u2705 Takeaways R\u00e1pidos<\/h2>\n
\u2713 Evite SELECT * \u2014 \u00e9 o inimigo #1 da performance
\n\u2713 Crie \u00edndices nos JOINs, n\u00e3o s\u00f3 nos filtros WHERE
\n\u2713 Coluna mais seletiva primeiro no \u00edndice composto
\n\u2713 Compress\u00e3o de dados no Protheus \u00e9 mandat\u00f3ria
\n\u2713 Monitore e encerre Queries Sleeping
\n\u2713 Deletes\/Updates em massa: sempre em lotes (loops)
\n\u2713 Use collation Latin1_General_BIN para Protheus
\n\u2713 Power Alerts + Tuning = solu\u00e7\u00e3o mais r\u00e1pida e barata<\/strong>
\n\u2713 Otimize o banco antes de comprar mais hardware<\/div>\n<\/div>\n

<\/p>\n

\u25b6\u00a0 Assistir \u00e0 Live Completa<\/a><\/div>\n

<\/p>\n

\n

Resumo por Power Tuning<\/strong> \u00a0\u00b7\u00a0 powertuning.com.br<\/a><\/p>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

\ud83c\udfa7 Resumo de Live Otimiza\u00e7\u00e3o de Banco de Dados Protheus (SQL Server) Fabr\u00edcio Lima \u00a0\u00b7\u00a0 Abril 2026 Live original: 1h 30min \u00a0\u00b7\u00a0 Leitura deste resumo: 10 min Apresentador Fabr\u00edcio Lima \u00a0\u00b7\u00a0 LinkedIn \u2197 \u00a0\u00b7\u00a0 YouTube \u2197 Sobre o que \u00e9 Uma live t\u00e9cnica sobre como resolver lentid\u00e3o no ERP Protheus atuando diretamente no banco de…
Leia mais<\/a><\/p>\n","protected":false},"author":6,"featured_media":8523,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"content-type":"","_exactmetrics_skip_tracking":false,"_exactmetrics_sitenote_active":false,"_exactmetrics_sitenote_note":"","_exactmetrics_sitenote_category":0,"_jetpack_newsletter_access":"","_jetpack_dont_email_post_to_subs":false,"_jetpack_newsletter_tier_id":0,"_jetpack_memberships_contains_paywalled_content":false,"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_post_was_ever_published":false},"categories":[176,62,59,138,63],"tags":[890,873,887,881,879,880,889,888,547,876,875,877,189,884,208,188,141,22,185,872,885,886,882,35,883,878,521,187,874],"class_list":["post-8457","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-banco-de-dados","category-casos-reais-de-clientes","category-tuning","category-power-alerts","category-sql-server","tag-advpl","tag-banco-de-dados-protheus","tag-cases-reais-protheus","tag-collation-latin1_general_bin","tag-compressao-sql-server","tag-data-compression","tag-dba-protheus","tag-erp-totvs","tag-fabricio-lima","tag-index-seek","tag-indices-sql-server","tag-key-lookup","tag-lentidao-protheus","tag-locks-sql-server","tag-otimizacao-protheus","tag-performance-protheus","tag-power-alerts","tag-power-tuning","tag-protheus","tag-protheus-tuning","tag-queries-sleeping","tag-r_e_c_n_o_","tag-select","tag-sql-server","tag-substring-where","tag-table-scan","tag-tempdb","tag-totvs-protheus","tag-tuning-sql-server"],"jetpack_featured_media_url":"https:\/\/powertuning.com.br\/blog\/wp-content\/uploads\/2026\/04\/Capa_Blog.png","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/powertuning.com.br\/blog\/wp-json\/wp\/v2\/posts\/8457","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/powertuning.com.br\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/powertuning.com.br\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/powertuning.com.br\/blog\/wp-json\/wp\/v2\/users\/6"}],"replies":[{"embeddable":true,"href":"https:\/\/powertuning.com.br\/blog\/wp-json\/wp\/v2\/comments?post=8457"}],"version-history":[{"count":3,"href":"https:\/\/powertuning.com.br\/blog\/wp-json\/wp\/v2\/posts\/8457\/revisions"}],"predecessor-version":[{"id":8524,"href":"https:\/\/powertuning.com.br\/blog\/wp-json\/wp\/v2\/posts\/8457\/revisions\/8524"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/powertuning.com.br\/blog\/wp-json\/wp\/v2\/media\/8523"}],"wp:attachment":[{"href":"https:\/\/powertuning.com.br\/blog\/wp-json\/wp\/v2\/media?parent=8457"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/powertuning.com.br\/blog\/wp-json\/wp\/v2\/categories?post=8457"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/powertuning.com.br\/blog\/wp-json\/wp\/v2\/tags?post=8457"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}