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?