数据库管理员

希望提高数据库技能并向社区中的其他人学习的数据库专业人员的问答

3
在非持久计算列SQL Server上创建非聚集索引
我正在努力寻找有关SQL Server如何实际存储非持久计算列的任何文档。 请看以下示例： --SCHEMA CREATE TABLE dbo.Invoice ( InvoiceID INT IDENTITY(1, 1) PRIMARY KEY, CustomerID INT FOREIGN KEY REFERENCES dbo.Customer(CustomerID), InvoiceStatus NVARCHAR(50) NOT NULL, InvoiceStatusID AS CASE InvoiceStatus WHEN 'Sent' THEN 1 WHEN 'Complete' THEN 2 WHEN 'Received' THEN 3 END ) GO --INDEX CREATE NONCLUSTERED INDEX IX_Invoice ON Invoice …
1
使用跨数据库证书时触发器中的权限
我使用跨数据库证书（如Erland Sommarskog所述）来控制对环境（SQL Server 2008 R2）中某个数据库的访问。 我已经在数据库A中存储了更新数据库B中表的存储过程。到目前为止，这一直适用于db A中的各种存储过程以及db B中的表。我正在尝试更新数据库B中的表，但是该表上有一个触发器。此触发器正在将附加数据插入db B中的另一个表中。 消息916，级别14，状态1，过程table_trigger，第11行在当前安全性上下文下，服务器主体“ sql \ login”无法访问数据库“ B”。 我尝试授予与证书绑定的数据库B用户的插入权限，以将其插入到该其他表中，但是它无法解决该错误。除了更改触发器以便使用之外，我还有其他选择WITH EXECUTE AS OWNER吗？ 这是DDL复制问题： CREATE LOGIN [GuggTest] WITH PASSWORD=N'abcd', DEFAULT_DATABASE=[master], CHECK_EXPIRATION=OFF, CHECK_POLICY=OFF CREATE DATABASE A; CREATE DATABASE B; USE A; CREATE TABLE dbo.SPtoUpdate ( ID INT , ILoveFishing VARCHAR(255) ); INSERT INTO dbo.SPtoUpdate ( ID …
3
非IT人员的数据库登台环境
我正在向我的IT部门建议一个数据库登台环境。这个想法是，像我这样的非IT人员（公共工程数据分析师）将有一个测试解决方案的地方，然后自己在实际环境中实施解决方案，或者在需要时要求IT部门实施解决方案。有几种原因/场景可以使该环境受益： 在我们的实时数据库环境（，等）中create table，我具有一些基本的数据库特权create view。我大约每周进行一次模式更改，但是在实时环境中测试和实现这些更改似乎很疯狂。数据库上有无数的依赖关系，因此，如果出现问题，可能会造成灾难性的后果。我宁愿提前在单独的环境中进行测试。 我没有一些更高级的特权，如create trigger或create function在现场数据库。很好，但是我确实有一些可以通过触发器和/或函数解决的问题。我计划建议在登台环境中向我授予这些权限，以便我可以开发和测试一些想法，如果它们起作用，则建议IT在实时环境中实施它们。 通常，我的IT部门没有时间或资源为我开发解决方案。真的就是这么简单。因此，如果我可以自己做腿部工作，那么我的问题就更有可能得到解决。 “非IT人员的暂存环境”对我来说似乎是一种足够合理的方法，但是老实说，我只是想出了办法。我不知道在IT /数据库世界中通常是如何完成的。 是否有适合这种情况的已建立的IT /数据库实践？（为非IT人员提议数据库登台环境时，我走的路正确吗？）
3
使用MAXTRANSFERSIZE和CHECKSUM时，无法还原启用TDE的数据库
更新：@AmitBanerjee -Microsoft SQL Server产品组的高级程序经理，确认MS将调查此问题，因为它是缺陷。 有没有人遇到在启用TDE并使用MAXTRANSFERSIZE> 65536的情况下还原在SQL Server 2016上进行的备份的问题（对于我而言，我选择了65537，以便可以压缩TDE数据库）和CHECKSUM？ 下面是一个副本： --- create database create database test_restore go -- create table create table test_kin (fname char(10)) go -- Enable TDE use master GO CREATE CERTIFICATE test_restore WITH SUBJECT = 'test_restore_cert' GO SELECT name, pvt_key_encryption_type_desc, * FROM sys.certificates WHERE name = 'test_restore' GO …
4
根据另一列重置运行总计
我正在尝试计算运行总计。但是，当累积总和大于另一个列的值时，应该重置 create table #reset_runn_total ( id int identity(1,1), val int, reset_val int, grp int ) insert into #reset_runn_total values (1,10,1), (8,12,1),(6,14,1),(5,10,1),(6,13,1),(3,11,1),(9,8,1),(10,12,1) SELECT Row_number()OVER(partition BY grp ORDER BY id)AS rn,* INTO #test FROM #reset_runn_total 索引详细信息： CREATE UNIQUE CLUSTERED INDEX ix_load_reset_runn_total ON #test(rn, grp) 样本数据 +----+-----+-----------+-----+ | id | val | reset_val …
1
使用COALESCE将主键从IDENTITY更改为持久计算列
为了使应用程序与整体数据库脱钩，我们尝试将各种表的INT IDENTITY列更改为使用COALESCE的PERSISTED计算列。基本上，我们需要分离的应用程序能够为许多应用程序之间共享的通用数据更新数据库，同时仍允许现有应用程序在这些表中创建数据而无需修改代码或过程。 因此，从本质上讲，我们已经脱离了的列定义； PkId INT IDENTITY(1,1) PRIMARY KEY 至; PkId AS AS COALESCE(old_id, external_id, new_id) PERSISTED NOT NULL, old_id INT NULL, -- Values here are from existing records of PkId before table change external_id INT NULL, new_id INT IDENTITY(2000000,1) NOT NULL 在所有情况下，PkId也是主键，在除一种情况以外的所有情况下，它都是聚集的。所有表都具有与以前相同的外键和索引。本质上，新格式允许由解耦的应用程序提供PkId（作为external_id），但也允许PkId作为IDENTITY列值，因此允许通过使用SCOPE_IDENTITY和@@ IDENTITY依赖于IDENTITY列的现有代码照常工作。 我们遇到的问题是，我们遇到了一些查询，这些查询过​​去可以在可接受的时间内运行，现在已经完全崩溃了。这些查询使用的生成查询计划与以前不同。 鉴于新列是PRIMARY KEY，数据类型与以前相同，并且为PERSISTED，因此我希望查询和查询计划的行为与之前相同。就SQL Server如何生成执行计划而言，COMPUTED PERSISTED INT PkId是否应在本质上与显式INT定义具有相同的行为？您还可以看到这种方法还有其他可能的问题吗？ …
3
指定的网络名称不再可用
我们有一个访问数据库的应用程序（SQL Server 2014企业版）。该应用程序调用存储过程来访问数据库。一切运行良好，直到最近开始发送以下错误并停止应用程序。重新启动应用程序可以暂时解决此问题，但稍后会遇到相同的错误。 错误：从服务器接收结果时发生传输级错误。（提供程序：TCP提供程序，错误：0-指定的网络名称不再可用。） 我进行了很多研究，其中大多数人指出这是网络问题，但找不到任何能真正解决问题的方法。有谁知道我应该在数据库方面进行哪些更改才能解决此问题。我非常感谢任何建议。
1
SQL Server-为什么更新语句中不允许使用窗口函数？
运行更新语句（例如下面的语句）时，我收到一条错误消息，告诉我 窗口函数只能出现在SELECT或ORDER BY子句中。 UPDATE dbo.Dim_Chart_of_Account SET Account_Order = LAG([Account_Order]) OVER (ORDER BY [Account_SKey]) 我知道可以使用可更新的CTE轻松解决此问题，如下所示 WITH my_cte AS ( SELECT [Account_Order], LAG([Account_Order]) OVER (ORDER BY [Account_SKey]) AS acc_order_lag FROM Dim_Chart_of_Account ) UPDATE my_cte SET [Account_Order] = acc_order_lag 我的问题是，是否有任何原因为什么不允许在更新语句中使用此方法，我应该避免使用可更新的CTE作为解决方法吗？ 我担心的是，将窗口函数与更新语句一起使用时会出现问题，因此，我想了解这是一种可接受的方法还是应该避免。
3
关系数据库中的完整性约束-我们应该忽略它们吗？
我正在与我工作的公司的开发人员进行永久性讨论，因为他们说最好摆脱关系数据库中的关系强制（通过FOREIGN KEY约束定义），以便加快大型查询并获得更好的结果。性能。 所考虑的平台是MySQL 5.x，并且尚未设置FOREIGN KEY，甚至缺少相关表的一些PRIMARY KEY约束，至少对于我来说，这是不合理的。也许他们是对的，但我是错的，但我没有足够的论点来讨论这种情况。 三年来，这一直是首选方法。我是这家公司的新手（只有一个月），但是随着产品的“上市”，人们在犹豫是否要增强数据库。话说回来，我注意到的第一件事是一页需要1分钟的加载时间（是的，需要60秒！）。 当前事务状态背后的一种说法是，“非规范化”数据库比规范化数据库要快，但我认为那不是真的。 大多数相关查询都包含JOIN操作，这使它们在处理大量数据（数据库包含数百万行）时非常非常非常慢地运行。 通常，“ CRUD”操作的处理是在应用程序代码级别实现的；例如，为了删除一些数据自，例如TableA： 必须首先即时检查TableA和的行之间是否存在某种关系TableB， 如果上述关系被“检测到”，则应用程序代码将不允许删除相关行，但是 如果由于某种原因该应用程序代码失败，则无论涉及的行和表是否存在任何关系，DELETE操作都将“成功”进行。 题 您能帮我拟定一个良好，准确而可靠的答案以丰富辩论的内容吗？ 注意：也许以前有人问过（并回答过）类似的问题，但是我无法通过Google找到任何东西。
3
为什么将自动更新统计信息设置为False？
作为更广泛的收购项目的一部分，我刚刚继承了大约20个SQL Server实例。我正在评估性能，我不喜欢实施维护计划的方式。 我看到每天进行一揽子索引重建（我可以处理这一问题），并且每天都在手动更新统计信息。 大约一半的数据库已设置为“自动更新统计信息= False”，原因除了我被告知要减少“性能问题”外，其他原因还不清楚。 我一直认为并努力将其设置为True的最佳实践，并认为如果此设置为True，则不需要手动更新。我错了吗？ 谁能解释一下将此设置为False会有什么好处，但是每天进行一次手动更新呢？ 我应该提到，某些数据库具有很高的事务性（每天有数以百万计的插入，删除，更新），而其他数据库的事务处理率很低，而有些则全部是只读的。尽管没有任何韵律或原因，但关于“自动更新”设置为“否”的信息。好像是彩票。
2
SQL Server示例统计信息更新在升序键列上错过最高的RANGE_HI_KEY
我正在尝试了解统计信息采样的工作原理，以及以下是否是采样统计信息更新的预期行为。 我们有一个按日期划分的大型表，其中有数十亿行。分区日期是先前的业务日期，因此是升序键。我们仅将前一天的数据加载到该表中。 数据加载会在一夜之间进行，因此在4月8日（星期五），我们加载了7月7日的数据。 每次运行后，我们都会更新统计信息，尽管需要抽样，而不是FULLSCAN。 也许我很天真，但我希望SQL Server能够确定范围内的最高键和最低键，以确保获得准确的范围样本。根据这篇文章： 对于第一个存储桶，下边界是生成直方图的列的最小值。 但是，它没有提及最后一个存储桶/最大值。 由于采样的统计信息是在8日上午更新的，因此该样本未达到表格（第7位）中的最高值。 由于我们对前一天的数据进行了很多查询，因此导致基数估计不准确，并且许多查询超时。 SQL Server是否应该不标识该键的最大值并将其用作最大值RANGE_HI_KEY？还是这仅仅是不使用更新的限制之一FULLSCAN？ 版本SQL Server 2012 SP2-CU7。由于OPENQUERYSP3 中行为的变化，即四舍五入到SQL Server和Oracle之间的链接服务器查询中的数字，我们当前无法升级。
3
在PostgreSQL中为不能为null的字段不指定NOT NULL有什么后果？
我有一个应用程序（数据存储在PostgreSQL中），其中表中的大多数字段始终不为null，但是这些表的架构并未强制执行此操作。例如看这个假表： CREATE TABLE "tbl" ( "id" serial, "name" varchar(40), "num" int, "time" timestamp PRIMARY KEY ("id"), UNIQUE ("id") ); 此外name，num，time没有明确提及的NOT NULL，在现实中是这样，因为执行发生在应用端。 我的感觉是应该对其进行更改，但相反的是，应用程序级别确保此处不会出现空值，并且没有其他人手动修改该表。 我的问题是：通过设置显式NOT NULL约束？ 我们拥有一个良好的代码审查流程和一个相当不错的文档，因此，某些新人提交的东西可能会破坏此约束，这实际上不足以证明更改是正确的。 这不是我的决定，所以这正是我在寻找其他理由的原因。我认为，如果某些内容不能为null，并且数据库允许您指定某些内容不为null，则只需执行此操作即可。特别是如果更改非常简单。
2
SQL Server不使用所有内存
我有SQL Server 2014，最大内存设置为6GB（物理内存为8GB）。 在目标服务器内存为6GB，有时，然后回落到总的服务器内存（约5.3GB，从未达到6GB）。我用committed_kb在sys.dm_os_sys_info检查SQL Server所使用的内存。 当我监视sys.dm_os_buffer_descriptors时，我看到页面已从缓存中删除-但仍然有700MB的内存。如果什么都不需要内存，您将如何解释从缓存中删除页面的事实？我希望SQL Server仅在需要内存时才删除页面。 在此服务器上，解除分配的临时表不是问题。我的PLE是3632。过程高速缓存是2182 MB。 我希望只有没有可用的内存时，页面才会被丢弃，但是我有700MB的可用空间，还是我误会了这一点？ 有人可以尝试解释这种行为吗？ SQL Server也在从磁盘读取数据，因此我想我可以得出结论，并非所有需要的页面都在内存中。 我进行了一些进一步的研究，并从磁盘将大量页面读取到内存中，并在读取过程中注意到taskmanager中的某些内容： 正在使用的内存从7.0GB-> 7.2GB-> 7.0GB-> 7.2GB-> ... Sqlservr.exe从5.3GB-> 5.5GB-> 5.3GB-> 5.5GB-> ... 就像Windows不允许sqlservr.exe增长到6GB一样。 我运行了Shanky提供的查询： select (physical_memory_in_use_kb/1024) Physical_Memory_usedby_Sqlserver_MB, (locked_page_allocations_kb/1024 )Locked_pages_used_Sqlserver_MB, (Virtual_address_committed_kb/1024 )Total_Memory_in_MB,--RAM+ Pagefile process_physical_memory_low, process_virtual_memory_low from sys. dm_os_process_memory 得到以下结果： Physical_Memory_usedby_Sqlserver_MB: 5247 Locked_pages_used_Sqlserver_MB: 0 Total_Memory_in_MB: 5625 process_physical_memory_low: 0 process_virtual_memory_low: 0 …
1
内存表的性能比基于磁盘的表差
我在SQL Server 2014中有一个表，如下所示： CREATE TABLE dbo.MyTable ( [id1] [bigint] NOT NULL, [id2] [bigint] NOT NULL, [col1] [int] NOT NULL default(0), [col2] [int] NOT NULL default(0) ) （id1，id2）是PK。基本上，id1是将一组结果（id2，col1，col2）分组的标识符，其pk为id2。 我正在尝试使用内存表来摆脱现有的基于磁盘的表，这是我的瓶颈。 表中的数据被写入->读取->删除一次。 每个id1值都有数千个id2（成百上千）。 数据在表中存储的时间非常短，例如20秒。 在此表上执行的查询如下： -- INSERT (can vary from 10s to 10,000s of records): INSERT INTO MyTable SELECT @fixedValue, id2, col1, col2 …
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.