Temos um sistema ERP um pouco menos moderno, o back-end está atualmente em uma instalação do SQL Server 2008 R2. Temos por mandato de gerenciamento (não é sempre o caso) a prática completamente impraticável de permitir que muitos usuários extraiam dados deste sistema à vontade para fins de manipulação dos dados em seu tipo preferido de relatório (BI, Powerquery, Access , Excel, etc.)
Embora todos esses usuários geradores de relatórios tenham apenas direitos selecionados, existem vários outros aplicativos que têm a capacidade de realmente manipular dados para fins de fazer coisas como EDI, entrada automatizada de dados.
Logicamente, isso cria uma série de condições de corrida nas mesas. Primeiro a chegar, primeiro a servir, ou pior ainda, ainda servindo, por favor, aguarde, ou apenas NÃO... Acredito que isso está causando ainda mais anos de corrupção de dados inexplicável que requer assistência do fornecedor para corrigir. Porque nem todos os aplicativos são codificados adequadamente para antecipar a chance de que algo mais possa ter interrompido sua própria intenção privada.
Portanto, a tarefa é provar/corrigir/mitigar sempre que possível em um sistema que herdei recentemente.
Meu primeiro instinto me diz que isso não pode ser feito, sem algum tipo de controle de IPC/erro/transação entre produtos de diferentes fornecedores e sua vontade de corrigi-lo, controle sobre o código-fonte ou capacidade de restringi-lo, que isso NÃO PODE ser corrigido de um DBA perspectiva, são simplesmente más práticas que levam ao que deveria ser antecipado como efeitos colaterais potencialmente indesejados.
Portanto, tudo o que posso fazer neste momento é provar isso e ver que, com provas, posso solicitar algum tipo de mudança de comportamento no coração da administração que insiste que deve ser assim.
A primeira etapa é que estou executando uma saída contínua do criador de perfil no disco, embora com uso intensivo de recursos. Tenho que ser capaz de voltar e ver o que foi enviado, por quem e qual o impacto que teve. Também estou usando o log perfmon e o PAL para tentar fazer referência cruzada ao comportamento intensivo no servidor, "quando o processador e a memória estão atrelados, o que o servidor SQL estava fazendo naquela instância (provavelmente atendendo a uma das GUI escritas, com baixo desempenho, dez consultas de união de tabelas, não indexadas, que algum redator/ferramenta de relatório juntou"
Uma dessas situações acabou de ocorrer, tínhamos um usuário no sistema ERP que não conseguia realizar uma função, identificamos o usuário logado no banco de dados que não estava utilizando o software ERP (Estava utilizando ODBC, usuário SQL com acesso somente select, e MS Access), desconectou-os e a função foi concluída. A gerência se recusa a acreditar que eles estão relacionados porque "deveriam estar lidando com tabelas diferentes e o usuário só tinha acesso selecionado" e não tenho histórico de perfil do instante imediatamente anterior ao ocorrido.
Portanto, tudo isso se resume a uma pergunta para os colegas DBA, dada a tarefa de PROVAR que o aplicativo A está sendo afetado negativamente pelo aplicativo B, que sugestões você teria a oferecer?
Infelizmente, também lidamos com muitos problemas com isso onde trabalho. Nos casos em que isso tem sido um problema, pessoas que não conhecem bancos de dados, abrem literalmente uma tabela SQL "ao vivo" no MS Access. A princípio, as coisas podem parecer transitórias porque podem abrir e fechar o Access rapidamente. Mas há aqueles momentos em que eles deixam o MS Access aberto na mesa SQL ao vivo enquanto saem para almoçar ou talvez durante o fim de semana prolongado - bloqueando aplicativos que tentam usar o banco de dados. Só para dizer o óbvio: o bloqueio pode afetar adversamente qualquer aplicativo que tente usar a linha, tabela ou banco de dados SQL bloqueado.
Tudo o que realmente precisávamos fazer para provar qualquer coisa era capturar dados
sp_who2
para encontrar as cadeias de bloqueio.Dito isto, quando estou longe do console, ainda uso o seguinte código que escrevi há mais de uma década (quero dizer, ainda estou usando o DBCC InputBuffer) para encontrar esses problemas irritantes - se necessário (execute em um teste/desenvolvimento para ver se ele atende às suas necessidades). Embora certamente não seja o Rolls Royce das rotinas, ainda funciona para mim.
Esse código basicamente cria uma tabela, BlockingProcesses, em um novo banco de dados DBADMIN para armazenar as informações de bloqueio. Dois procedimentos armazenados
sp__Maint_BlockWatch
esp__Maint_Blockingprocesses
trabalham juntos para encontrar os bloqueadores. E um trabalho SQL é executado uma vez por minuto para verificar se há blocos. Você pode precisar alterar pequenas coisas no código abaixo, como o usuário que precisa executar o trabalho, possível agendamento, etc.Eu tenho a mesma vulnerabilidade ambiental, embora em menor escala: muitos usuários se conectam com seu front-end preferido, como MS Access via ODBC, bloqueando inadvertidamente tabelas SQL e exibições, mesmo quando o usuário tem SELECT ONLY.
Felizmente, evitar muitos bloqueios parece viável seguindo uma ordem para que esses usuários também instalem o SQL Server 2012 SSMS. O pacote de instalação incluía "SQL Server Native Client 11.0". As conexões ODBC que usam esse driver têm uma nova opção de "intenção do aplicativo". Escolha 'READONLY' em vez do padrão 'READWRITE'. Voo doo?