No post de hoje, trazemos algumas dicas e insights sobre boas práticas para desenvolvimento em banco de dados Sybase ASE. O assunto é técnino, porém divertido ele também será, Jovem Padawan.

“Um pouco mais de conhecimento ilumina nosso caminho” – Mestre Yoda.

Sumário

1 O que é Sybase?
2 No Sybase ASE, índices precisam existir
3 Você deve usar os Datatypes corretos
4
5 Funções são boas, mas devem ser evitadas em cláusulas WHERE e JOIN
6 Stored Procedures devem substituir consultas muito executadas
7 Fique atento à performance das suas queries no Sybase
8 Adie o início das transações e antecipe o seu fim
9 Como é trabalhar com o Sybase ASE?
10 Perspectivas para o futuro do Sybase

O que é Sybase?

First things first! Ou, em tradução livre, vamos começar do começo. Por mais redundante que essa afirmação seja, precisamos começar definindo o conceito-chave deste artigo.

Geralmente quando nos referimos à Sybase, na maioria das vezes estamos falando da obra e não do autor, assim como o Banco de Dados Oracle tornou a Oracle mundialmente reconhecida. O produto Sybase Adaptive Server Enterprise, ou Sybase ASE, ou simplesmente Sybase, foi um sistema de gerenciamento de banco de dados (SGBD) relacional da empresa Sybase Inc, adquirida em 2010 pela SAP Company. Com a compra, a tecnologia do Sybase ASE foi incorporada aos produtos SAP, e no decorrer do tempo acabou se tornando o SAP Adaptive Server Enterprise (SAP ASE), abandonando o nome Sybase.

Comercialmente super bem-sucedido, por ter adaptabilidade a diversos tipos de aplicações, o Sybase ASE teve uma forte presença nos mais diversos mercados globais. Aliado a isso, se tornou um SGBD famoso entre os DBAs (administradores de bancos de dados) e ficou conhecido por sua robustez e qualidade técnica, marcando sua importância na indústria de TI. Após sua considerável contribuição histórica, com o avanço da tecnologia em diversos segmentos e aspectos, como por exemplo a computação em nuvem, atualmente o Sybase ASE é considerado um sistema legado, inclusive com versões chegando ao fim de seu suporte pela SAP Company.

Diante desse cenário, não é de hoje que a migração do Sybase ASE é pauta nas reuniões estratégicas de quem o utiliza, porém por não ser um processo simples, rápido e de baixo custo, este SGBD ainda será utilizado por um bom tempo. Portanto, preparamos a seguir algumas dicas, com discussões interessantes, na utilização do Sybase ASE, além de um panorama geral envolvendo o seu futuro.

No Sybase ASE, índices precisam existir

Índices estão diretamente relacionados ao bom desempenho de um banco de dados. Eles são utilizados pelo otimizador para reduzir o tempo das consultas e são atualizados automaticamente a cada inserção, atualização ou exclusão de um registro na tabela.

Portanto, a criação de um índice deve ser avaliada com cuidado. Por exemplo, se uma tabela tem muitos registros (ordem de milhões) onde praticamente só temos consultas à tabela (nesse caso, as inserções são raras e não necessariamente precisam ser rápidas), a criação de um índice pode melhorar consideravelmente a performance da consulta.

Mas em contrapartida, se a coluna que possui o índice é atualizada constantemente em uma operação que deve ser rápida, a performance da inserção será pior do que se não houvesse índice, pois seus índices vão ficando fragmentados, o que pode prejudicar a performance, em alguns casos tornando pior em relação se não houvesse o índice. Portanto, nesse segundo caso, se a consulta não é realizada frequentemente e não existem requisitos fortes de performance, a criação do índice seria desnecessária. O query plan de uma consulta é uma ferramenta de análise muito importante nesse caso, mas falaremos mais sobre isso daqui a pouco no tópico sobre melhoria de performance de queries.

Você deve usar os Datatypes corretos

