Arquivo de setembro, 2012

Pessoal é com grande prazer que anuncio dia 28/09 a partir das 20:00 o webcast Instalando e Configurando o SQL Server Failover Cluster que eu irei apresentar pelo user group SQL Server RS.

Se você quer aprender um pouco sobre o que de melhor em alta disponibilidade no SQL Server não percam.

Vejam a chamada em http://sqlserverrs.com.br/sqlserverrs/?p=299 e inscreva-se em https://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032529833&Culture=pt-BR&community=0

Conto com a presença de todos vocês.

Olá pessoal,

Esses dias meu amigo Leandro Ribeiro (blog | twitter) solicitou no Twitter dicas sobre o banco de dados do Protheus e como eu dou manutenção no banco de dados desse produto, percebi que eu sabia vários detalhes que poderiam ser úteis para quem está começando a trabalhar com o Protheus agora.

Para quem não conhece o Protheus é um dos maiores ERPs do mundo, ele é desenvolvido pela empresa brasileira Totvs onde há alguns anos é líder de mercado nacional. A grande vantagem do Protheus é que além dele ser bem completo ele customizável, ou seja, você compra a licença do sistema e pode contratar um desenvolvedor para customizá-lo a seu gosto, já imaginou isso ? Já pensou se você pudesse fazer isso com qualquer software que comprasse ou utilizasse ? Pois é, por aí dá para sentir o poder do produto e dá para começar a perceber o porque ele é tão usado no mercado nacional, mas é claro que nem tudo são flores e é obvio que esse produto tem seus pontos fracos, algumas particularidades e é exatamente para discutir isso que escrevi esse post.

