Teremos auditores externos vindo para realizar uma revisão em nosso banco de dados Oracle. Eles estarão executando uma ferramenta para realizar a revisão e, para isso, exigem um ID de usuário que possa se conectar ao banco de dados e obter informações dele.

Temos um usuário existente no banco de dados para isso. No entanto, é um ID de produção e não podemos permitir que ele seja bloqueado. Gostaríamos de clonar / duplicar este ID, incluindo suas funções e direitos.

Existe uma maneira de fazer isso no Oracle?

Estamos executando um servidor MySQL RDS m1.xlarge e tendo alguns problemas com alto uso da CPU. Tivemos alguns problemas há algumas semanas com a utilização da CPU atingindo 100% em uma instância grande. Quando atualizamos o tamanho para xlarge, isso estabilizou as coisas por um tempo, mas o uso da CPU aumentou gradualmente novamente.

Na última semana, a utilização da CPU esteve na casa dos 90, atingindo 100% ou mais ou menos consistentemente ontem, o que paralisou nosso local de produção. Após a reinicialização do servidor db, em poucas horas o uso da CPU voltou aos mesmos níveis.

Eu executei show processlist no servidor mysql e monitorei o mesmo através do MySQL admin. Não parece haver consultas particularmente longas ou um grande volume de consultas. Há alguns processos em estado de suspensão por um longo tempo... esses são daemons de trabalhadores isolados executados fora do nosso aplicativo principal que se comunicam com o banco de dados. Copiei a saída da lista de processos abaixo com os nomes dos servidores alterados para fornecer uma descrição do que são:

+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+
| 13 | rdsadmin | localhost:43513 | mysql | Sleep | 14 | | NULL |
| 15 | proddbuser | app-server-1.eu-west-1.compute.internal:36460 | proddb | Sleep | 46 | | NULL |
| 451 | proddbuser | app-server-1.eu-west-1.compute.internal:55512 | proddb | Sleep | 29 | | NULL |
| 912 | proddbuser | app-server-1.eu-west-1.compute.internal:45171 | proddb | Sleep | 13 | | NULL |
| 941 | proddbuser | app-server-1.eu-west-1.compute.internal:47353 | proddb | Sleep | 53 | | NULL |
| 951 | proddbuser | app-server-1.eu-west-1.compute.internal:48014 | proddb | Sleep | 37 | | NULL |
| 1009 | proddbuser | app-server-1.eu-west-1.compute.internal:51787 | proddb | Sleep | 36 | | NULL |
| 1041 | proddbuser | app-server-1.eu-west-1.compute.internal:53777 | proddb | Sleep | 14 | | NULL |
| 1572 | proddbuser | app-server-1.eu-west-1.compute.internal:42989 | proddb | Sleep | 3 | | NULL |
| 1592 | proddbuser | app-server-1.eu-west-1.compute.internal:43279 | proddb | Sleep | 162 | | NULL |
| 2909 | proddbuser | app-server-1.eu-west-1.compute.internal:37768 | proddb | Sleep | 35 | | NULL |
| 3028 | proddbuser | app-server-1.eu-west-1.compute.internal:42568 | proddb | Sleep | 5 | | NULL |
| 3119 | proddbuser | app-server-1.eu-west-1.compute.internal:46913 | proddb | Sleep | 76 | | NULL |
| 3189 | proddbuser | app-server-1.eu-west-1.compute.internal:51466 | proddb | Sleep | 5 | | NULL |
| 3216 | proddbuser | app-server-2.eu-west-1.compute.internal:44097 | proddb | Sleep | 14552 | | NULL |
| 3218 | proddbuser | app-server-2.eu-west-1.compute.internal:44099 | proddb | Sleep | 14552 | | NULL |
| 3219 | proddbuser | app-server-2.eu-west-1.compute.internal:44107 | proddb | Sleep | 44 | | NULL |
| 3220 | proddbuser | app-server-2.eu-west-1.compute.internal:44113 | proddb | Sleep | 26 | | NULL |
| 3223 | proddbuser | app-server-2.eu-west-1.compute.internal:44184 | proddb | Sleep | 50 | | NULL |
| 3224 | proddbuser | app-server-2.eu-west-1.compute.internal:44187 | proddb | Sleep | 1 | | NULL |
| 3226 | proddbuser | app-server-2.eu-west-1.compute.internal:44208 | proddb | Sleep | 33 | | NULL |
| 3229 | proddbuser | app-server-2.eu-west-1.compute.internal:44250 | proddb | Sleep | 14 | | NULL |
| 3232 | proddbuser | app-server-2.eu-west-1.compute.internal:44279 | proddb | Sleep | 26 | | NULL |
| 3233 | proddbuser | app-server-2.eu-west-1.compute.internal:44297 | proddb | Sleep | 31 | | NULL |
| 3237 | proddbuser | app-server-2.eu-west-1.compute.internal:44334 | proddb | Sleep | 27 | | NULL |
| 3239 | proddbuser | app-server-2.eu-west-1.compute.internal:44338 | proddb | Sleep | 11 | | NULL |
| 3241 | proddbuser | app-server-2.eu-west-1.compute.internal:44356 | proddb | Sleep | 26 | | NULL |
| 3260 | proddbuser | app-server-2.eu-west-1.compute.internal:44619 | proddb | Sleep | 8 | | NULL |
| 3337 | proddbuser | utility-server-1.eu-west-1.compute.internal:45193 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 309416 LIMIT 1 |
| 3419 | proddbuser | utility-server-1.eu-west-1.compute.internal:46136 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 284530 LIMIT 1 |
| 3463 | proddbuser | app-server-1.eu-west-1.compute.internal:59619 | proddb | Sleep | 9406 | | NULL |
| 3504 | proddbuser | utility-server-1.eu-west-1.compute.internal:47063 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 260571 LIMIT 1 |
| 3577 | proddbuser | app-server-1.eu-west-1.compute.internal:34394 | proddb | Sleep | 6734 | | NULL |
| 3585 | proddbuser | utility-server-1.eu-west-1.compute.internal:47990 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 231273 LIMIT 1 |
| 3664 | proddbuser | utility-server-1.eu-west-1.compute.internal:48909 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 201525 LIMIT 1 |
| 3716 | proddbuser | app-server-2.eu-west-1.compute.internal:56301 | proddb | Sleep | 27 | | NULL |
| 3748 | proddbuser | utility-server-1.eu-west-1.compute.internal:49850 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 167839 LIMIT 1 |
| 3771 | proddbuser | my-pc:30101 | NULL | Query | 0 | NULL | show processlist |
| 3831 | proddbuser | utility-server-1.eu-west-1.compute.internal:50785 | proddb | Query | 0 | Sending data | SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`foreign_key` = 123228 LIMIT 1 |
+------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+

