none
Como devo criar Scripts e Jobs e transformar uma trigger em um Job? RRS feed

  • Pergunta

  • Olá, boa tarde! Estou realmente com um problema, tenho alguns passo-a-passos para seguir, e como tenho recebido uma ajuda muito grande da comunidade, espero que consiga realizar essas atividades. 

    Atualmente, criei uma base de dados nova, porque, resumidamente, eu tenho um banco que contém informações e tabelas que estão sobrecarregados devido o uso de um portal(tenho um portal em C# que acessa as informações de status de algumas tabelas dessa base sobrecarregada e exibe essas informações), e a ideia é separar as informações que o portal usa  em uma base de dados somente para o portal. Porém, essas duas bases vão ter que trocar informações, como acessar status de tarefas (parado, funcionando ou em execução) dentro da base que está sobrecarregada. Tenho pouquíssima experiencia e vivência com a ferramenta sql server(2016) e os passos que tenho que executar são: 

    1. Fazer um Script para excluir todas as tabelas, views e triggers que são do meu portal e deixar a base que está sobrecarregada, somente com as informações que pertencem a ela.
    2. Fazer um Script para excluir todas as tabelas do Automate(ferramenta de RPA) e renomear a Base de Dados para a nova base que criei.
    3. Listar TODAS as tabelas do Automate(ferramenta de RPA) que o meu portal acessa diretamente.
    4. Criar Views dessas Tabelas do Automate.
    5. Alterar o Portal para que acesser as Tabelas e Views da nova base de dados criada.
    6. Transformar as Triggers em Jobs.

    Algumas dessas tarefas, principalmente a parte de triggers e scripts estão extremamente confusas na minha cabeça em como proceder. 

    sexta-feira, 6 de dezembro de 2019 15:32

Todas as Respostas

  • Ana, são tarefas extensas e que dependem mais do conhecimento do contexto do que de SQL Server. Por exemplo, o primeiro item cita "excluir todas as tabelas, views e triggers que são do meu portal"; essa informação não tem relação com SQL Server mas sim com o projeto do banco de dados. Em algum local existe a documentação de quais objetos (tabelas, procedimentos etc) do banco de dados que o portal utiliza e que sejam específicas do portal?


    José Diz     Belo Horizonte, MG - Brasil     [query performance tuning: Porto SQL]


    Este conteúdo é fornecido sem garantias de qualquer tipo, seja expressa ou implícita.

    • Editado José Diz sexta-feira, 6 de dezembro de 2019 17:04
    sexta-feira, 6 de dezembro de 2019 16:46
  • Oi José, o contexto que eu acho que você se refere é que, o meu portal "popula", atualiza e faz selects nas minhas tabelas dentro da base que está sendo "isolada", a ideia é fazer com que o meu portal utilize uma base só dele e o Automate(ferramenta de RPA) fique com a base sobrecarregada somente para ele. Ou seja, dentro da minha base sobrecarregada, eu tenho tabelas e procedures que não pertencem ao Automate e sim ao meu portal e preciso remover elas de lá com os registros e tudo mais que elas conterem e passa-las para a base que criei. Existem sim, por exemplo, todas as tabelas que pertencem ao portal estão nomeadas em letras maiúsculas e as do Automate, não. Não sei se deu para entender melhor, mas vou deixar uma imagem mostrando.

    Tudo o que está em letras minúsculas, pertencem ao Automate.

    • Editado Ana_Miguel sexta-feira, 6 de dezembro de 2019 17:15
    sexta-feira, 6 de dezembro de 2019 17:04
  • (...) eu tenho tabelas e procedures que não pertencem ao Automate e sim ao meu portal e preciso remover elas de lá (...)

    Se você sabe quais são as tabelas e procedimentos, então no script basta colocar os comandos que apagam esses objetos. Algo assim:

    -- código #1 -- apaga objetos de uso exclusivo do portal

    -- apaga procedimentos
    DROP PROCEDURE proc_1; ... DROP PROCEDURE proc_n;

    -- apaga funções
    DROP FUNCTION função_1;
    ...
    DROP FUNCTION função_n;

    -- apaga visões
    DROP VIEW visao_1;
    ...
    DROP VIEW visao_n;
    -- apaga tabelas
    DROP TABLE tabela_1; ... DROP TABLE tabela_n;

     

    Ao remover as tabelas também serão removidos os gatilhos, as restrições e índices associados à tabela. É preciso ficar atento à ordem em que as tabelas são apagadas, devendo iniciar por aquelas que não possuam colunas que sejam chaves estrangeiras em outras tabelas.

    Para saber alguns dos objetos associados a uma tabela você pode utilizar a visão sys.dm_sql_referencing_entities.


    José Diz     Belo Horizonte, MG - Brasil     [query performance tuning: Porto SQL]


    Este conteúdo é fornecido sem garantias de qualquer tipo, seja expressa ou implícita.

    • Editado José Diz sexta-feira, 6 de dezembro de 2019 17:31
    • Sugerido como Resposta IgorFKModerator sexta-feira, 6 de dezembro de 2019 18:22
    sexta-feira, 6 de dezembro de 2019 17:23
  • Vou tentar então utilizar os comando acima, começando por excluir as tabelas.
    sexta-feira, 6 de dezembro de 2019 17:33
  • Vou tentar então utilizar os comando acima, começando por excluir as tabelas.

    Ana, o código #1 é um esboço. Pelo que vi em sua lista de tarefas, o item 1 somente pode ser executado após ter criado banco de dados novo, estabelecida a comunicação entre eles ("essas duas bases vão ter que trocar informações") e ter reconfigurado o software do portal para que utilize o novo banco de dados; antes disso me parece que deixaria o portal inoperante. E tabelas são os últimos objetos a excluir, para não deixar alguns objetos inconsistentes.

    Quando citei contexto, me referia a todo o projeto em que está envolvida. Quando você comenta que "tenho um banco que contém informações e tabelas que estão sobrecarregados devido o uso de um portal", foi realizada análise das causas da sobrecarga? No lugar de desmembrar o banco de dados em dois outra possibilidade seria corrigi-las de alguma outra forma (otimizar programas, alocar novos recursos ao computador etc). Além disso, ao dividir o banco de dados em dois mas mantê-los na mesma instância, e com os mesmos recursos computacionais, talvez não resolva a questão de sobrecarga se a causa for recursos computacionais insuficientes (pouca memória física, discos lentos, processador sobrecarregado etc).

    Aqui no fórum é possível auxiliar em pontos específicos mas, considerando-se o porte das alterações em andamento, e como você cita que possui pouca experiência no SQL Server, talvez seja o caso de contratar alguma consultoria local específica para rever esse projeto. Você está em Portugal?


    José Diz     Belo Horizonte, MG - Brasil     [query performance tuning: Porto SQL]


    Este conteúdo é fornecido sem garantias de qualquer tipo, seja expressa ou implícita.

    • Editado José Diz sábado, 7 de dezembro de 2019 13:36
    sábado, 7 de dezembro de 2019 00:24
  • 6. Transformar as Triggers em Jobs.

    Presumo que se refira aos gatilhos de manutenção das informações do portal, pois não faria sentido alterar gatilhos específicos do Automate. É necessário saber o que cada gatilho realiza para saber que ação realizar. Se, por exemplo, há um gatilho em tabela do Automate que cria ou altera informações em tabela do portal, basta alterar o destino, informando o nome do novo banco de dados. Como as bases estão na mesma instância, é um processo simples.

    Se você puder esclarecer este item, facilita postar sugestões.


    José Diz     Belo Horizonte, MG - Brasil     [query performance tuning: Porto SQL]


    Este conteúdo é fornecido sem garantias de qualquer tipo, seja expressa ou implícita.

    sábado, 7 de dezembro de 2019 13:33