Vamos as dicas:

  1. Quase sempre o banco de dados se chama DADOSADV ou pelo menos começa com DADOS. Não me pergunte o motivo, pois eu não sei;
  2. A aplicação não acessa o banco de dados diretamente ela usa uma camada intermediária chamada Top Connect. O Top Connect quase sempre é instalado no mesmo servidor que o banco de dados, porém há casos em que ele é instalado em uma máquina exclusiva e então a aplicação se conecta ao Top e o Top se conecta ao SQL Server;
  3. O Protheus é multiempresa, porém ao contrário do que estamos acostumado a ver nas modelagens onde a empresa é identificada com um campo dentro de cada tabela, o banco do Protheus cria uma tabela para cada empresa até a versão 10 do ERP, então se o teu cliente tiver mais de uma empresa aberta trabalhando no mesmo banco de dados, para cada empresa terá uma tabela de cliente, produto, nota fiscal e assim suscetivamente. Agora imaginem uma construtora do ramo imobiliário que para cada incorporação construída tem que ser aberto um CNPJ. Já pensou se ela tiver mais de 100 empreendimentos construídos ou em construção? O banco passará de 100 mil tabelas facilmente!
  4. A partir da versão 11 do Protheus já é possível criar as empresas dentro da mesma tabela o que diminui significativamente o número de tabelas dentro do banco de dados. Essa dica da versão 11 do Protheus foram dadas pelos amigos Bruno e Luiz Carlos nos comentários do post.
  5. O nome das tabelas não ultrapassam 6 caracteres e são representados da seguinte maneira: 3 primeiros caracteres é a família que aquela tabela pertence, os 2 próximos caracteres representa a empresa que aquela tabela pertence e o último caractere é reservado ao sistema, por exemplo a tabela de cliente da empresa 01 é a SA1010, da empresa 02 é a SA1020 onde SA1 é a família da tabela, 01 e 02 representa a empresa e o 0 no final é reservado. Como assim família ? Exemplo, cliente é SA1, fornecedor é SA2 e assim por diante. A Totvs considera que Cliente e Fornecedor pertencem à mesma família;
  6. O campo chave primária das tabelas é sempre o mesmo, ou seja, todas as tabelas tem um campo chamado R_E_C_N_O_ que é auto-incrementado pelo Top Connect e é a PK das tabelas;
  7. Os registros das tabelas nunca são deletados fisicamente. Todas as tabelas contém um campo chamado D_E_L_E_T_ e quando alguém excluí um registro no sistema, no banco de dados esse campo é preenchido com um *, então sempre que for fazer qualquer select lembrem-se de desprezar os registros deletados colocando na condição where D_E_L_E_T_ = ”, ou D_E_L_E_T_ <> ‘*’. Esse conceito de exclusão lógica foi herdado do DBF;
  8. Não existe campo DateTime nas tabelas. Todos os campo data são VARCHAR(8), nunca são nulos e são sempre preenchidos com 8 caracteres em branco para informar que estão vazios;
  9. Não existe campo NULL. Se o campo for numérico ele é preenchido com zero e se for String/Char é preenchido com espaços em branco. Em ambos os casos o preenchimento é feito via Constraint Default. Agora imaginem a quantidade de Constraint que cada tabela tem!;
  10. Muito cuidado ao criar índices nas tabelas, pois se você criar em uma terá que criar em todas, por exemplo: Se criar um índice na tabela de cliente SA1XX0 lembre-se de replicar esse índice para as demais tabelas de cliente caso tenha;
  11. O Protheus trabalha com um dicionário de dados próprio onde são definidas as tabelas, campos e índices então em uma atualização de versão é feita uma checagem do dicionário de dados com a estrutura do banco de dados e tudo que não estiver definido no dicionário será apagado, seja campo, índice ou tabela, portanto ao criar um índice utilizado em um trabalho de Tuning eu aconselho a criar uma rotina que diariamente verifica a existência desse índice e então caso não exista mais crie-o novamente. Eu costumo colocar tudo dentro do step de um job que diariamente consulta a sys.indexes pelo nome;
  12. Nunca crie um campo em uma tabela sem antes passar para o dicionário de dados do Protheus, pois ao abrir uma tela que use a tabela onde o campo foi criado, essa tela irá travar por não ter o campo no dicionário;
  13. O desempenho das consultas não são grande coisa, pois a maioria dos desenvolvedores Protheus não tem grandes habilidades e conhecimento sobre indexação, então é sempre bom dar uma checada nas consultas mais lentas e dar um help para a galera de desenvolvimento;
  14. Uma forma de ganhar espaço em disco com o banco do Protheus é usar a compressão de dados a nível de página caso o SQL Server seja Enterprise. Em testes realizados na tabela SB1(Produtos) com 28000 produtos, comprimindo apenas a tabela passou de 72 MB para 6 MB, ou seja, uma taxa de compressão de 91.66%;
  15. Os bancos geralmente são enormes então é válido pensar em uma estratégia de particionamento das tabelas;
  16. Índices não usados e duplicados não é excessão e sim regra, então é válido analisar isso e repassar para os desenvolvedores. Nunca apague um índice sem antes apagar no dicionário, pois as telas fazem essa verificação também em sua abertura e caso não encontre no banco elas travarão;
  17. O Top Connect não funciona em cluster devido ao hardlock que é quem licencia o Protheus e como em alguns casos ele é instalado no mesmo servidor do banco de dados, não será possível colocar ele no Service and Application do Cluster e quando ocorrer um Failover será necessário reiniciar o servidor de licença que fica geralmente em outro servidor, senão ele não voltará ao ar e a aplicação não abrirá;
  18. Não é possível fazer uma replicação merge das tabelas, devido fato da replicação merge adicionar um campo de controle de unicidade chamado rowguid e caso tenha um campo na tabela do banco e não tenha no dicionário do Protheus isso causa sérios impactos. Mesmo que não houvesse o impeditivo do campo rowguid, muitas tabelas ultrapassam 246 colunas e seria impossível replicar com merge devido o limite de 246 colunas por artigo;
  19. Devido o padrão das tabelas do Protheus não terem campos NULL e todos serem preenchidos com uma Constraint Default isso impede que as tabelas sejam colocadas In-Memory a.k.a Hekaton que é o novo recurso do SQL Server 2014. É possível desde que todas as Constraints Defaults sejam excluídas e os campos que são Not Null passem a ser Null, porém isso implicaria em uma grande mudança na modelagem do banco e os efeitos colaterais nesse tipo de mudança são incontáveis;
  20. Normalmente os bancos são muito grandes, então a rotina de manutenção de índices se torna uma tarefa difícil e quase impossível para a rotina do Maintenance Plan do SQL Server, portanto é válido usar rotina própria ou de terceiros como a rotina do Ola Hallengren.

Bom galera espero que essas dicas sejam úteis para todos. Conforme eu for me lembrando de mais coisas eu vou atualizando o post.

Até mais.