Eventualmente, acontece de passarmos desapercebidos pelos tipos de variáveis nas consultas que fazemos.

Por exemplo, se a coluna no banco de dados é do tipo NUMERIC (10, 0) e quando montamos a consulta, usamos uma variável do tipo INT na cláusula WHERE. Aparentemente, os Datatypes são equivalentes, mas o que acontece é que o otimizador não consegue usar índices nesse caso, e sua consulta vai perder em performance.

Em um dos casos em que atuamos, conseguimos reduzir o tempo médio da consulta em mais de 20 vezes, de 4 minutos para menos de 12 segundos, simplesmente corrigindo o tipo da variável da aplicação na consulta.

Os 3 minutos e 48 segundos restantes podem ser acumulados a cada execução, e serem bem utilizados para assistir um episódio do nosso podcast Entre Chaves, por exemplo.

Funções são boas, mas devem ser evitadas em cláusulas WHERE e JOIN

As funções escalares nos ajudam no tratamento de dados, sejam elas parte da biblioteca do próprio SGBD, ou criadas por quem o utiliza, são chamadas de escalares por retornarem um único valor como resultado, dado um conjunto de parâmetros de entrada. Na biblioteca interna do Sybase ASE podemos citar como exemplo as funções AVG, DATEDIFF, SUM, MAX, que respectivamente retornam a média dos valores, o intervalo entre duas datas, a soma total dos valores, e o valor máximo.

Porém, quando aplicamos as funções escalares a uma coluna com índice, estamos impedindo que o índice dessa coluna seja utilizado na cláusula WHERE, ou em um JOIN. O desempenho da sua consulta será então comprometido, como mencionamos no caso anterior.

Stored Procedures devem substituir consultas muito executadas

Consultas que são executadas com frequência, que possuem código extenso, ou que são realizadas em comum por várias aplicações ou plataformas, podem ser substituídas por Stored Procedures (SP).

Com essa mudança, o tempo de compilação dos comandos SQL é reduzido e o tráfego de rede também. Além de garantir segurança por eliminar acesso direto de aplicações a tabelas do banco. Diante disso, a substituição de consultas recorrentes por SPs poderá trazer ganhos para o banco ou para a aplicação e, por isso, é um tópico relevante ao trabalhar com Sybase ASE

Fique atento à performance das suas queries no Sybase

Quando falamos de query, é necessário pensar também em performance, afinal ninguém gosta de uma tela de loading, né? Algumas vezes esses contratempos são originados por queries demoradas, ou um conjunto delas que comprometem o funcionamento eficiente do banco de dados.

No Sybase ASE temos maneiras de avaliar o desempenho de uma query através do seu plano de execução e da análise de estatísticas. Essas ferramentas nos apresentam informações de grande relevância para a eficiência da query, como a sequência das execuções até a recuperação do dado, custos físicos e lógicos de leitura e gravação, a utilização de index, entre outros.

O plano de execução pode ser obtido com o uso do comando SET SHOWPLAN ON antes de executar a query em questão. Com isso podemos avaliar por exemplo, a utilização do index pelo otimizador do próprio Sybase ASE, e se está ocorrendo o “full table scan” (tabela sendo percorrida em sua totalidade, uma operação mais custosa).

As estatísticas da query são acessíveis pelo comando SET STATISTICS IO ON, e nos trazem informações sobre os custos físicos e lógicos para execução da query. O valor de I/O (Input/Output) pode ser uma boa referência para o desempenho, este quando muito elevado, demonstra talvez uma necessidade de refatoração da query ou ainda o seu particionamento a fim de dividir o custo em queries mais performáticas.

Adie o início das transações e antecipe o seu fim

Transações custam caro para o Sybase ASE, já que ele deve manter um controle rígido do seu estado interno. Se você abre uma transação e realiza diversas consultas de preparação para sua atualização, para só depois realizar sua operação de gravação, ele mantém um estado interno que pode ser desnecessário durante essas consultas, ocasionando locks, blocks ou até mesmo deadlocks.

