All perguntas(dba)

Preciso obter vários valores de uma sequência com apenas uma consulta. No Stack Overflow, encontrei isto:

https://stackoverflow.com/questions/896274/select-multiple-ids-from-a-postgresql-sequence

A solução parece ser a seguinte:

select nextval('my_sequence') from generate_series(1, N)

Como isso se comporta quando meu aplicativo pode iniciar essa consulta simultaneamente sempre que atende a alguma solicitação do cliente?

A resposta mais votada tem um comentário que diz:

Observe que não há garantia de que os 3 números (nextvals) sejam sequenciais.

Não me importo necessariamente com a sequencialidade, mas é garantido que os valores retornados sejam pelo menos estritamente crescentes monotonicamente, mesmo que possam ser entrelaçados com os valores gerados por outra consulta simultânea?

Temos uma tabela #ValidCode com uma lista de códigos válidos como: 'A', 'B', 'C', etc. Outra tabela chamada #SourceData com dados de entrada — que vêm como uma combinação de tokens válidos e inválidos (às vezes duplicados).

Ex:

• 'A;B;C' ( válido )
• 'A;A;A;A;A;B' ( Válido )
• 'ad;df;A;B' ( inválido )

Tentando encontrar uma abordagem de consulta ótima para processar essas strings para encontrar linhas válidas em #SourceData . Veja o exemplo abaixo:

DROP TABLE IF EXISTS #ValidCode
GO
CREATE TABLE #ValidCode
(
      ID        INT             IDENTITY(1,1)
    , Code      CHAR(1)
)
INSERT INTO #ValidCode (Code) VALUES ('A'), ('B'), ('C')
GO
DROP TABLE IF EXISTS #SourceData 
GO
CREATE TABLE #SourceData 
(
      ID        INT             IDENTITY(1,1)
    , Codes     VARCHAR(500)
    , Is_Valid  BIT
    , Is_Split  BIT
)

INSERT INTO #SourceData (Codes) 
VALUES    ('A;B;C')
        , ('B;A')
        , ('B;B;B;C;C;A;A;B')
        , ('B;Z;1')
        , ('B;ss;asd')


SELECT * FROM #ValidCode
SELECT * FROM #SourceData

A consulta processaria os dados na tabela #SourceData e atualizaria o sinalizador Is_Valid para que eles pudessem ser consumidos no processo subsequente.

Regras :

• Cada token deve ser válido para que toda a linha da coluna seja válida (linhas 1 a 3)
• Mesmo que um token seja inválido, o valor da linha inteira será inválido (linhas 4 e 5)

Então, esta é a saída preferida:

Abordagem atual : Faça um loop por cada linha em #SourceData e divida-as no delimitador ';', depois compare-as com a tabela #ValidCode . Se todos os tokens forem individualmente válidos, marque a linha em #SourceData como válida ( flag Is_Valid ). Caso contrário, marque como inválida. A WHILEabordagem de loop funciona, mas é lenta.

O #SourceData pode ter até 3 milhões de linhas. Com cada linha tendo várias combinações de valores válidos duplicados ('A;A;A;A') e inválidos ('A;as;sdf;B')

Existe uma abordagem melhor?

Obrigado!

Suponha que você tenha uma tabela que seja:

• Lido com tanta frequência que quase sempre fica na RAM.
• Muito pequeno.
• Quase nunca mudou.

Há alguma desvantagem em mover tal tabela para OLTP na memória? Meus pensamentos são que se ela estiver sempre na memória de qualquer maneira, então você deve considerar usar a arquitetura projetada para viver na memória.

Estou explorando o procedimento sp_rename no MSSQL com base na entrada fornecida em uma resposta a outra pergunta.

Tenho cerca de 50 tabelas que foram criadas com uma coluna UID tendo um nome de restrição exclusivo aleatório como "UQ__tblAssig__C5B19603C906D5BE". Quero renomear essas restrições para exatamente I_UID para todas as tabelas para cumprir com outros índices usados ​​nas diferentes tabelas. Observe que o índice [I_UID] não está presente em nenhuma das tabelas de antemão. Executar a primeira dessas três linhas funciona bem, e obtenho um índice I_UID na pasta de índice de tblAssignmentType.

EXEC sp_rename N'[tblAssignmentType].[UQ__tblAssig__C5B19603C906D5BE]', N'[I_UID]', N'INDEX';
EXEC sp_rename N'[tblProduct].[UQ__tblProdu__C5B196034878474D]', N'[I_UID]', N'INDEX';
EXEC sp_rename N'[tblAssignment].[UQ__tblAssig__C5B196031B17A97B]', N'[I_UID]', N'INDEX';