Devo também dizer que o tráfego no site é extremamente baixo durante este período, em relação ao horário normal de pico, cerca de 10% da carga que vemos nos horários de pico.

Também temos um novo monitoramento de relíquias que nos mostra quais são as chamadas de banco de dados de aplicativos mais demoradas. Isso nos mostra que uma chamada específica que representa 99% do tempo que nosso aplicativo gasta no banco de dados é uma consulta simples de localização por id como esta:

SELECT `mytable`.* FROM `mytable` WHERE `mytable`.`id` = 123 LIMIT 1

(não é exatamente o mesmo que as consultas que estavam sendo executadas na lista de processos acima)

Essa operação ficou mais lenta na última semana, com o desvio padrão entre as solicitações de tempo aumentando e também a quantidade máxima de tempo que leva sendo medida em termos de segundos. Eu acho que isso é apenas um resultado dos problemas de utilização da CPU e não uma causa.

Esta tabela tem cerca de 80.000 linhas, portanto, não é enorme. Espera-se que a maior parte do tempo dos aplicativos no banco de dados seja gasto procurando registros nesta tabela, a principal funcionalidade do aplicativo é baseada nisso. Eu mesmo executei uma consulta semelhante do meu servidor de aplicativos para o banco de dados de produção algumas vezes, enquanto o uso da CPU permanece em torno de 100% e responde em 1 ou 2 ms.

Com base em todos os itens acima, não temos certeza de como proceder com nossa depuração. Gostaria de saber se alguém tem alguma idéia de que tipo de coisas podem ser a causa raiz e como investigá-las? O acesso ao servidor subjacente que executa nosso servidor db é limitado, pois é uma instância do Amazon RDS.

Parece haver uma infinidade de informações sobre o processo de configuração de tarefas de backup, mas não há muitas informações sobre a visão geral dos backups de banco de dados. Pelo menos, é difícil formular uma consulta de mecanismo de pesquisa que forneça essas informações. Eu sei que existem três tipos diferentes de backups:

• Backups completos do banco de dados
• Backups Diferenciais de Banco de Dados
• Backups de log de transações

Parece que devo usar todos os três. Então, este é um cronograma que faz sentido?

• 1º de cada mês -- Faça umbackup completo do banco de dados.
• Todos os dias à meia -noite -- Faça umbackup diferencial do banco de dados.
• A cada 15 minutos -- Faça umbackup do log de transações .

Dessa forma, se meu banco de dados falhar, digamos, no dia 12, eu apenas restauraria o backup completo do banco de dados do dia 1, faria os 12 backups diferenciais do dia 1 ao 12 e, finalmente, restauraria o log de transações mais recente (são o diferencial dos logs de transação?).

Finalmente, um backup de banco de dados completo é independente? ou seja, depois de fazer um backup completo do banco de dados em 1º de fevereiro, posso excluir todos os arquivos de janeiro? Claro, eu manteria alguns sets dos meses anteriores por precaução, mas a questão é conceitual.

Definição de problema

Nossos usuários precisam da capacidade de consultar um banco de dados que esteja atualizado. Os dados podem ficar obsoletos por até 24 horas e isso é aceitável. Qual seria a abordagem de menor custo para obter e manter um segundo banco de dados atualizado com uma cópia de produção? Existe uma abordagem que eu não estou pensando?

carga de trabalho

Temos um aplicativo de terceiros que usamos para monitorar a atividade de negociação de ações. Durante o dia, muitas pequenas mudanças ocorrem como parte de vários fluxos de trabalho (sim, essa troca era válida. Não, isso é suspeito etc.). À noite, realizamos grandes operações baseadas em conjuntos (carregamos as negociações do dia anterior).

A solução e o problema atuais

Fazemos uso de instantâneos de banco de dados . Às 22h, descartamos e recriamos o instantâneo. O processamento ETL então começa. Obviamente, isso está sobrecarregando nosso disco, mas permite que nossos usuários consultem o banco de dados sem bloqueá-lo (eles usam um front-end do Access). Eles o usam até tarde da noite e no início da manhã, para que percebam o tempo de inatividade.

O problema com essa abordagem é duplo. A primeira é que, caso o processamento noturno falhe, e isso não é muito incomum, podemos restaurar o banco de dados, o que resulta na queda do instantâneo. O outro problema é que nossos tempos de processamento estão ultrapassando nosso SLA. Estamos tentando resolver isso trabalhando com o fornecedor depois de identificar consultas mal escritas e falta de indexação. O instantâneo do banco de dados também é um culpado nessa desaceleração, conforme evidenciado pela diferença de velocidade quando está presente versus não --- chocante, eu sei.

Abordagens consideradas

Agrupamento

Tínhamos o agrupamento de banco de dados ativado, mas isso não atendia às necessidades de disponibilizar os dados e apenas complicava a vida do administrador. Desde então, foi desligado.

Replicação do SQL Server

Começamos a olhar para a replicação na semana passada. Nossa teoria é que podemos obter um segundo catálogo levantado e sincronizado com o banco de dados de produção. Antes do início do ETL, cortaremos a conexão e a reabilitaremos apenas quando o processo ETL for concluído.

O administrador começou com a replicação de instantâneo , mas está preocupado com o fato de levar vários dias de alto uso da CPU para gerar o instantâneo, bem como o consumo de disco necessário. Ele indica que parece gravar todos os dados em arquivos físicos antes de enviá-los ao assinante, portanto, nosso banco de dados de 0,6 TB custará 1,8 TB em custos de armazenamento. Além disso, se demorar vários dias para gerar um snap, ele não caberá no SLA desejado.

Depois de ler o excelente artigo, parece que o Snapshot pode ser a maneira de inicializar os assinantes, mas gostaríamos de mudar para a replicação transacional para mantê-la sincronizada depois disso. Presumo que ativar/desativar a replicação transacional não forçará uma reinicialização completa? Caso contrário, vamos explodir nossa janela de tempo

Espelhamento de banco de dados

Nosso banco de dados está em modo de recuperação TOTAL, portanto, o espelhamento de banco de dados é uma opção, mas sei ainda menos sobre isso do que a replicação. Encontrei a resposta SO que indicava "O espelhamento de banco de dados impede que os dados sejam acessados ​​diretamente, os dados espelhados só são acessíveis por meio de um instantâneo do banco de dados".

Log de envio