Quando uma transação acessa uma parte dos dados, temos a possibilidade de que outro processo concorrente também precise desses dados ao mesmo tempo, com isso, o SGBD garante que nenhum processo secundário utilize essas informações, caracterizando assim o lock, garantindo a integridade dos dados durante as transações. Acessos simultâneos são possíveis e podem ocorrer com certa frequência, portanto o SGDB tenta manter uma organização colocando um processo em espera, o bloqueando (block), enquanto o outro conclui e libera o lock. Algumas vezes essa organização falha e acabam surgindo os denominados deadlocks, caracterizados quando os dois processos de lock e block criam uma dependência cruzada entre eles, que nunca será resolvida, dependendo de intervenção externa para resolver o impasse.

Como é trabalhar com o Sybase ASE?

Observamos várias críticas de profissionais que trabalham com o Sybase ASE, às vezes mencionando ser um SGBD antigo, legado para as soluções e necessidades tecnológicas atuais, ou até mesmo de baixo desempenho. Porém, também observamos em diversos casos, que o produto acaba sendo injustiçado por problemas de modelagem, queries não performáticas, até mesmo desconhecimento técnico do produto, o que comprometem sua utilização de maneira eficiente.

Em comparação com seus concorrentes diretos, estes podem apresentar mais vantagens e até mais funcionalidades que o Sybase ASE, mas não podemos deixar de mencionar que existem as necessidades particulares de cada contexto.

Perspectivas para o futuro do Sybase

Quando acompanhamos os planos da SAP Company para com os produtos Sybase não teremos melhorias significativas em vista, como o lançamento de um produto sucessor, as novidades ficam mais para as manutenções básicas dos recursos já existentes, como correções de erros e atualizações de segurança, principalmente com o encerramento do suporte para versões anteriores ao Sybase 16, versão mais atual.

Com o avanço das soluções em nuvem, as aplicações on-premisses (servidores locais), como é o caso do Sybase ASE, estão perdendo espaço. A migração para nuvem representa uma redução de investimento em TI e de custos indiretos, como custos de manutenção e atualizações no futuro, principalmente a escalabilidade, facilitando o desafio do controle da demanda sazonal.

Diante desse cenário, a principal rota de migração do Sybase tem sido para os Cloud Databases, evoluindo assim para a infraestrutura como serviço (IaaS). Dentre vários produtos podemos listar os bancos de dados da Amazon Web Service (AWS), Microsoft Azure, Google Cloud Platform e da Oracle. Porém, alguns clientes ainda preferem ou precisam adiar um pouco esse passo, optando pelo Microsoft SQL Server ou o SGBD da Oracle na versão on-premisse. Vale registrar que a SAP Company não oferece atualmente nenhuma ferramenta de migração do Sybase, ficando sob responsabilidade do seu cliente.

“Por aqui o treinamento devo terminar”.

E para além do conteúdo técnico, recomendamos o estudo prático sobre o Sybase ASE, juntamente das necessidades do negócio, além de um estudo quanto as possibilidades de migração, buscando entender melhor as diferenças entre os outros SGBDs. Analise os mais relevantes para sua trajetória e os que mais estão em alta no mercado, afinal de contas, a demanda é que vai ditar onde haverá oportunidades!

Se para todas suas perguntas, as respostas aqui você não encontrou, Jovem Padawan. Lembre-se, continuar estudando você deve. E de “sempre repassar o que você aprendeu”.

“Que a força esteja com você.”

Tem interesse em fazer parte de um time que entende de metodologia ágil na prática e transformação digital? Conheça nossa página de carreiras e se inscreva para a vaga que mais tem a ver com o seu perfil!

Por: William Nunes, Walace Martins e o Lucas Abdo

Sybase banco de dados: 6 boas práticas para armazenamento de informações

One-stop shop em tecnologia

Confira outros artigos