Entretanto, quando executo uma das próximas linhas, recebo a seguinte mensagem de erro:

Msg 15335, Level 11, State 1, Procedure sp_rename, Line 733 [Batch Start Line 38]
Error: The new name '[I_UID]' is already in use as a INDEX name and 
       would cause a duplicate that is not permitted.

Mas em tblProduct eu não tenho um índice chamado I_UID. Portanto, suspeito que a declaração de renomeação anterior fez um índice I_UID no escopo global, mesmo que ele apareça na tabela correta.

O que me leva à pergunta: que tipo de sintaxe eu poderia usar com sp_rename para especificar que o novo nome deveria estar contido dentro do escopo de uma determinada tabela de tal forma que o mesmo nome local também pudesse ser usado para outras tabelas posteriormente?

Eu uso o SQL SMS (SSMS) para executar todas as ações no meu único MS SQL DB. Sou apenas um administrador. Nunca restaurei um backup.

Quando faço um backup completo, tudo funciona. Depois, se eu quiser fazer um backup diferencial no dia seguinte, recebo um erro em que ele não consegue encontrar o backup:

Não é possível executar um backup diferencial do banco de dados "PMI" porque não há backup do banco de dados atual.

Desculpe, não forneço mais informações. Todos os erros aparecem em francês (idioma do sistema).

Não tenho problemas se eu fizer backups diferenciais logo após o backup completo.

Esta solicitação SQL:

SELECT  

   msdb.dbo.backupset.database_name,  
   msdb.dbo.backupset.backup_start_date,  
   msdb.dbo.backupset.backup_finish_date, 
   msdb.dbo.backupset.expiration_date,
   msdb..backupset.type, 
   CASE msdb..backupset.type  
       WHEN 'D' THEN 'Full'  
       WHEN 'I' THEN 'Diff'
       WHEN 'L' THEN 'Log'  
   END AS backup_type,
   CASE msdb.dbo.backupmediafamily.device_type 
       WHEN 2 THEN 'Disk'
       WHEN 5 THEN 'Tape'
       WHEN 7 THEN 'Virtual Device' 
       WHEN 9 THEN 'Azure Storage' 
       WHEN 105 THEN 'A permanent backup device'
       ELSE 'Unknown' 
   END AS device_type_desc,
   msdb.dbo.backupmediafamily.physical_device_name,
   msdb.dbo.backupset.is_copy_only,
   msdb.dbo.backupset.is_snapshot,   
   msdb.dbo.backupset.first_lsn,
   msdb.dbo.backupset.last_lsn,
   msdb.dbo.backupset.database_backup_lsn,
   msdb.dbo.backupset.checkpoint_lsn,
   msdb.dbo.backupset.differential_base_lsn,
   msdb.dbo.backupset.fork_point_lsn,
   msdb.dbo.backupmediaset.name,
   msdb.dbo.backupmediaset.software_name,
   msdb.dbo.backupset.user_name,
   'EOR'
   
FROM   msdb.dbo.backupmediafamily  
   INNER JOIN msdb.dbo.backupset 
   ON msdb.dbo.backupmediafamily.media_set_id = msdb.dbo.backupset.media_set_id  
   INNER JOIN msdb.dbo.backupmediaset
   on msdb.dbo.backupmediaset.media_set_id = backupmediafamily.media_set_id

WHERE 1 = 1

AND   (CONVERT(datetime, msdb.dbo.backupset.backup_start_date, 102) >= GETDATE() - 7)

AND     database_name IN ('PMI')     

ORDER BY   --2,

           2 desc,3 desc;

Resultado de retorno:

