我的数据库有很多表和很多视图。对于我的一项任务,我正在使用此查询。当我运行以下查询时,它返回大量列 - 其中许多属于表,许多属于视图。问题:我们如何区分哪些列来自表,哪些列来自视图:
SELECT * FROM INFORMATION_SCHEMA.Columns
备注:我使用的是最新版本的 SQL Server 2022
我的数据库有很多表和很多视图。对于我的一项任务,我正在使用此查询。当我运行以下查询时,它返回大量列 - 其中许多属于表,许多属于视图。问题:我们如何区分哪些列来自表,哪些列来自视图:
SELECT * FROM INFORMATION_SCHEMA.Columns
备注:我使用的是最新版本的 SQL Server 2022
我将数据库恢复到不同的 SQL 服务器,但有趣的是,该服务器上的 msdb 备份集表显示了源服务器的数据库备份历史记录。
这是预期的吗?
注意:我没有恢复msdb。
重现步骤:
询问:
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
在将 1.8 TB 大型数据库恢复到另一台服务器时,当恢复完成大约 90% 时,我遇到了此错误消息:
90%已处理完毕。
消息 3013,级别 16,状态 1,第 52 行
RESTORE DATABASE 异常终止。
消息 1204,级别 19,状态 4,第 52 行
SQL Server 数据库引擎实例此时无法获取 LOCK 资源。当活跃用户较少时重新运行您的语句。要求数据库管理员检查该实例的锁和内存配置,或者检查长时间运行的事务。
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)
用它来检查sql错误日志,我找不到任何明确的迹象表明上述原因。
EXEC xp_readerrorlog 1
这是我发现的:
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.
怎样做才能让我的恢复彻底进行而不是中途停止?
我有一个列(varchar),其中包含用“-”分隔的单词。
表示例:
ID | 蛞蝓 |
---|---|
1 | 姓名1-姓名2-姓名3-姓名4-姓名5 |
2 | 姓名6-姓名2-姓名3-姓名4-姓名7 |
计算单词及其出现次数的最佳方法是什么?
预期结果:
单词 | 数数 |
---|---|
姓名1 | 1 |
姓名2 | 2 |
姓名3 | 2 |
姓名4 | 2 |
姓名5 | 1 |
姓名6 | 1 |
姓名7 | 1 |
我尝试了这个查询,它在包含超过 22 万条记录的表上运行速度很快,但不确定这是否正确(计数正确与否)
SELECT
SUBSTRING_INDEX(slug,'-',-1) AS word,
count(SUBSTRING_INDEX(slug,'-',-1)) as count
FROM table_name
GROUP BY word
BRIN 索引在数据在物理存储中捆绑在一起的表上效果最好(或仅)。
除了测试或考虑创建数据的逻辑之外,有没有办法提前检查这一点?
就我而言,我怀疑我的表是根据客户端 ID 排序的,但我不确定这是否足够一致。
数据库:SQL Server,2017。
我需要在触发器中强制执行某些业务规则。现在,在您告诉我使用外键之前,请知道规则太复杂,无法通过外键执行。说完这些,让我开始回答我的问题:
如果违反业务规则,这是回滚/取消触发器中的插入/更新的正确方法吗:
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
我知道我的问题看起来很简单,但我偶然发现了这篇关于SQL Server 错误处理的“论文”。浏览完之后,我的印象是错误处理非常复杂。我感到困惑的一件事是,我是否需要rollback
在语句之前/之后显式调用该throw
语句?或者throw
本身会回滚更新/插入。根据我的测试,它throw
本身会回滚更新/插入。然而,在微软自己关于触发器的文档中,rollback
包含这样的语句:
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;
纳入rollback
真的有必要吗?
我有更多概念性问题。有没有办法模拟以下内容:
CREATE TABLE AssetPair (
older_asset_id INT8,
newer_asset_id INT8,
PRIMARY KEY (older_asset_id, '-', newer_asset_id)
);
我的问题是,older_asset_id
并且newer_asset_id
正在增加 ID,因此可能出现以下边缘情况:
older_asset_id: 1, newer_asset_id: 234 --> PrimaryKey:1234
// same Primary keys
older_asset_id: 12 newer_asset_id: 34 --> PrimaryKey:1234
如果我能够在两列之间插入连字符,我就能够避免这个问题。有什么想法吗?
我目前正在浏览《Pro SQL Server 2019 管理:现代 DBA 指南》,发现一件事让我有些困惑。
在第 5 章:配置实例中,有关最小和最大服务器内存的部分(第 139-140 页)说:
在许多环境中,您可能希望为最小和最大服务器内存提供相同的值。这将避免 SQL Server 动态管理其保留的内存量的开销。
但是,如果您有多个实例,则动态内存管理可能会有所帮助,以便在任何给定时间具有最重工作负载的实例可以消耗最多的资源。
...假设您有一个实例并且没有其他应用程序(例如 SSIS 包)在服务器上运行,您通常会将最小和最大内存设置设置为
- 内存 - 2 GB
- (内存/8)* 7
然而,“为最小和最大服务器内存提供相同的值”的建议与文档相矛盾,文档说:
不建议将最大服务器内存 (MB) 和最小服务器内存 (MB) 设置为相同或接近相同的值。
在什么情况下最好将最大服务器内存和最小服务器内存设置为相同的值?
或者我对建议有什么误解?
我正在 postgresql 表(在 RDS 实例上)上运行 select 语句,以便对 200 万行中的值进行求和。select 语句有大约 100 个参数(主要是我们想要求和的不同国家/地区)。
当我从应用程序运行此查询一次时,它将在大约 500 毫秒内执行。然而,当我连续执行几次时,查询延迟会在运行 8 或 9 次后突然增加10-20 倍,达到大约 5 到 10 秒。(这些测量是来自我启用的 RDS 日志的服务器端log_min_duration_statement
)。
什么可能导致执行时间的跳跃?-- 我预计查询在初次运行时会变慢,但我惊讶地发现在几次连续运行后延迟会增加。
一些关键的观察结果:
psql
。我尝试寻找常见的可疑点,例如 RDS IOPS 突发限制、数据库负载、内存消耗、可用连接,但在这方面看起来没有任何可疑之处。
我还确保查询正在使用的索引和从表返回的行被缓存。
我正在运行的查询具有以下形状。我截断了 90 个国家/地区 ID 中的一些:
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;
重要的是,只有当查询具有 90 多个国家/地区 ID 时,才会出现此问题。我可以毫无问题地在 50 个国家/地区运行它。
explain analyze
作为参考,以下是执行时间较快的查询的输出:
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 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 |
+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
对于查询执行缓慢的情况,explain analyze
输出是相同的,但最里面的Index Scan
步骤花费了 20 倍的计算量。
如果有人对我如何解决这个问题有任何指示,我会洗耳恭听。
我正在处理 SQL-Server 数据库中的一些表,并且正在进行一些重要的修改。为了在搞砸时不丢失所有内容,我决定执行“生成脚本”(仅数据,我正在使用 Microsoft SQL Server Management Studio),所以现在我有一堆 SQL“INSERT”命令,例如:
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)
哎呀,我做错事了。
没问题,我想。只需替换INSERT
即可UPDATE
,但这似乎并不那么简单:在 StackOverflow 上查找这个问题,有关于事务、不同数据库技术的完整讨论,...
好吧,该UPDATE
命令不起作用。
但是应该还有其他命令(REPLACE
不起作用,SUBSTITUTE
不作为命令存在),不是吗?
有人有想法吗?
提前致谢