Meu banco de dados tem muitas tabelas e muitas visualizações. Para uma das minhas tarefas, estou usando esta consulta. Quando executo a consulta a seguir, ela retorna toneladas de colunas - muitas das quais pertencem a tabelas e muitas pertencem a visualizações. Pergunta : Como podemos distinguir quais colunas são de tabelas e quais são de visualizações:
SELECT * FROM INFORMATION_SCHEMA.Columns
Observação : estou usando a versão mais recente do SQL Server 2022
Restaurei um banco de dados para um servidor SQL diferente, mas curiosamente as tabelas de backupset msdb neste servidor estão mostrando o histórico de backup do banco de dados do servidor de origem.
Isso é esperado?
Nota: não restaurei o msdb.
Passos para reproduzir:
Consulta:
SELECT
CONVERT(CHAR(100), SERVERPROPERTY('Servername')) AS Server,
msdb.dbo.backupset.database_name,
msdb.dbo.backupset.backup_start_date,
msdb.dbo.backupset.backup_finish_date,
msdb.dbo.backupset.expiration_date,
CASE msdb..backupset.type
WHEN 'D' THEN 'Database'
WHEN 'L' THEN 'Log'
END AS backup_type,
msdb.dbo.backupset.backup_size,
msdb.dbo.backupmediafamily.logical_device_name,
msdb.dbo.backupmediafamily.physical_device_name,
msdb.dbo.backupset.name AS backupset_name,
msdb.dbo.backupset.description
FROM
msdb.dbo.backupmediafamily
INNER JOIN msdb.dbo.backupset ON msdb.dbo.backupmediafamily.media_set_id = msdb.dbo.backupset.media_set_id
WHERE
(CONVERT(datetime, msdb.dbo.backupset.backup_start_date, 102) >= GETDATE() - 7)
ORDER BY
msdb.dbo.backupset.backup_finish_date desc
Ao fazer uma restauração de um grande banco de dados de 1,8 TB em um servidor diferente, me deparei com esta mensagem de erro quando a restauração estava cerca de 90% concluída:
90 por cento processado.
Msg 3013, Nível 16, Estado 1, Linha 52
RESTORE DATABASE está sendo encerrado de forma anormal.
Msg 1204, Nível 19, Estado 4, Linha 52
A instância do Mecanismo de Banco de Dados SQL Server não pode obter um recurso LOCK neste momento. Execute novamente seu extrato quando houver menos usuários ativos. Peça ao administrador do banco de dados para verificar a configuração de bloqueio e memória desta instância ou para verificar transações de longa execução.
SELECT [instance]=@@servername,[setting name]=name, value, value_in_use, [description]
FROM sys.configurations
where name in ('min server memory (MB)',
'min memory per query (KB)',
'max server memory (MB)',
'optimize for ad hoc workloads')
SELECT [instance]=@@servername,
cpu_count AS [Logical CPU Count],
hyperthread_ratio AS [Hyperthread Ratio],
cpu_count/hyperthread_ratio AS [Physical CPU Count],
CONVERT(decimal(12,2),physical_memory_kb/1024.00/1024.00) AS [Physical Memory (GB)],
affinity_type_desc,
virtual_machine_type_desc,
sqlserver_start_time
FROM sys.dm_os_sys_info WITH (NOLOCK)
usando isso para verificar o log de erros do sql, não consegui encontrar nenhuma indicação clara da causa do problema acima.
EXEC xp_readerrorlog 1
isso é o que eu encontrei:
Using dynamic lock allocation. Initial allocation of 2500 Lock blocks and 5000 Lock Owner blocks per node. This is an informational message only. No user action is required.
Node configuration: node 0: CPU mask: 0x000000000000000f:0 Active CPU mask: 0x000000000000000f:0. This message provides a description of the NUMA configuration for this computer. This is an informational message only. No user action is required.
o que fazer para permitir que minhas restaurações funcionem perfeitamente e não parem no meio?
Tenho uma coluna (varchar) que contém palavras separadas por '-'.
Exemplo de tabela:
| eu ia | lesma |
|---|---|
| 1 | nome1-nome2-nome3-nome4-nome5 |
| 2 | nome6-nome2-nome3-nome4-nome7 |
Qual a melhor forma de contar palavras e suas ocorrências?
Resultado esperado:
| palavra | contar |
|---|---|
| nome1 | 1 |
| nome2 | 2 |
| nome3 | 2 |
| nome4 | 2 |
| nome5 | 1 |
| nome6 | 1 |
| nome7 | 1 |
Tentei esta consulta, que funciona rápido em uma tabela com mais de 220 mil registros, mas não tenho certeza se esta é a correta (conta corretamente ou não)
SELECT
SUBSTRING_INDEX(slug,'-',-1) AS word,
count(SUBSTRING_INDEX(slug,'-',-1)) as count
FROM table_name
GROUP BY word
Os índices BRIN funcionam melhor (ou apenas) em tabelas onde os dados são agrupados em armazenamento físico.
Existe uma maneira de verificar isso de antemão, além de testar ou considerar a lógica que cria os dados?
No meu caso, suspeito que minha tabela esteja ordenada por ID do cliente, mas não tenho certeza se isso é consistente o suficiente.
Banco de dados: SQL Server, 2017.
Preciso impor certas regras de negócios em um gatilho. Agora, antes de me dizer para usar uma chave estrangeira, saiba que as regras são muito complicadas para serem aplicadas por chaves estrangeiras. Com isso resolvido, deixe-me ir ao cerne da minha pergunta:
Esta é a maneira correta de reverter/cancelar a inserção/atualização em um gatilho se uma regra de negócios for violada:
CREATE TRIGGER [dbo].[MyTestTrigger]
ON [dbo].[MyTestTable]
AFTER INSERT, UPDATE
AS
BEGIN
SET NOCOUNT ON;
IF TRIGGER_NESTLEVEL(OBJECT_ID('[dbo].[MyTestTrigger]')) > 1
BEGIN
RETURN;
END
if (condition_is_true) begin
;throw 51000, 'Bad data Message.',1;
end
end
Sei que minha pergunta parece simples, mas me deparei com esse " tratado " sobre tratamento de erros no SQL Server. Depois de folheá-lo, tive a impressão de que o tratamento de erros é extremamente complicado. Uma coisa que me deixa confuso é: preciso chamar explicitamente a rollbackinstrução antes/depois da throwinstrução? Ou ele throwpróprio reverterá a atualização/inserção. Dos meus testes, o throwpróprio reverte a atualização/inserção. No entanto, na própria documentação da Microsoft sobre gatilhos, a rollbackdeclaração está incluída:
USE AdventureWorks2022;
GO
IF OBJECT_ID ('Purchasing.LowCredit','TR') IS NOT NULL
DROP TRIGGER Purchasing.LowCredit;
GO
-- This trigger prevents a row from being inserted in the Purchasing.PurchaseOrderHeader table
-- when the credit rating of the specified vendor is set to 5 (below average).
CREATE TRIGGER Purchasing.LowCredit ON Purchasing.PurchaseOrderHeader
AFTER INSERT
AS
IF (ROWCOUNT_BIG() = 0)
RETURN;
IF EXISTS (SELECT 1
FROM inserted AS i
JOIN Purchasing.Vendor AS v
ON v.BusinessEntityID = i.VendorID
WHERE v.CreditRating = 5
)
BEGIN
RAISERROR ('A vendor''s credit rating is too low to accept new
purchase orders.', 16, 1);
ROLLBACK TRANSACTION;
RETURN
END;
A inclusão de é rollbackrealmente necessária?
Tenho mais uma questão conceitual. Existe uma maneira de modelar o seguinte:
CREATE TABLE AssetPair (
older_asset_id INT8,
newer_asset_id INT8,
PRIMARY KEY (older_asset_id, '-', newer_asset_id)
);
Meu problema é que older_asset_idestamos newer_asset_idincrementando IDs para que os seguintes casos sejam possíveis:
older_asset_id: 1, newer_asset_id: 234 --> PrimaryKey:1234
// same Primary keys
older_asset_id: 12 newer_asset_id: 34 --> PrimaryKey:1234
Se eu conseguisse inserir um hífen entre as duas colunas, conseguiria evitar esse problema. Alguma ideia?
Atualmente estou dando uma olhada no Pro SQL Server 2019 Administration: A Guide for the Modern DBA e descobri uma coisa que me confunde um pouco.
No Capítulo 5: CONFIGURANDO A INSTÂNCIA , a seção Memória mínima e máxima do servidor (páginas 139-140) diz:
Em muitos ambientes, é provável que você deseje fornecer o mesmo valor para memória mínima e máxima do servidor. Isso evitará a sobrecarga do SQL Server gerenciando dinamicamente a quantidade de memória reservada.
No entanto, se você tiver várias instâncias, o gerenciamento dinâmico de memória poderá ser benéfico para que a instância com a carga de trabalho mais pesada em um determinado momento possa consumir mais recursos.
... Supondo que você tenha uma instância e nenhum outro aplicativo, como pacotes SSIS, em execução no servidor, normalmente você definiria as configurações de memória mínima e máxima como o valor mais baixo do
- RAM - 2 GB
- (RAM / 8) * 7
No entanto, o conselho para " fornecer o mesmo valor para memória mínima e máxima do servidor " está em contradição com a documentação , que diz:
Não é recomendado definir a memória máxima do servidor (MB) e a memória mínima do servidor (MB) como o mesmo valor ou próximo dos mesmos valores.
Em que situações seria uma boa ideia definir a memória máxima do servidor e a memória mínima do servidor com o mesmo valor (ish)?
Ou estou entendendo mal alguma coisa sobre o conselho?
Estou executando uma instrução select em uma tabela postgresql (em uma instância RDS) para somar valores em 2 mil linhas. A instrução select tem cerca de 100 parâmetros (principalmente países diferentes que queremos somar).
Quando executo essa consulta uma vez em meu aplicativo, ela será executada em aproximadamente 500 ms. No entanto, quando eu o executo várias vezes seguidas, a latência da consulta aumenta repentinamente de 10 a 20 vezes , para aproximadamente 5 a 10 segundos após 8 ou 9 execuções. (Essas medições são do lado do servidor dos logs RDS onde eu habilitei log_min_duration_statement).
O que poderia causar esse salto no tempo de execução? - Eu esperaria que a consulta fosse mais lenta na execução inicial, mas estou surpreso ao ver a latência aumentar após várias execuções consecutivas.
Algumas observações importantes:
psqlpara executá-la.Tentei procurar os suspeitos do costume, como otimização do RDS IOPS Burst, carga do banco de dados e consumo de memória, conexões disponíveis, mas nada parece suspeito nesse aspecto.
Também me certifiquei de que o índice que a consulta está usando e as linhas retornadas da tabela sejam armazenadas em cache.
A consulta que estou executando tem o seguinte formato. Trunquei alguns dos 90 IDs de países:
SELECT d.primary_title_no,
SUM(d.cume) AS lifetime
FROM schema.my_data AS d
WHERE d.currency = 'USD'
AND d.date >= '2020-01-01'::date + (7 * (d.week - 1))
AND d.date < '2021-01-01'::date + (7 * (d.week - 1))
AND d.is_lifetime = TRUE
AND d.ter_id IN ('AE','AM', ... (100 odd values) ...,'WA','ZA')
GROUP BY d.primary_title_no
ORDER BY lifetime DESC
LIMIT 250;
É importante ressaltar que esse problema só acontece quando a consulta tem mais de 90 IDs de países. Posso executá-lo em 50 países sem problemas.
Para referência, aqui está o resultado de explain analyzeuma consulta com um tempo de execução rápido:
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| QUERY PLAN |
|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Limit (cost=1218692.98..1218693.23 rows=100 width=12) (actual time=369.146..369.167 rows=100 loops=1) |
| -> Sort (cost=1218692.98..1218697.34 rows=1742 width=12) (actual time=369.145..369.154 rows=100 loops=1) |
| Sort Key: (sum(cume)) DESC |
| Sort Method: top-N heapsort Memory: 33kB |
| -> GroupAggregate (cost=1218595.34..1218626.41 rows=1742 width=12) (actual time=366.250..368.653 rows=1959 loops=1) |
| Group Key: primary_title_no |
| -> Sort (cost=1218595.34..1218599.89 rows=1820 width=12) (actual time=366.240..366.844 rows=5739 loops=1) |
| Sort Key: primary_title_no |
| Sort Method: quicksort Memory: 462kB |
| -> Index Scan using idx_dailies_currency_ter_id_primary_title_no_lifetime on dailies d (cost=0.43..1218496.79 rows=1820 width=12) (actual time=1.093..364.406 rows=5739 loops=1) |
| Index Cond: (((currency)::text = 'USD'::text) AND ((ter_id)::text = ANY ('{AE,AM,AR,AT,AU,AZ,BA,BE,BG,BH,BO,BR,BY,CH,CL,CN,CO,CR,CU,CZ,DE,DK,DO,EC,EE,EG,ES,FI,FR,GE,GR,GT,HK,HN,HR,HU,IL,IN,IQ,IS,IT,JP,KG,KR,KW,KZ,LB,LT,LU,LV,MD,MX,MY,MZ,NI,NL,NO,NZ,OM,PA,PE,PH,PL,PT,PY,QA,RO,RS,RU,SA,SE,SG,SI,SK,SV,TH,TJ,TM,TR,TT,TW,UK,UP,UY,UZ,WA,ZA}'::text[]))) |
| Filter: (((date - (7 * (week - 1))) >= '2020-01-01'::date) AND ((date - (7 * (week - 1))) < '2020-06-01'::date)) |
| Rows Removed by Filter: 314494 |
| Planning Time: 0.613 ms |
| Execution Time: 369.213 ms |
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
Para um caso em que a consulta é executada lentamente, a explain analyzesaída é a mesma, mas 20 vezes o cálculo é gasto na Index Scanetapa mais interna.
Se alguém tiver alguma indicação de como posso solucionar esse problema, serei todo ouvidos.
Estou trabalhando com algumas tabelas em um banco de dados SQL-Server e fazendo algumas modificações cruciais. Para não perder tudo quando errar, resolvi fazer um "Gerar script" (somente dados, estou trabalhando com Microsoft SQL Server Management Studio), então agora tenho vários comandos SQL "INSERT", como :
INSERT [dbo].[User_Group_Access] ([Visible], [GroupId], [Enabled], [ControlId], [Administrator]) VALUES (0, 26, 0, 181, 0)
INSERT [dbo].[User_Group_Access] ([Visible], [GroupId], [Enabled], [ControlId], [Administrator]) VALUES (0, 26, 0, 182, 0)
Ops, fiz algo errado.
Não tem problema, pensei. Basta substituir INSERTe UPDATEpronto, mas isso não parece tão simples: procurando esta questão no StackOverflow, há discussões inteiras sobre transações, diferentes tecnologias de banco de dados, ...
Ok, o UPDATEcomando não funciona.
Mas deveria haver algum outro comando ( REPLACEnão funciona, SUBSTITUTEnão existe como comando), não é?
Alguém tem uma ideia?
desde já, obrigado