database_name  backup_start_date       backup_finish_date      expiration_date         type backup_type device_type_desc          physical_device_name                                          is_copy_only is_snapshot first_lsn              last_lsn               database_backup_lsn    checkpoint_lsn         differential_base_lsn  fork_point_lsn  name  software_name         user_name           
-------------- ----------------------- ----------------------- ----------------------- ---- ----------- ------------------------- ------------------------------------------------------------- ------------ ----------- ---------------------- ---------------------- ---------------------- ---------------------- ---------------------- --------------- ----- --------------------- --------------------
PMI            2024-11-19 20:25:21.000 2024-11-19 20:25:33.000 2024-12-04 20:25:21.690 D    Full        Disk                      D:\SQL Backup\PMI\PMI_backup_2024_11_19_202521_6517704.bak    0            0           104302000000558300001  104302000000558600001  104222000001229700037  104302000000558300001  NULL                   NULL            NULL  Microsoft SQL Server  sa                  
PMI            2024-11-19 01:59:51.000 2024-11-19 01:59:53.000 2024-11-27 01:59:51.703 D    Full        Virtual Device            {960E26B9-BCB7-482C-BDAC-207548B83077}3                       0            1           104222000001229700037  104222000001231400001  104222000001228000001  104222000001229700037  NULL                   NULL            NULL  Microsoft SQL Server  AUTORITE NT\Système 
PMI            2024-11-19 00:59:26.000 2024-11-19 00:59:37.000 2024-12-04 00:59:26.060 D    Full        Disk                      D:\SQL Backup\PMI\PMI_backup_2024_11_19_005925_9360289.bak    0            0           104222000001228000001  104222000001228300001  104219000001378500037  104222000001228000001  NULL                   NULL            NULL  Microsoft SQL Server  sa                  
PMI            2024-11-18 01:59:47.000 2024-11-18 01:59:49.000 2024-11-26 01:59:46.977 D    Full        Virtual Device            {230EA0F3-9D31-4279-A5DB-D1E74A9F800D}3                       0            1           104219000001378500037  104219000001380200001  104219000001374100001  104219000001378500037  NULL                   NULL            NULL  Microsoft SQL Server  AUTORITE NT\Système 
PMI            2024-11-17 23:00:05.000 2024-11-17 23:00:05.000 2024-11-25 23:00:05.213 I    Diff        Disk                      D:\SQL Backup\PMI\PMI_backup_2024_11_17_230005_0981356.diff   0            0           104219000001377400001  104219000001377700001  104219000001374100001  104219000001377400001  104219000001374100001  NULL            NULL  Microsoft SQL Server  sa                  
PMI            2024-11-17 22:00:07.000 2024-11-17 22:00:19.000 2024-11-25 22:00:07.307 D    Full        Disk                      D:\SQL Backup\PMI\PMI_backup_2024_11_17_220007_1834384.bak    0            0           104219000001374100001  104219000001374400001  104219000001366900037  104219000001374100001  NULL                   NULL            NULL  Microsoft SQL Server  sa                  
PMI            2024-11-17 09:59:50.000 2024-11-17 09:59:53.000 2024-11-25 09:59:50.867 D    Full        Virtual Device            {04A6F783-F33B-4558-8DCE-53D7FEB0CAEC}3                       0            1           104219000001366900037  104219000001368600001  104219000001362500037  104219000001366900037  NULL                   NULL            NULL  Microsoft SQL Server  AUTORITE NT\Système 
PMI            2024-11-17 01:59:54.000 2024-11-17 01:59:56.000 2024-11-25 01:59:54.717 D    Full        Virtual Device            {13E16352-8EC7-48B9-9FEF-B4C486907099}3                       0            1           104219000001362500037  104219000001364200001  104219000001355000001  104219000001362500037  NULL                   NULL            NULL  Microsoft SQL Server  AUTORITE NT\Système 
PMI            2024-11-16 23:00:05.000 2024-11-16 23:00:06.000 2024-11-24 23:00:05.683 I    Diff        Disk                      D:\SQL Backup\PMI\PMI_backup_2024_11_16_230005_5608786.diff   0            0           104219000001361400001  104219000001361700001  104219000001355000001  104219000001361400001  104219000001355000001  NULL            NULL  Microsoft SQL Server  sa                  
PMI            2024-11-16 15:45:35.000 2024-11-16 15:45:35.000 2024-11-24 15:45:35.063 I    Diff        Disk                      D:\SQL Backup\PMI\PMI_backup_2024_11_16_154535_0369182.diff   0            0           104219000001359000001  104219000001359300001  104219000001355000001  104219000001359000001  104219000001355000001  NULL            NULL  Microsoft SQL Server  sa                  
PMI            2024-11-16 15:45:21.000 2024-11-16 15:45:22.000 2024-11-24 15:45:21.850 I    Diff        Disk                      D:\SQL Backup\PMI\PMI_backup_2024_11_16_154521_8283665.diff   0            0           104219000001358100001  104219000001358400001  104219000001355000001  104219000001358100001  104219000001355000001  NULL            NULL  Microsoft SQL Server  sa                  
PMI            2024-11-16 15:44:55.000 2024-11-16 15:45:06.000 2024-11-24 15:44:55.180 D    Full        Disk                      D:\SQL Backup\PMI\PMI_backup_2024_11_16_154455_1502171.bak    0            0           104219000001355000001  104219000001355300001  104219000001346600001  104219000001355000001  NULL                   NULL            NULL  Microsoft SQL Server  sa                  
PMI            2024-11-16 15:41:46.000 2024-11-16 15:41:58.000 2024-11-24 15:41:46.560 D    Full        Disk                      D:\SQL Backup\PMI\PMI_backup_2024_11_16_154146_5409243.bak    0            0           104219000001346600001  104219000001346900001  104219000001325800261  104219000001346600001  NULL                   NULL            NULL  Microsoft SQL Server  sa                  
PMI            2024-11-16 01:59:50.000 2024-11-16 01:59:53.000 2024-11-24 01:59:50.890 D    Full        Virtual Device            {404A5262-328C-46C9-B456-31D0B249A06D}3                       0            1           104219000001325800261  104219000001336600001  104213000001527500272  104219000001325800261  NULL                   NULL            NULL  Microsoft SQL Server  AUTORITE NT\Système 
PMI            2024-11-15 01:59:56.000 2024-11-15 01:59:58.000 2024-11-23 01:59:56.130 D    Full        Virtual Device            {B685428C-A7AE-4642-A17B-CC729BD16D77}3                       0            1           104213000001527500272  104213000001538700001  104203000000360300144  104213000001527500272  NULL                   NULL            NULL  Microsoft SQL Server  AUTORITE NT\Système 
PMI            2024-11-14 01:59:52.000 2024-11-14 01:59:55.000 2024-11-22 01:59:52.267 D    Full        Virtual Device            {BE641173-DEA0-400A-A31B-2658897D80B9}3                       0            1           104203000000360300144  104203000000366400001  104129000000461200270  104203000000360300144  NULL                   NULL            NULL  Microsoft SQL Server  AUTORITE NT\Système 
PMI            2024-11-13 02:00:05.000 2024-11-13 02:00:08.000 2024-11-21 02:00:04.993 D    Full        Virtual Device            {B7FE8CE1-83D0-4384-BBBC-B729A957527D}3                       0            1           104129000000461200270  104129000000472300001  104122000002730300037  104129000000461200270  NULL                   NULL            NULL  Microsoft SQL Server  AUTORITE NT\Système 