Parece que o envio de logs também pode ser uma opção, mas essa é outra daquelas coisas sobre as quais não sei nada. Seria uma solução de menor custo (implementação e manutenção) do que qualquer outra? Com base no comentário de Remus "O envio de log permite acesso somente leitura à cópia da réplica, mas desconectará todos os usuários ao aplicar o próximo log de backup recebido (por exemplo, a cada 15 a 30 minutos)." Não tenho certeza de quanto tempo esse tempo de inatividade se traduziria, de modo que isso poderia causar alguma angústia aos usuários.

MS Sync

Só ouvi falar sobre o uso do Sync no fim de semana passado e ainda não o investiguei. Eu odiaria introduzir uma nova tecnologia para algo com grande visibilidade como este problema, mas se for a melhor abordagem, que assim seja.

SSIS

Fazemos bastante SSIS aqui, portanto, gerar algumas centenas de pacotes SSIS para manter o secundário sincronizado é uma opção para nós, embora feia . Não sou fã de fazer isso, pois é uma grande sobrecarga de manutenção que prefiro que minha equipe não assuma.

Instantâneo "mágico" da SAN

No passado, ouvi falar de nossos administradores usando alguma tecnologia SAN para fazer backups instantâneos de discos inteiros. Talvez haja alguma mágica da EMC que possa ser usada para fazer cópias ultrarrápidas do mdf/ldf e possamos então desanexar/anexar o banco de dados de destino.

Backup e restauração

Acho que fazemos backups completos uma vez por semana, diferenciais todas as noites e tlogs a cada 15 minutos. Se os usuários pudessem conviver com a interrupção de 3 a 4 horas para a restauração completa, suponho que essa seja uma abordagem.

Restrições

Windows 2008 R2, SQL Server 2008 R2 (Enterprise Edition), VMWare v5 Enterprise Edition, armazenamento EMC SAN com unidades mapeadas para arquivos vmdk, backups de gerenciamento de commvault e 0,6 TB de dados no catálogo de origem. Este é um aplicativo de terceiros que hospedamos internamente. Modificar sua estrutura geralmente é desaprovado. Os usuários não podem ficar sem consultar o banco de dados e se recusam a ser constrangidos pela identificação proativa das tabelas que monitoram para realizar seu trabalho.

Nossos DBAs são puramente contratados no momento. Os titulares zarparam e ainda não os substituímos. Os administradores do aplicativo não são versados ​​em assuntos do SQL Server e temos uma equipe de administradores de armazenamento/VM que podem ajudar/dificultar esse esforço. As equipes de desenvolvimento não estão envolvidas no momento, mas podem ser alistadas com base na abordagem. Portanto, seria preferível uma solução mais simples de implementar e manter.

Eu, estou no lado de desenvolvimento da casa, então só posso propor abordagens e não tive que lidar com o lado administrativo das coisas. Portanto, sem tempo na sela do administrador, hesito em dizer que uma abordagem seria superior a outra --- tudo parece ótimo de acordo com os documentos. Estou totalmente disposto a seguir qualquer direção que vocês sugerirem porque, a meu ver, isso só vai me tornar mais valioso como profissional de DB. Eu tenho um carrinho de mão, mas nenhuma capa do holocausto disponível .

Perguntas relacionadas

• https://stackoverflow.com/questions/525637/what-are-the-scenarios-for-using-mirroring-log-shipping-replication-and-cluste

• https://stackoverflow.com/questions/434982/mirroring-vs-replication

• https://stackoverflow.com/questions/4303020/sync-databases-mirroring-replication-log-shipping

• https://stackoverflow.com/questions/4303020/sync-databases-mirroring-replication-log-shipping

• http://nilebride.wordpress.com/2011/07/24/log-shipping-vs-mirroring-vs-replication/

Editar% s

Para responder às perguntas de @onpnt

Aceitação de latência de dados

Atualmente, os usuários visualizam dados com até 24 horas de atraso. Os dados são atuais apenas a partir de 2200

Quantidade de alteração de dados em um determinado minuto, hora e dia Não tenho certeza de como quantificar isso. Horário comercial, talvez centenas de mudanças por hora. Processamento noturno, milhões de linhas por dia útil

Conectividade com o secundário

Rede interna, host virtual separado e armazenamento dedicado

Leia os requisitos na instância secundária

O grupo do Windows terá acesso de leitura ao secundário, todas as tabelas

Tempo de atividade da instância secundária

