Estou ensinando a mim mesmo o MongoDB HA, passando por vários cenários de conjuntos de réplicas, configurando prioridades, árbitros, conjuntos de réplicas ocultos etc. Atualmente, estou usando vários mongods em um único servidor Windows, executando em portas separadas, obviamente.
Existem cenários específicos que eu não conseguiria simular com coisas como rs.stepDown()e rs.freeze()? Ou parando os serviços?
Sou um DBA do SQL Server por profissão, investigando o MongoDB para um projeto. Uma das convenções que usamos é armazenar informações de estilo de configuração em um banco de dados SQLDBA em cada servidor (limites de reconstrução de índice, exceções de backup etc.).
Eu estou querendo saber se esta mesma técnica seria útil aqui. Minha pergunta é:
Com certeza, temos um servidor/banco de dados SQL de hub central, mas também armazenamos alguns dados de configuração localmente em cada servidor para conduzir determinados processos. Não queremos que eles falhem porque um servidor não conseguiu entrar em contato com o hub.
Isso pode se enquadrar na categoria de opinião, mas estou curioso para saber se as pessoas estão usando o sinalizador de rastreamento 4199 como um parâmetro de inicialização para o SQL Server. Para aqueles que o usaram, em que circunstâncias você experimentou regressão de consulta?
Certamente parece um benefício de desempenho potencial em geral, estou pensando em habilitá-lo globalmente em nosso ambiente de não produção e deixá-lo descansar por alguns meses para descobrir quaisquer problemas.
As correções em 4199 são lançadas no otimizador por padrão em 2014 (ou 2016)? Embora eu entenda o caso de não introduzir alterações inesperadas no plano, parece estranho manter todas essas correções ocultas entre as versões.
Estamos usando 2008, 2008R2 e principalmente 2012.
Provavelmente uma pergunta rápida.
Estamos procurando testar alguns sinalizadores de rastreamento como parâmetros de inicialização em nosso ambiente e, embora eu saiba que podemos usar DBCC TRACESTATUSpara obter sinalizadores de rastreamento com escopo global, ele não especifica se isso foi definido na inicialização ou apenas definido com -1 bandeira. A análise do log de erros do SQL é o único método disponível? Possivelmente uma entrada de registro em algum lugar?
Qualquer maneira de resolver isso programaticamente seria útil.
Obrigado por ler!
No interesse de eliminar a ambiguidade entre quando estou me conectando à não-produção e à produção, utilizo vssettings para um tema específico no Management Studio (estilo fogo e enxofre quando em produção, calmante blues em não-produção).
Anteriormente, nosso acesso de não produção era por meio de uma conta, e nosso acesso de produção era por meio de uma conta mais restrita. Com esse método, consegui definir um tema para cada conta uma vez e tudo estava bem. Agora todo o acesso está usando a conta elevada.
Existe uma maneira de dizer ao SSMS no momento do lançamento para usar um tema específico? Ou uma maneira programática de fazer isso sem passar por "Ferramentas > Configurações de importação e exportação" todas as vezes? Estou usando a versão SQL 2014 do SSMS.
Obrigado.
Aqui está o meu problema. Estou tentando mover um banco de dados para um novo servidor por meio de uma restauração completa e, em seguida, substituir com um rápido backup/restauração diferencial. Posso fazer uma restauração completa sem problemas, mas ao restaurar o backup diferencial, recebo o seguinte aviso:
Msg 3127, Nível 16, Estado 1, Linha 1 O arquivo 'Database_Log2' do banco de dados restaurado 'DatabaseName' está sendo deixado no estado extinto porque o banco de dados está usando o modelo de recuperação simples e o arquivo está marcado para acesso de leitura/gravação. Portanto, somente arquivos somente leitura podem ser recuperados por meio da restauração gradual.
O banco de dados é restaurado e é considerado online, mas qualquer operação de backup falha devido a este arquivo DEFUNCT com o seguinte erro:
Msg 3636, Nível 16, Estado 2, Linha 1 Ocorreu um erro ao processar os metadados 'BackupMetadata' para o banco de dados id 10 arquivo id 6. Msg 3046, Nível 16, Estado 2, Linha 1 Foram encontrados metadados inconsistentes. A única operação de backup possível é um backup de final de log usando a opção WITH CONTINUE_AFTER_ERROR ou NO_TRUNCATE. Msg 3013, Nível 16, Estado 1, Linha 1 BACKUP DATABASE está terminando de forma anormal.
Se eu fizer um RESTORE FILELISTONLY no full e no diferencial, ambos me darão a mesma saída, que corresponde ao que vejo em sys.database_files no banco de dados de origem. O servidor é SQL2012 SP1, na edição Developer.
Posso fazer um backup completo e imediatamente depois fazer um diferencial e restaurar esses arquivos em um banco de dados diferente no mesmo servidor e ver exatamente o mesmo problema, então há algo em como o diferencial é criado que está causando isso. Se eu restaurar o backup completo COM RECUPERAÇÃO, não há problema. Não sei se este arquivo existia neste banco de dados, mas é perfeitamente possível que este arquivo existisse e tenha sido excluído há muito tempo. Se eu consultar sys.database_files no banco de dados restaurado, o arquivo DEFUNCT terá um valor para drop_lsn, o que parece confirmar isso. Atualmente, no banco de dados de origem, há apenas um grupo de arquivos (PRIMARY), 4 arquivos de dados e um arquivo de log.
Alguma ideia?