Posso ver uma tarefa às 02:00:00... Acho que é syspolicy_purge_historyuma tarefa padrão do sistema SQL.

ATUALIZAÇÃO: Desativei esta tarefa e continua o mesmo problema.

Você tem uma ideia?

Tenho um requisito em que há duas tabelas principais envolvidas: uma é a tabela de preparação - dados DLSTYTOTAL vindos de outro RDBMS de origem e a outra é a tabela particionada - STYTOTAL_RAW, onde estamos carregando os dados de entrada.

1. Gerar automaticamente o próximo valor de identidade da tabela particionada de origem

Para fazer a partição, criei mais uma tabela de preparação chamada - STYTOTAL_RAW_Intermediate_Staging. Já que a tabela DLSTYTOTAL não tem todas as colunas, particularmente a coluna de identidade e as colunas de chave de partição.

A tabela de preparação principal obtém 10 milhões + dados. Pensei em usar select * into com cada queda de tempo e criá-la na tabela de preparação de partição e então alternar para a tabela de partição. O problema é que não consegui obter o valor IDENTITY correto, pois ele era redefinido a cada vez. Pensei em pegar o valor máximo mais 1 da tabela de partição - STYTOTAL_RAW. Mas select IDENTITY(INT,@IDENTITY_no_max ,1) AS [STYTOTALID] isso não está aceitando variável

declare @IDENTITY_no_max bigint
select  max([STYTOTALID]) as [Original_max] from STYTOTAL_RAW -- original max value
select @IDENTITY_no_max= max([STYTOTALID]+1) from STYTOTAL_RAW
select @IDENTITY_no_max as [@IDENTITY_no_max]
    
select IDENTITY(INT,1,@IDENTITY_no_max) AS [STYTOTALID],ISNULL([STYLE],0) [STYLE],DATEADD(MICROSECOND, ROW_NUMBER() OVER (ORDER BY (SELECT NULL)), SYSDATETIME()) [InsertedDateTime],
CAST(1 AS bit)  as [IsCurrent],[DELDATTIM],[DELFLAG]
into [STYTOTAL_RAW_Intermediate_Staging] from [C1810429].[DLSTYTOTAL]

2. Alterar a coluna de data [InsertedDateTime] para não nula do select * para si mesma.

   selecione DATEADD(MICROSEGUNDO, NÚMERO_DA_LINHA() SOBRE (ORDEM POR (SELECIONE NULO)), é nulo(SYSDATETIME(),'1900-01-01 00:00:00.000') ) [Data_Hora_Inserida] em tbl_date_not_null sp_help 'tbl_date_not_null'