Não há uma definição forte de um requisito de tempo de atividade. Os usuários querem que esteja sempre disponível, mas estão dispostos a pagar por isso, provavelmente não tanto. Realisticamente, eu diria que 23 horas por dia seriam suficientes.

Alterações no esquema existente e em todos os objetos

Modificações pouco frequentes, talvez uma vez por trimestre para objetos de tabela. Talvez uma vez por mês para objetos de código.

Segurança

Sem necessidades especiais de segurança. As permissões de produção corresponderiam às permissões da cópia. Embora, pensando bem, possamos revogar o acesso de leitura dos usuários ao prod e permitir que eles leiam apenas a cópia ... Embora não seja um requisito.

@darin strait

Reverter para o instantâneo pode ser uma opção, mas acho que houve algum motivo para eles não terem feito isso. vou verificar com o administrador

@cfradenburg

Minha suposição era que usaríamos apenas uma dessas abordagens, mas é um bom ponto que as restaurações quebrariam as "outras" tecnologias de sincronização. Eles estão investigando o que fazer usando a mágica do snapshot da EMC. Como o administrador descreveu, eles tirariam um instantâneo às 19h e migrariam a imagem para a zona secundária. Isso deve ser concluído em 2200 e, em seguida, eles realizarão uma desanexação e reanexação do banco de dados secundário.

Embrulhar

29/10/2012 Avaliamos a mágica do snapshot da EMC e algumas outras opções de replicação, mas os DBAs decidiram que poderiam descobrir melhor o espelhamento. Votei positivamente nas respostas porque todas elas ajudaram e me deram muitas opções, bem como "lição de casa" para investigar.

Eu tenho algumas ALTER TABLEdeclarações que estou executando. Nem todos eles funcionam (eles são o resultado da execução do SQL Data Compare) e eu quero agrupá-los em algumas transações e reverter as instruções se algo der errado.

Isso é possível ou são apenas dados que podem ser revertidos?

Ao se conectar a um SQL Server 2008 R2 a partir de um aplicativo cliente .NET 4 em um servidor diferente na mesma LAN, é possível definir três protocolos de rede diferentes:

1. TCP
2. Pipes nomeados
3. Não defina nada na string de conexão e use o padrão

Qual é a melhor prática? O que escolher?

Informações adicionais: TCP e pipes nomeados são ativados no servidor e no cliente. O aplicativo está usando espelhamento de banco de dados. Cliente e servidor se comunicam em uma LAN rápida.

Estamos investigando isso porque temos problemas raros e espúrios de conectividade e tempo limite. (Mas, independentemente disso, gostaria de saber a melhor prática).

Existe um artigo sobre este assunto no MSDN , mas é muito genérico e vago. Não aconselha ou recomenda nada de útil.

Alguém pode resumir as diferenças entre:

http://www.postgresql.org/docs/9.1/static/xfunc-sql.html

e

http://www.postgresql.org/docs/9.1/static/plpgsql.html

?

Pontos principais:

• diferenças conceituais
• dada uma família problemática, conveniência de uso
• questões políticas

É de conhecimento comum que você deve ter

SET NOCOUNT ON   

por padrão ao criar novos procedimentos armazenados.

A Microsoft alterou o modelo padrão para incluir isso em 2012. Achei que deveria ser o mesmo para gatilhos, mas não está incluído no modelo.

Isso é intencional ou apenas um descuido?

É suficiente ter todo o índice na memória/ram ou o mongodb tenta alocar o máximo de RAM possível para armazenar até os dados para leituras rápidas?

Eu gostaria de executar o mongodb + outros aplicativos e parece que o mongodb é o único que não me permite definir um intervalo de RAM, digamos "max_memory_allocated_or_reserved=8GB".

Se não houver como fazer isso, devo explicar ao oom-killer que mongod é o processo "ruim" que não é a melhor prática na minha opinião ...

As três SELECTinstruções neste código

USE [tempdb];
GO

SET NOCOUNT ON;

CREATE TABLE dbo.persist_test (
      id            INT NOT NULL
    , id5           AS (id * 5)
    , id5p          AS (id * 5) PERSISTED
);

INSERT INTO dbo.persist_test (id)
VALUES (1), (2), (3);

SELECT id
FROM dbo.persist_test;

SELECT id5
FROM dbo.persist_test;

SELECT id5p
FROM dbo.persist_test;

DROP TABLE dbo.persist_test;

gerar este plano:

Por que o final SELECT, que está selecionando um valor persistente, gera um operador Compute Scalar ?