NinjaTrader 8 lento ou com as velas congeladas: porque acontece, quanto te custa e como resolvê-lo
Se o teu NinjaTrader 8 ficou lento, as velas deixam de atualizar em pleno mercado ou a plataforma fecha sozinha, o mais provável é que o problema não esteja na tua ligação nem no teu computador: está na base de dados interna do NinjaTrader. E não é um incömodo técnico — é um risco financeiro mensurável.
Neste guia explicamos, com documentação oficial e estudos revistos por pares, porque acontece, quanto te custa de verdade, o que podes fazer tu mesmo e como evitar que volte a acontecer.
O que é a base de dados do NinjaTrader e porque se degrada
O NinjaTrader 8 guarda as tuas ordens, execuções, posições e histórico de preços numa base de dados SQLite local (pasta Documentos\NinjaTrader 8\db). O SQLite é fiável em milhares de milhões de implementações, mas a sua própria documentação enumera as condições exatas que o corrompem[1] — e várias são habituais num ambiente de trading intensivo.
Porque é que o NinjaTrader 8 é especialmente vulnerável
| Condição (SQLite oficial) | Presente no trading real |
|---|---|
| Bloqueio de ficheiro defeituoso / acesso concorrente | Várias instâncias ou contas partilham os mesmos ficheiros ao mesmo tempo |
Falha de fsync (o disco “mente” sobre a escrita) | Alto volume de ordens: milhares de escritas por sessão |
| Encerramento ou crash a meio de uma transação | Quedas de feed, reconexões, fechos forçados |
| Cópia de segurança durante uma transação ativa | Ferramentas que copiam a pasta com o NinjaTrader aberto |
fsync() funcione corretamente — exatamente o perfil de um copiador multiconta que emite milhares de ordens por dia.Sintomas: como saber se é a tua base de dados
- As velas ficam paradas mesmo que o preço no DOM se mova.
- Abrir um gráfico ou mudar de instrumento demora muito mais do que antes.
- O NinjaTrader consome cada vez mais memória e vai “aos solavancos”.
- Fechos inesperados, sobretudo ao arrancar ou ao carregar dados.
A cadeia causal: do ficheiro à perda
O dano segue uma sequência mecânica e reproduzível:
| # | Elo | O que acontece |
|---|---|---|
| 1 | BD corrompida ou enorme | Erros de dados (IDs duplicados) ou ficheiro danificado; leituras lentas |
| 2 | A plataforma recarrega a BD na thread do ecrã | Ao reconectar o feed, o gráfico tenta recarregar as execuções a partir da BD |
| 3 | Bloqueio | A thread do ecrã bloqueia; as velas param, a operativa segue por outra thread |
| 4 | Execução danificada | Ordens tardias, duplicadas ou impossíveis; posição por gerir |
| 5 | Perda financeira | Slippage, posição presa, risco sem stop |
Não é um incómodo técnico: é risco financeiro mensurável
Um bloqueio é, no fundo, latência extrema. E a latência tem um custo quantificado pela literatura académica.
Se 500 ms já representam um custo substancial, um bloqueio de segundos ou minutos transforma esse custo numa perda de primeira ordem. E acontece precisamente quando o mercado está mais volátil — que é quando o feed cai e a BD fica sob stress.
Um estudo do Journal of Financial Economics (2022) sobre quedas de corretoras documenta ainda que, quando a tua plataforma te bloqueia, perdes o controlo do teu risco no pior momento; não é uma anedota, é um efeito medido à escala de mercado[3].
Como se traduz no teu P&L
| Dano | Efeito na tua conta |
|---|---|
| Slippage por bloqueio | Pior preço de entrada/saída em cada operação afetada |
| Posição presa | Perda pelo lado adverso enquanto não podes fechar |
| Ordens duplicadas / fantasma | Exposição indesejada, posição invertida |
| Dados históricos corrompidos | Backtests e estatísticas mal calculados → decisões erradas |
| Registos erróneos | Disputas com prop firms, erros fiscais/contábeis |
Soluções manuais (e porque não bastam)
- Reduzir o histórico que guardas (menos dias de dados à mão).
- Fazer cópia de segurança da tua pasta do NinjaTrader antes de tocar em algo.
- Compactar ou reconstruir a base de dados seguindo a documentação oficial[5].
O problema é que isto é manual, ocasional e arriscado: é preciso lembrar-se, escolher o momento (mercado fechado) e um passo mal dado pode deixar-te sem histórico. A maioria só reage quando algo já se partiu.
A forma de não voltar a acontecer: automatizar a manutenção
Em vez de apagar fogos, a solução sustentável é que a manutenção aconteça sozinha, em segundo plano e no momento certo. Para isso criámos o TSD DB Guardian, um programa externo ao NinjaTrader que trata da saúde da sua base de dados sem que tenhas de fazer nada:
- Deteta a corrupção e o crescimento excessivo de forma contínua.
- Faz cópia com um backup verificado antes de atuar.
- Repara quando é preciso e espera pelo mercado fechado para não incomodar a tua operativa.
- Deixa um relatório de auditoria assinado de cada intervenção.
Funciona de forma programável (semanal, a cada 15 ou a cada 30 dias) e traz um botão de pânico para lançar a manutenção de imediato. É software de Windows que convive com o NinjaTrader 8; não é um complemento que carregue dentro da plataforma.
Deixa de lutar com a base de dados do NinjaTrader
Experimenta o TSD DB Guardian 14 dias grátis, com todas as funções e sem cartão.
Ver TSD DB Guardian Testar grátis 14 dias
Perguntas frequentes
Vou perder o meu histórico de dados ao reparar a base?
Não, se for feito com uma cópia de segurança prévia. O DB Guardian faz sempre backup antes de atuar; se o fizeres manualmente, faz tu a cópia primeiro.
Tenho de parar de operar para fazer a manutenção?
Não. O DB Guardian espera pelo mercado fechado e trabalha em segundo plano. A manutenção manual, essa, convém fazê-la com a plataforma fechada.
Isto é um indicador do NinjaTrader?
Não. É um programa de Windows independente que convive com o NinjaTrader 8 e trata da sua base de dados a partir de fora.
Porque é que bloqueia justamente nos momentos de mais movimento?
Porque a volatilidade traz mais ordens, mais escritas e mais reconexões de feed — as condições exatas que stressam a base de dados SQLite e disparam a recarga na thread do ecrã.
Referências
- SQLite. How To Corrupt An SQLite Database File. sqlite.org/howtocorrupt.html
- Moallemi, C. C., & Saglam, M. (2013). The Cost of Latency in High-Frequency Trading. Operations Research, 61(5).
- Retail trader sophistication and stock market quality: Evidence from brokerage outages. Journal of Financial Economics (2022).
- NinjaTrader Support Forum. Issue with Order Flow Market Depth Map Freezing Platform — significant loss incurred.
- NinjaTrader Help Guide. Operations > Database Operations (Reset DB / Repair DB).