Existe alguma maneira de obter o valor de identidade o tempo todo da tabela de origem e preencher para staging . Também é possível alterar a coluna de data para not null no select * em si mesmo em vez de alter table com not null.

Obrigado pela ajuda.

Adicionando o script aqui: https://dbfiddle.uk/uaMhsB4k

Tenho um problema em não conseguir alterar uma tabela CDC que antes não nos causava problemas.

Executamos instruções alter em nossas tabelas cdc para adicionar uma coluna às tabelas sobre as quais agora estamos começando a enfrentar um erro.

A consulta que estamos tentando executar é

ALTER TABLE cdc.dbo_TABLE_NAME_CT 
    ADD processed BIT DEFAULT 0 NULL

Que agora retorna o seguinte erro

Msg 2104, Nível 16, Estado 13, Linha 34
Não é possível alterar o erro: 8277, Gravidade: -1, Estado: 0. (Params:). O erro é impresso em modo conciso porque houve erro durante a formatação. Rastreamento, ETW, notificações etc. são ignorados. 'dbo_TABLE_NAME', porque você não tem permissão.

Estou usando o SQL Server 2016 (v13.0.7045.2).

Em um servidor SQL 13.0.7029, conseguimos executar os comandos alter, então parece que algo mudou como parte de um patch.

O problema é semelhante a este aqui https://stackoverflow.com/questions/79075830/error-while-trying-to-alter-cdc-table-on-sql-server

Isso aconteceu em vários ambientes do nada e antes funcionava bem. Não tenho certeza se como parte de um novo patch algo mudou causando isso.

Sei que alterar tabelas cdc não é recomendado, mas isso não nos causou nenhum problema anteriormente.

Gostaria de saber se alguém tem alguma ideia sobre isso, pois não tenho muita certeza de como proceder.

Não tenho certeza se esse é um comportamento intencional ou um bug. Não há menção nos service packs da Microsoft de que eles fizeram algo para desabilitar a capacidade de adicionar uma coluna às tabelas.

Ainda mais se é assim que as coisas vão funcionar daqui para frente, precisamos nos ajustar adequadamente, mas agora não sei por que esse recurso parou de funcionar de repente.

Estou tentando conectar a um banco de dados do Azure usando SSMS v20.2 e Microsoft Entra MFA para autenticação. Quando clico em conectar, recebo a mensagem de erro abaixo:

Não foi possível carregar o arquivo ou assembly 'Azure.Core, Version=1.38.0.0, Culture=neutral, PublicKeyToken=92742159e12e44c8' ou uma de suas dependências. A definição de manifesto do assembly localizado não corresponde à referência do assembly. (Exceção de HRESULT: 0x80131040) (Framework Microsoft SqlClient Data Provider)

Consigo me conectar via Azure Data Studio, mas o SSMS está me dando problemas.

As soluções que estou encontrando online têm a ver com projetos no Visual Studio, o que não é o caso - é simplesmente eu tentando conectar. Tentei uma instalação de reparo, bem como desinstalar/reinstalar completamente o SSMS, sem sorte. Alguém encontrou esse problema e encontrou uma solução?

Estou executando o Postgresql 17 em um servidor RHEL 8.8 e quero conectar de um servidor de terminal remoto usando um cliente de banco de dados como o BeaverDB. No entanto, não consigo conectar (continuo recebendo uma "Conexão recusada: conectar" do cliente) e parece que isso ocorre porque não consigo fazer o servidor de banco de dados escutar endereços externos, conforme descrito na documentação do Postgresql:

1. Inicio o psql e determino o arquivo de configuração relevante usando o seguinte comando:

   select * from pg_settings where name = 'config_file';

2. Eu edito a linha relevante no arquivo de configuração de

   listen_addresses = 'localhost' para

   listen_addresses = '*'

e eu salvo e fecho o arquivo.

3. Eu reinicio o sistema de banco de dados usando

   sudo systemctl restart postgresql-17

mas também tentei reiniciar a máquina inteira.

4. Quando eu uso o psql novamente e digito

   select * from pg_settings where name = 'listen_addresses';

ainda diz localhost.

Sei que há vários outros tópicos com perguntas muito semelhantes, mas nenhum contém uma solução. O que estou fazendo errado aqui?

Há algum benefício de otimização (armazenamento/velocidade de consulta/...) ao escolher comprimentos específicos para colunas VARCHAR no PostgreSQL? Como, 2^n-1ou algo parecido?