É possível armazenar nomes/sobrenomes/completos e possivelmente informações adicionais de/para contas de usuário oracle no oracle?
Eu olho para a tabela dba_users, mas ela não contém essas informações.
Preciso ter certeza de que as contas do oráculo estão mapeadas para uma única pessoa. Portanto, além dos nomes, idealmente, preciso ter informações básicas de identidade ou endereço de e-mail sobre os nomes.
Como isso pode ser garantido no oráculo?
Estou procurando uma consulta para obter todos os valores de atributo "NetAmount" do elemento "PRODUCT" do seguinte exemplo XML:
<ROOT>
<CATEGORY name="A">
<PRODUCT NetAmount="10.50"/>
<PRODUCT NetAmount="20.50"/>
</CATEGORY>
<CATEGORY name="B">
<PRODUCT NetAmount="30.50"/>
<PRODUCT NetAmount="40.50"/>
<PRODUCT NetAmount="75.50"/>
</CATEGORY>
</ROOT>
Para o meu cenário, não importa se o XML está armazenado em uma tabela ou variável.
Eu tentei várias abordagens diferentes, mas todas falharam.
Amostra:
SELECT
NetAmount.value('(@NetAmount)[1])','varchar(250)') AS Products
FROM
@x.nodes('//ROOT/Category/Product')
AS P(NetAmount)
Geralmente recebo a seguinte mensagem de erro que não faz sentido para mim:
Meldung 2370, Ebene 16, Status 1, Zeile 5 XQuery [value()]: Am Ende des XQuery-Ausdrucks wurden keine Token mehr erwartet. Gefunden: ')'.
Eu tenho a seguinte estrutura com um número variável de elementos no 2º nível na raiz com nomes desconhecidos:
<root>
<A>text a</A>
<B>text b</B>
</root>
Preciso de uma consulta que entregue o texto de um elemento específico no 2º nível. o nome do elemento requerido é o argumento passado por um usuário.
Já consegui encontrar por exemplo para o elemento "A", consultando o documento XML armazenado na variável @x:
declare @str varchar(1000) = '<root><A>text a</A><B>text b</B></root>'
declare @x xml = convert(xml, @str)
SELECT xLangStruct.x.value('(A/text())[1]', 'varchar(100)') from @x.nodes('//root') as xLangStruct(x)
Isso funciona para "A", mas agora preciso substituir "A" por uma variável ou qualquer tipo de filtragem ... Então, preciso de algo assim:
SELECT xLangStruct.x.value('(@SEARCHEDELEMENT/text())[1]', 'varchar(100)') from @x.nodes('//root') as xLangStruct(x)
ou
SELECT xLangStruct.x.value('(./text())[1]', 'varchar(100)') from @x.nodes('//root') as xLangStruct(x) WHERE xLangStruct.x.Elementname = @SEARCHEDELEMENT
Desejo usar o logshipping para transferir bancos de dados grandes (tamanho de 400-700 GB) do servidor (e armazenamento) A para o servidor (e armazenamento) B.
Tentei isso várias vezes e funcionou. Mas tenho dúvidas sobre alguns detalhes:
Ao usar o LogShipping, os únicos Log-Backups que podem ser feitos são os backups que o processo de logshipping cria. Portanto, outros softwares ou trabalhos de backup devem ser desativados antecipadamente.
No caso de eu configurar o envio de log, o backup completo inicial necessário, independentemente de eu fazer e restaurar manualmente antes da configuração de envio de log ou deixar a configuração de envio de log criar e restaurá-lo para mim, levará um tempo, pelo menos uma hora ou mais, para ser concluído, e tempo adicional para ser restaurado no secundário. Eu já tentei ambas as opções com sucesso para dbs menores.
Minha pergunta é: Se eu configurar o logshipping para um banco de dados grande e precisar fazer uma recuperação pontual, o que acontecerá no tempo entre fazer o backup completo inicial e o primeiro backup de log feito após a restauração do backup completo? backup foi concluído? Existe algo como uma lacuna no backup? Antes que a configuração do envio de logs seja concluída, acho que não há backup configurado, então perderei esse período de tempo? Ou o log de transações continuará crescendo até que a parte de restauração de backup completo seja concluída e o primeiro backup de log aconteça?
Enquanto me peguei reengenhando a funcionalidade do sp_who/sp_whoisactive usando as views sys.sysprocesses e sys.dm_exec_session, para ter uma visão geral sobre a execução de sessões e transações no meu servidor, pensei: " não, em vez disso, use algo que já esteja disponível e testado! "
exec sp_whoisactive @get_additional_info = 1;
retorna uma coluna XML adicional que oferece muitas informações, uma delas é o Nível de Isolamento .
Eu gostaria de ter o nível de isolamento no conjunto de resultados primário de sp_whoisactive. Alguém teve o mesmo requisito e já resolveu? Por que não é incluído no conjunto de resultados primários do zero, já que é uma informação importante.
Nosso cluster de failover de disponibilidade Always On do SQL Server recém-instalado e configurado com o SQL Server 2016 Enterprise Edition é executado com quatro instâncias e seis nós. Inclui o DB Engine Service e o Agent Service nos recursos de cada Cluster Node. Tudo funciona bem.
Mas agora descobrimos que o serviço Filter Daemon Launcher (FTFDL) de preenchimento de texto existe em cada um dos nós e está sendo executado aleatoriamente, independentemente do fato de onde o Sql-Instance está sendo executado no momento. Alguns nós têm quatro serviços FTFDL em execução, enquanto apenas uma instância está localizada lá. Outros têm um ou dois deles em execução.
Pergunta: Devemos adicionar este serviço como recurso de cluster? Por que ele está sendo iniciado e interrompido aleatoriamente nas instâncias de cluster de failover resultando em vários serviços ativos sem a instância relevante ativa? Qual é a melhor prática aqui?
Hoje eu mudei os locais dos arquivos do tempdb usando o ALTER DATABASE MODIFYcomando e acidentalmente o configurei para usar a raiz do volume . O serviço SQL Server falhou ao reiniciar e apresentou erros de acesso negado no log de eventos. É um cluster de failover de 2016 Sp1. Eu tentei contornar isso usando
NET START MSSQL$INST1 /f /T3608
mas não funciona.
O que é que eu posso fazer sobre isto? Como posso reiniciar o serviço para poder redefinir a configuração para usar uma subpasta.
Hoje percebi que o cache do plano do nosso servidor sql está cheio de centenas e milhares de planos compilados quase idênticos.
O número total de planos é de cerca de 30.000 em um sistema ativo consumindo cerca de 4500 MB. Olhando para eles, há milhares que são quase iguais.
Algumas amostras:
(@ID uniqueidentifier,@GSS nvarchar(663))UPDATE [TAB1] SET [GSS]=@GSS WHERE [ID]=@ID
(@ID uniqueidentifier,@GSS nvarchar(664))UPDATE [TAB1] SET [GSS]=@GSS WHERE [ID]=@ID
(@ID uniqueidentifier,@GSS nvarchar(665))UPDATE [TAB1] SET [GSS]=@GSS WHERE [ID]=@ID
(@ID uniqueidentifier,@GSS nvarchar(666))UPDATE [TAB1] SET [GSS]=@GSS WHERE [ID]=@ID
(@ID uniqueidentifier,@GSS nvarchar(669))UPDATE [TAB1] SET [GSS]=@GSS WHERE [ID]=@ID
(@ID uniqueidentifier,@FR ntext,@uiStamp datetime,@uiUser varchar(10))UPDATE [TTR] SET [FR]=@FR, [uiStamp]=@uiStamp, [uiUser]=@uiUser WHERE [ID]=@ID
(@ID uniqueidentifier,@FR ntext,@uiStamp datetime,@uiUser varchar(11))UPDATE [TTR] SET [FR]=@FR, [uiStamp]=@uiStamp, [uiUser]=@uiUser WHERE [ID]=@ID
(@ID uniqueidentifier,@FR ntext,@uiStamp datetime,@uiUser varchar(12))UPDATE [TTR] SET [FR]=@FR, [uiStamp]=@uiStamp, [uiUser]=@uiUser WHERE [ID]=@ID
(@ID uniqueidentifier,@FR ntext,@uiStamp datetime,@uiUser varchar(13))UPDATE [TTR] SET [FR]=@FR, [uiStamp]=@uiStamp, [uiUser]=@uiUser WHERE [ID]=@ID
O aplicativo usa sp_executesql em quase todos os lugares e passa valores como parâmetros, por isso tive certeza de que os planos estão sendo reutilizados.
Mas agora parece que o aplicativo não se importa com o comprimento do tipo de string e o comprimento é adicionado automaticamente dependendo do tamanho real dos valores, causando um plano diferente para cada combinação de comprimento de string para cada valor de string passado. Então, principalmente, parece que as instruções UPDATE e INSERT são o problema aqui. Acho que alguns desenvolvedores economizaram algum tempo neste momento simplesmente deixando o tamanho de lado.
As contagens de uso desses tipos de planos redundantes UPDATE/INSERT são relativamente baixas (geralmente 1, alguns até 10, apenas alguns até 40 usos).
Seu tamanho varia entre 0,05 MB e 2 MB. É difícil dizer valores e quantias exatos para possíveis economias porque as instruções não podem ser classificadas corretamente devido às constantes de comprimento variáveis entre elas. No entanto, acho que um tamanho médio de plano aqui é de 0,17 MB em cerca de 15.000 planos de atualização/inserção, onde acho que um mínimo de 80% poderia ser salvo, aproximadamente isso pode ser uma economia potencial de 2.040 MB dos 2.550 MB realmente em uso para esses 15.000 planos. Isso reduziria o uso total do cache do plano de 4500 MB para sth. cerca de 2500 MB.
Parece que poderíamos facilmente salvar alguma memória aqui, certo?
Estamos falando de servidores sql com pouca memória (32 GB) que poderiam realmente se beneficiar de alguma memória livre adicional, no entanto, acho que isso também é uma questão de saúde geral do sistema.
Então, minha pergunta é, o que posso fazer sobre isso? Eu tenho QUALQUER opção no lado do banco de dados para obter controle sobre isso? Existem opções de otimização de consulta adhoc que eu ainda não conheço, digamos, ignore isso?
Ou é realmente necessário que o desenvolvedor adicione corretamente o tipo e o comprimento do tipo aos parâmetros de entrada?
No caso de tipos (n)varchar, o comprimento inicial já está definido na definição da tabela, portanto, existem desvantagens ao usar exatamente esses?
Informação adicional:
Enquanto isso, encontrei o post do K.Tripps sobre o cache do plano ficando selvagem ... e sua consulta me mostra que tenho planos de 1500 MB e 20300 com contagem de uso de 1 no cache ...
"Otimizar para cargas de trabalho ad hoc" é uma bala de prata no meu caso específico?
Mais algumas informações: descobri que as consultas são criadas por SqlDataAdapter e SqlCommandBuilder. O Tamanho do Parâmetro para todos os parâmetros criados não são derivados de qualquer forma da tabela de origem pelo construtor de comandos. Se eles não forem definidos, o tamanho dos valores reais passados em nós será usado como valor de tamanho. Isso pode ser encontrado aqui: " Se não for definido explicitamente, o tamanho é inferido do tamanho real do valor do parâmetro especificado. "
A seguinte consulta simples atingiu o tempo limite várias vezes durante os últimos dias:
SELECT Object1.*,
Object2.Column1,
Object2.Column2 AS Column3
FROM Object2 INNER JOIN Object1 ON Object2.Column2 = Object1.Column3
WHERE Object2.Column4=Variable1 AND
Object2.Column5=Variable2 AND
Object1.Column6=Variable3
Eu poderia pegá-lo no SentryOne e o vi sendo executado com frequência, executando o tempo limite de consulta de 60 segundos definido pelo aplicativo e causando constantemente 12 milhões de leituras.
Não consegui ver nada relacionado, como bloqueios ou impasses, causando o tempo limite.
Copiei a consulta e a executei no SSMS. Ele retornou em poucos ms e retornou zero linhas. Este é o plano de execução que recebi: https://www.brentozar.com/pastetheplan/?id=SJ-LK8jug
Mais tarde, fiz esta etapa novamente com a mesma consulta e os mesmos valores de parâmetro. De repente, ele funcionou por cerca de 90 segundos retornando zero linhas e obtive um plano diferente da seguinte forma: https://www.brentozar.com/pastetheplan/?id=HyVu58i_l
Como você pode ver, o número de linhas estimadas é 1 e o número de linhas reais é enorme. Isso me fez adivinhar que muitas mudanças foram feitas na tabela. Então eu olhei para os valores [sys].[dm_db_stats_properties] para as tabelas envolvidas, especialmente para OBJECT1 e os índices usados.
[Observe para evitar confusão, os planos anônimos usam os mesmos nomes para diferentes índices (Object1.Index1)]
Neste ponto, vi os seguintes valores estatísticos ...
Object1.Index1 ( referenciando o segundo plano de execução ineficiente ):
RowsInTable=3826101
RowsSampled=103245
UnfilteredRows=3826101
RowMods=2140
Histogram Steps 200
PercentChanged=0.0
Para Object1.Index2 (Índice Agrupado):
RowsInTable=3826101
RowsSampled=103734
UnfilteredRows=3826101
RowMods=2140
HistoSteps=199
PercentChanged=0.0
Então percebi que acidentalmente adicionei uma quebra de linha na primeira execução e acho que isso me fez ter um plano de execução diferente e novo.
Decidi atualizar todas as estatísticas da tabela OBJECT1. Depois disso, executei a consulta inicial novamente quando a peguei do SentryOne sem QUALQUER ALTERAÇÃO, sem quebras de linha ...
Desta vez foi rápido como esperado e o plano de execução foi idêntico ao primeiro plano eficiente. Isso me faz suspeitar que as estatísticas eram meio obsoletas.
Eu consultei as meta-informações estatísticas novamente com os seguintes resultados ( referenciando o primeiro plano eficiente) :
Object1.Index1 (Índice Agrupado)
RowsinTable=3828157
RowsSampled=104017
UnfilteredRows=3828157
RowModifications=14
HistoSteps=199
PercentCahnge=0.0
Para Object1.Index2 (Índice não clusterizado)
RowsInTable=3828157
RowsSampled=103275
UnfilteredRows=3828157
RowMods=14
HistogrSteps=127
PercentChanged=0.0
O aplicativo depois foi executado como esperado, rapidamente sem timeouts. Então eu acho que STATISTICS UPDATE ajudou aqui.
Deixe-me salientar adicionalmente que, como parte da minha manutenção automatizada de índices e estatísticas durante a noite, todos os índices da tabela foram mantidos/atualizados com sucesso durante a última noite.
Agora minhas perguntas:
Eu sei que os planos de execução são problemáticos se eles esperam poucas linhas e realmente retornam muitas linhas a mais do que o esperado. Não entendo como um plano de execução pode revelar 3.141.000 linhas se realmente retornar ZERO linhas. Como isso é possível?
A investigação na tabela OBJECT 1 e suas estatísticas não mostraram nenhuma dica para alterações maiores ou linhas adicionadas. Consultei linhas adicionadas ou alteradas desde a última manutenção automatizada de índice e estatísticas e parece que 2.370 linhas foram alteradas enquanto ~ 3.800.000 linhas estão na tabela. Esta é uma pequena quantidade alterada como os valores de [sys].[dm_db_stats_properties] também mostraram. As estatísticas poderiam realmente ser um problema aqui? os números que citei acima mostram alguma boa razão para uma atualização de estatísticas?
ATUALIZAÇÃO: Os valores para ParameterCompiledValue e ParameterRuntimeValue são idênticos no GOOD PLAN, mas diferentes no BAD PLAN. A Tabela OBJECT1 tem um valor na Coluna6 que fornece > 3 milhões de linhas, enquanto todos os outros valores fornecem um máximo de cerca de 60 mil linhas. O Plano BAD usou exatamente esse valor >3 Mio Rows para ParameterRuntimeValue enquanto foi compilado com um valor que entregaria apenas 160 Rows. Então, parece que eu preciso de um plano que aborde os dois cenários ou uma solução mais flexível que crie um plano adequado de qualquer maneira...?
Gostaria de saber se os métodos internos de crescimento de um arquivo usando
ALTER DATABASE testdb
MODIFY FILE
(
NAME = testdb_Log
, SIZE = 40960MB --40 GB
)
trabalhar diferente, deixando o arquivo crescer automaticamente para o mesmo tamanho ao longo do tempo?
Antecedentes da minha pergunta: eu enfrento contagens de VLF muito altas (> 10K) em vários arquivos de log de diferentes bancos de dados ativos com recuperação total com tamanho em torno de 100 GB.
Ao testar estratégias para corrigir isso, redimensionei um arquivo de log para 16 MB com 4 VLFs e deixei crescer para 40960 MB e depois com uma configuração AUTOGROW de 100 MB. Depois eu tinha 20 VLF no arquivo.
Minha expectativa era ver mais
(40960 MB - 16 MB) / 100 MB * (8 VLF por crescimento automático) = 3276 VLF no arquivo.
Em vez disso, agora tenho apenas 20. Por quê?
Segunda parte da minha pergunta: Até agora eu entendi que uma configuração de AUTOGROW inadequada causa as altas contagens de VLF, que é definitivamente o caso em nossos dbs onde essa configuração não foi cuidada por um longo período de tempo. Todos os artigos explicando como lidar com esta situação aconselham escolher um valor adequado para AUTOGROW. Mas se eu estiver certo, supondo que, se o processo de crescimento manual (primeira parte deste post) nem usar a configuração de crescimento automático, e eu aumentar o arquivo de log dessa maneira para um tamanho adequado que não exija nenhum crescimento automático, o crescimento automático configurações não é tão importante depois?
Terceira parte da minha pergunta? A contagem de VLF de 20 em um arquivo de log de 40 GB agora é muito baixa? É por isso que li que devemos incrementar o arquivo novamente em incrementos? Qual contagem de VLF pode ser um número BOM (de desempenho) para um arquivo de log de 40 G ou 80 G?
Não consegui estabelecer uma conexão DAC local usando o SSMS enquanto estava conectado à área de trabalho remota do sistema operacional Sql-Server. O primeiro motivo foi o SQL-Browser Service desativado. Mais tarde, o segundo motivo apontado foi o erro "DAC não ativado":
"Nenhuma conexão DAC pôde ser estabelecida na porta padrão. Certifique-se de que o DAC esteja ativado".
Procurei uma solução. A solução sugerida que encontrei foi habilitar a propriedade Facet "RemoteDacEnabled" ou executar
sp_configure 'remote admin connections', 1
Isso me faz pensar: por que devo habilitar uma propriedade REMOTE DacEnabled caso queira me conectar do SISTEMA LOCAL? Eu entendo REMOTO errado aqui?
"A conexão só é permitida de um cliente em execução no servidor. Nenhuma conexão de rede é permitida."
Se eu tiver que fazer logon no servidor local e NÃO na rede, que sentido faz uma configuração REMOTE DAC?
EDIT/parte da resposta: O principal motivo da minha pergunta foi que eu NÃO entendi por que temos que permitir/ativar as configurações REMOTEDAC apenas no caso de querermos estabelecer uma conexão LOCAL DAC do próprio servidor (foi o que eu tentei sem sorte em primeiro lugar).
AGORA, depois de tentar mais, descobri que usar ...
ServerName.SubDomain.Domain.de
causou este erro ao conectar-se ao DAC enquanto ...
Nome do servidor
FUNCIONA (sem ativar a configuração RemoteDac).
(O estranho é que consigo me conectar bem usando uma conexão "normal" com ambas as opções)
A causa raiz foi que o FQDN foi interpretado como um servidor remoto e isso causou o erro acima.
No entanto, depois de habilitar o REMOTEDAC, as duas opções acima funcionam para um DAC, independentemente de eu tentar localmente no servidor ou em clientes remotos.
É possível criar FAILOVER CLUSTER A com Node01 (ativo) e Node02 (passivo) e FAILOVER CLUSTER B com o mesmo Node02 (passivo) e Node03 (ativo)?
Percebi que as instâncias do SQL Server em nós passivos não são cobradas, apenas o sistema operacional. Portanto, compartilhar um nó para mais de uma instância Sql passiva faria sentido aqui. Eu sei, uma vez que o cluster A e o cluster B têm um problema, sou cortado ...
Mas este é um cenário permitido e/ou comum?
Tenho a seguinte estrutura:
Table R Table RZ (n-m) Table Z
------- ----------------- ---------
R1 R1 | Z1 Z1 | "A"
R2 R1 | Z2 Z2 | "B"
R3 R2 | Z1 Z3 | "C"
R4 R2 | Z3 Z4 | "D"
... R3 | Z1 ...
... R3 | Z2 ...
... R3 | Z4 ...
(Deixei de fora algumas complicações adicionais e outras junções para simplificar)
Preciso consultar todas as linhas de "R" com algumas das colunas ou "R" incluindo uma coluna no resultado que tenha a coluna "Nome" concatenada da tabela "Z".
Aqui está uma amostra seguindo o conteúdo da tabela acima:
ID of R | Name of Z
--------------------
R1 | "A,B"
R2 | "A,C"
R3 | "A,B,D"
Até agora, uma função escalar estava em vigor, usada por cada linha de R, consultando novamente a junção R-RZ-Z novamente, concatenando e retornando os nomes, mas percebi que isso é muito lento.
Tentei FOR XML, mas não consigo combinar o resultado XML entregando a string que desejo com o restante das colunas exigidas da tabela R.
Qual é a melhor maneira de resolver isso?
Estou enfrentando o seguinte problema, minhas instruções MERGE baseadas em dados (exibições) que não fornecem chaves primárias ou nenhuma chave exclusiva, sempre apenas ADICIONE INSERTS adicionais em cada execução na tabela de destino.
Como usei TODAS AS COLUNAS na parte de comparação, esperava que fossem comparadas com o destino e, no caso de correspondência, NÃO inseridas, mas deixadas sozinhas.
Em vez disso, o número de linhas no destino continua crescendo continuamente a cada execução.
Sim, eu sei que pode ser melhor entregar a chave primária. Mas não tenho conhecimento suficiente sobre os dados entregues e, em alguns casos, não foi possível encontrar uma combinação de chave primária.
Como posso evitar inserções adicionais nesse caso?
MERGE INTO [Z].[IAPP] AS Target
USING (
SELECT
[SXD],[UUZQ],[SSRTD],[AAFFT],[IID] From [Z].[vIAPP]
) AS Source ([SXD],[UUZQ],[SSRTD],[AAFFT],[IID])
ON (Target.[SXD] = Source.[SXD] AND Target.[UUZQ] = Source.[UUZQ] AND Target.[SSRTD] = Source.[SSRTD] AND Target.[AAFFT] = Source.[AAFFT] AND Target.[IID] = Source.[IID])
WHEN NOT MATCHED BY TARGET AND @Action = 'UI' THEN
INSERT([SXD],[UUZQ],[SSRTD],[AAFFT],[IID])
VALUES(Source.[SXD],Source.[UUZQ],Source.[SSRTD],Source.[AAFFT],Source.[IID])
WHEN NOT MATCHED BY SOURCE AND @Action = 'D' THEN
DELETE;
Qual é a melhor maneira de reinstalar um SQL Server que foi instalado usando um idioma errado sem perder nenhuma configuração?
Devo instalar uma segunda instância paralela à instância padrão - aqui não sei se isso é possível se estiver usando um idioma diferente?
Ou devo fazer uma segunda instalação do Sql Server (como se fossem duas Versões diferentes)?
Como alternativa, é claro que eu poderia desinstalar o antigo e instalar um novo Sql Server usando o idioma correto.
Independente do caminho a seguir, como você pode imaginar, definitivamente quero evitar fazer todo o trabalho de manutenção para criação de Logins, Usuários, Permissões, Alertas, Operadores, Jobs etc. novamente. Existe uma boa abordagem para conseguir isso?
Estou procurando a solução mais elegante para evitar a adição do último separador ';' após a última linha.
Por exemplo, o resultado deve ser
'Peter, Paul, Jill'
ao invés de
'Peter, Paul, Jill,'
DECLARE @p varchar(max) = '';
SELECT @P = @P + col2 +',' FROM tab1 WHERE coli = 1
RETURN @P
A solução
RETURN LEFT(@P, LEN(@P) -1);
funciona apenas se @P for longo o suficiente e, portanto, não for uma solução ...
Como posso resolver isso elegante e confiável?
Dado:
Consulta nº 1:
begin tran
UPDATE [dbo].[t] SET [mydatetime]='2011-12-25 07:00:00.000';
rollback
Consulta #2: (alterando mês/dia)
begin tran
UPDATE [dbo].[t] SET [mydatetime]='2011-25-12 07:00:00.000';
rollback
Por que a CONSULTA nº 1 falha ao ser executada em um novo SQL Server instalado enquanto a consulta nº 2 é executada com êxito?
Msg 242, Level 16, State 3, Line 6 Bei der Konvertierung eines varchar-Datentyps in einen datetime-Datentyp liegt der Wert außerhalb des gültigen Bereichs.
Em comparação, por que a consulta nº 1 é executada no servidor antigo, enquanto a consulta nº 2 falha no novo servidor?
Msg 242, Nível 16, Estado 3, Linha 7 A conversão de um tipo de dados varchar em um tipo de dados datetime resultou em um valor fora do intervalo.
Os servidores possuem versões diferentes (2008/2016). E como você pode ver nas mensagens de erro, existem dois idiomas diferentes instalados. Por favor, não me diga que só porque o idioma da instalação do Sql-Server é diferente, ele não é capaz de lidar com diferentes formatos de data?
Isso é configurável? Vou me safar com formatos uniformes como 20150129 08:00:00.000?
Criei instruções MERGE para transferir diferenças com um conjunto mínimo de colunas necessárias do banco de dados de produção para um banco de dados de teste. As tabelas mescladas são planejadas para serem usadas por diferentes cenários de relatório e análise (somente leitura). Todo o processo de obter as diferenças nas tabelas de teste deve ser rápido (pelo menos muito mais rápido do que a maneira atual de obter todo o conteúdo da tabela todos os dias fazendo um DELETE seguido de INSERT INTO para todos os dados, independentemente da quantidade de fato dados alterados que estimo em cerca de 5%).
Aqui está uma amostra:
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
SET NOCOUNT ON
IF NOT exists(select 1 from StagingDB.sys.tables t join StagingDB.sys.schemas s on t.schema_id = s.schema_id WHERE t.name like 'A' and s.name like 'staging')
BEGIN
SELECT Top 0 [ID],[OID]
INTO [StagingDB].[staging].[A]
From [LiveDB].[dbo].[A];
END;
MERGE INTO [StagingDB].[staging].[A] AS Target
USING (
SELECT [ID], [OID] From [LiveDB].[dbo].[A] where X = 0
) AS Source ([ID],[OID])
ON (Target.[ID] = Source.[ID])
WHEN MATCHED AND (Target.[OID] <> Source.[OID]) THEN
UPDATE SET [OID] = Source.[OID]
WHEN NOT MATCHED BY TARGET THEN
INSERT([ID],[OID]) VALUES(Source.[ID],Source.[OID])
WHEN NOT MATCHED BY SOURCE THEN
DELETE;
IF NOT EXISTS(
SELECT * FROM sys.indexes ix Where ix.name = 'PK_A' AND ix.object_id = OBJECT_ID('[StagingDB].[staging].[A]')
)
BEGIN
ALTER TABLE [StagingDB].[staging].[A] add constraint PK_A primary key CLUSTERED ([ID])
END
Isso é executado MUITO RAPIDAMENTE para a maioria das minhas tabelas. Infelizmente, existem duas tabelas que têm muito mais linhas e, além disso, muito mais colunas dessas duas tabelas estão sendo usadas posteriormente no processo de geração de relatórios, portanto, tenho que transferir muito mais dados.
Embora eu possa executar esse tipo de comando de mesclagem para 71 tabelas em menos de um minuto, as duas instruções MERGE problemáticas são executadas por cerca de 2 horas cada. Ainda não consegui descobrir o porquê.
Desconfio da quantidade de datas, mas também da forma como comparo as diferenças das tabelas. Para descobrir se devo executar uma instrução UPDATE, faço uma comparação para cada coluna incluída na instrução Merge. Portanto, caso eu tenha 10 colunas, a condição UPDATE do MERGE fica assim:
WHEN MATCHED AND (Target.[OID] <> Source.[OID] OR Target.[OID1] <> Source.[OID2] OR Target.[Text1] <> Source.[Text1] OR Target.[varcharlong1] <> Source.[varcharlong1] ) etc...
Acontece que esse tipo de verificação de condição de atualização inclui todas as colunas e não terá um índice. As tabelas de preparação sempre têm uma chave primária agrupada em identificador único e (até agora) nenhum índice adicional.
Minha pergunta é: embora a instrução MERGE esteja sendo executada de maneira muito rápida e eficiente para a maioria de nossas tabelas, parece que esse procedimento não é adequado para as duas tabelas maiores, incluindo várias colunas. Estou usando a instrução MERGE corretamente neste caso usando a cláusula OR para garantir que as linhas precisem ser atualizadas ou existe uma maneira melhor? Existe uma maneira melhor de obter rapidamente o delta (alterações) para um subconjunto de colunas em uma tabela de preparo? todas as minhas tabelas têm um ROWVERSION, talvez isso possa ser usado para descobrir as linhas que foram alteradas de alguma forma?
Eu tenho um processo de envio de logs em execução. Hoje percebi que os arquivos de log devem ter sido substituídos durante o período de alteração do relógio ontem, onde o relógio foi atrasado das 3h para 2h. Então, estou preocupado que algo possa estar errado. Eu olhei para os arquivos que foram copiados e descobri que eles estão armazenados com um nome de arquivo no horário UTC. O período de 01:00 - 02:00 UTC está faltando aqui.
A mesma saída está na saída de log_shipping_monitor_history_detail: Aqui 01AM-02AM também estão ausentes enquanto a coluna log_time está em andamento sem nenhuma duplicata.
Eu faço backup, cópia e restauração em períodos de 15 minutos.
O status genérico (master.dbo.sp_help_log_shipping_monitor) do processo de envio de log mostra 0 (OK).
O logshipping considera a alteração do relógio ou devo tomar alguma providência?
Eu tenho que mudar uma tabela particionada no Sql Server 2008 R2 para uma tabela normal para tornar meu banco de dados compatível com o Sql Server 2016 Standard Edition.
Na verdade a tabela possui 5 partições com o seguinte número de linhas:
> boundary, rows
2009-01-01 00:00:00.000 419
2010-01-01 00:00:00.000 386031
2011-01-01 00:00:00.000 1307990
2012-01-01 00:00:00.000 673183
NULL 9743057
A tabela contém uma coluna BLOB (imagem). O tamanho total da tabela é de cerca de 25 GB.
Eu li a pergunta Como remover uma partição de tabela , mas embora tenha respondido, não há resposta aceita e as respostas não abordam minha pergunta inteiramente.
Percebi o comando ALTER PARTITION FUNCTION MERGE RANGE , mas não entendi direito o que vai acontecer. Os dados serão mesclados em um dos grupos de arquivos existentes e depois ainda terei uma tabela particionada?
Em vez disso, tenho que copiar todos os dados para uma nova tabela com a mesma estrutura (pode demorar um pouco...)?
Terei que realizar esta ação durante um tempo de inatividade, por isso preciso de um procedimento que seja o mais eficiente possível.