数据库管理员

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

3
将行旋转为多列
我有一个SQL Server实例，该实例具有一个链接服务器到Oracle服务器。Oracle服务器上有一个名为的表，PersonOptions其中包含以下数据： ╔══════════╦══════════╗ ║ PersonID ║ OptionID ║ ╠══════════╬══════════╣ ║ 1 ║ A ║ ║ 1 ║ B ║ ║ 2 ║ C ║ ║ 3 ║ B ║ ║ 4 ║ A ║ ║ 4 ║ C ║ ╚══════════╩══════════╝ 我需要透视这些数据，因此结果是： ╔══════════╦═════════╦══════════╦══════════╗ ║ PersonID ║ OptionA ║ Option B ║ …
1
SQL Server-是否有人使用SUMA，跟踪标志8048或跟踪标志8015？
最近包括SQL Server启动跟踪标记8048，以解决SQL Server 2008 R2系统中的严重自旋锁争用问题。 希望听到其他人发现使用情况的情况，其中使用情况是通过跟踪标志8048（将查询内存授予策略从每个NUMA节点升级到每个核），跟踪标志8015（SQL Server忽略物理NUMA）或SUMA（交错访问足够均匀的内存（在某些NUMA计算机上为BIOS选项）。 跟踪标记8048 http://blogs.msdn.com/b/psssql/archive/2011/09/01/sql-server-2008-2008-r2-on-newer-machines-with-more-than-8-cpus每个数字节点可能需要跟踪标志-8048.aspx 跟踪标记8015 http://blogs.msdn.com/b/psssql/archive/2010/04/02/how-it-works-soft-numa-io-completion-thread-lazy-writer-workers-and-memory -nodes.aspx 详细的系统工作负载，从出现问题的系统收集的指标以及在干预后从系统收集的指标。 跟踪标志8048是一个“修复程序”，但这是最好的修复程序吗？由于跟踪标志8015，SQL Server忽略物理NUMA会完成相同的事情吗？如何将BIOS设置为交错内存，使服务器具有模仿SMP的SUMA行为而不是NUMA行为？ 和平！tw：@sql_handle 关于系统：-4个六核Xeon E7540 @ 2.00GHz，超线程-128 GB RAM-WS2008R2-MSSQL 2008 R2 SP2-maxdop 6 关于工作负载：-由2个报表应用程序服务器驱动的1000个批处理计划/排队报表。-3种批次：每天，每周，每月-与SQL Server的所有报表应用程序服务器连接均作为单个服务帐户进行-报表并发最大数= 90 故障系统的主要发现：-从Perfmon开始，间隔为15秒--系统保持95％-100％的CPU繁忙--SQL Server缓冲区页面查找<10000次/秒 从等待和自旋锁DMV开始，间隔5分钟 高CMEMTHREAD服务员和等待时间 SOS_SUSPEND_QUEUE高旋转和后退 鲍勃·多尔（Bob Dorr）在跟踪标记8048上的CSS工程师博客文章中指出，由于查询内存授予的瓶颈，每个NUMA节点具有8个以上内核的系统可能会遇到类似的症状。跟踪标志8048会将策略更改为每个核心而不是每个NUMA节点。 干预 使用-T8048重新启动MSSQL。区别立即显而易见：缓冲区页面查找率上升到100万以上，每秒达到800万。麻烦的批处理工作负载以前不到24小时就无法完成，而不到4小时就可以完成。提交了不是调查或干预重点的另一批工作量，作为验证跟踪标志8048的校正值的一部分（并确保其不必要的副作用最小）。该报告批处理先前在2小时内完成；带有跟踪标记8048的报告批处理大约在20分钟内完成。 每晚ETL也遇到了好处。ETL时间从大约60分钟减少到40分钟。 从多个地方收集信息，我推测报告排队的程度很高，并发报告计数大于硬件线程计数，并且所有用户的单一用户帐户组合在一起给一个NUMA节点施加了压力，直到工作线程压力导致它对于同一个用户帐户的下一个传入连接请求不利，此时下一个NUMA节点将立即获得一定数量的连接。每个NUMA节点最终都有很大可能强调查询内存授予瓶颈。 为查询内存授权打开更多通道消除了瓶颈。但是，我不确定费用。鲍伯·多尔（Bob Dorr）的CSS帖子清楚地表明，带有跟踪标志8048的其他内存开销。单页分配器区域内的开销是否受MSSQL 2008 R2最大服务器内存控制？如果是这样，我猜想系统在缓冲池缓存中将只少一些数据库页面。如果没有，应该降低最大服务器内存来容纳吗？
1
努力调试Amazon RDS MySQL实例上的高CPU使用率
我们正在运行m1.xlarge MySQL RDS服务器，并且在CPU使用率较高方面存在一些问题。几周前，我们遇到了一些问题，大型实例上的CPU利用率达到了100％。当我们将大小升级到xlarge时，可以稳定一段时间，但CPU使用率逐渐上升。 在过去一周左右的时间里，CPU利用率一直处于90年代的最高水平，昨天一直稳定地达到100％左右，这使我们的生产基地停顿了下来。重新引导数据库服务器后，几个小时内CPU使用率又恢复到相同的水平。 我已经在mysql服务器上运行了show processlist，并一直通过MySQL admin进行监视。似乎也没有特别长时间运行的查询或大量查询。有两个进程长时间处于睡眠状态……这些是在我们的主应用程序外部运行的与数据库通信的隔离工作程序守护程序。我在下面的过程列表输出中复制了服务器名称，以对其进行描述： +------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+ | Id | User | Host | db | Command | Time | State | Info | +------+----------+---------------------------------------------------+--------------+---------+-------+--------------+----------------------------------------------------------------------------------------+ | 13 | rdsadmin | localhost:43513 | mysql | Sleep | 14 | | NULL | | 15 | proddbuser | app-server-1.eu-west-1.compute.internal:36460 | proddb …
21 mysql 
3
SQL Server数据库同步
问题定义 我们的用户需要具有查询最新数据库的能力。数据最多可以保留24小时，这是可以接受的。用生产副本获取和保持第二个数据库的最新成本最低的方法是什么？有我没有想到的方法吗？ 工作量 我们有一个第三方应用程序，用于监视股票交易活动。白天，作为各种工作流程的一部分，会发生很多小的变化（是的，这种交易是有效的。否，这是可疑的，等等）。在晚上，我们执行基于大型集合的操作（加载前一天的交易）。 当前的解决方案和问题 我们利用数据库快照。晚上10点，我们放下并重新创建快照。然后开始ETL处理。显然，这对我们的磁盘造成了负担，但使我们的用户能够查询数据库而无需锁定数据库（他们使用Access前端）。他们在深夜和清晨使用它，因此他们会注意到停机时间。 这种方法的问题有两个方面。首先是，如果每晚处理失败，并且这种情况并非罕见，我们将还原数据库，从而导致快照被删除。另一个问题是我们的处理时间超过了我们的SLA。我们在发现书写不佳的查询和缺乏索引之后，尝试通过与供应商合作来解决此问题。数据库快照也是造成这种速度下降的罪魁祸首，我知道它存在时与不存在时的速度差异证明了这一点。 考虑的方法 聚类 我们已经打开了数据库集群功能，但是并不能满足使数据可用的需求，只是使管理员的生活更加复杂。此后已关闭。 SQL Server复制 我们上周开始研究复制。我们的理论是，我们可以建立第二个目录并与生产数据库同步。在开始ETL之前，我们将切断连接，只有在ETL过程完成后才重新启用它。 管理员从快照复制开始，但他担心生成快照以及所需的磁盘消耗会花费几天的高CPU使用率。他指出，似乎在将所有数据写出到物理文件之前，才将其发送给订户，因此我们的.6TB数据库将花费1.8TB的存储成本。另外，如果要花几天时间才能生成快照，那么它就不符合所需的SLA。 在阅读了精美的文章之后，似乎可以使用Snapshot初始化订阅者，但是之后我们希望切换到Transactional Replication以使其保持同步。我认为打开/关闭事务复制不会强制完全重新初始化吗？否则，我们会浪费时间窗口 数据库镜像 我们的数据库处于FULL恢复模式，因此可以选择数据库镜像，但是我对复制的了解甚至少于复制。我确实找到了SO答案，该答案指示“数据库镜像阻止直接访问数据，只能通过数据库快照访问镜像的数据。” 日志传送 听起来好像还可以选择日志传送，但这是我一无所知的另一件事。它会是一种比其他任何产品都更低廉的解决方案（实施和维护）吗？基于Remus的评论： “日志传送允许对副本的只读访问，但是在应用收到的下一个备份日志时（例如，每15-30分钟）将断开所有用户的连接。” 我不确定该停机时间将转换为多长时间，从而可能导致用户感到不安。 MS同步 我仅在上个周末听说过使用Sync，但尚未进行调查。我不愿为这种问题所具有的高可见性引入一种新技术，但是如果这是最好的方法，那就去吧。 SSIS 我们在这里做了很多SSIS，因此生成数百个SSIS包来保持辅助同步是我们的一种选择，尽管这是一个丑陋的选择。我不喜欢这样做，因为这是我不愿我的团队承担的大量维护费用。 SAN“魔术”快照 过去，我听说过我们的管理员使用某种SAN技术对整个磁盘进行即时备份。也许有一些EMC魔术可以用来制作mdf / ldf的uberquick副本，然后我们可以分离/附加目标数据库。 备份还原 我认为我们每周进行一次完整备份，每晚进行一次差异备份，每15分钟进行一次日志备份。如果用户可以在3-4个小时的停机时间内进行完全还原，那么我认为这可能是一种方法。 约束条件 Windows 2008 R2，SQL Server 2008 R2（企业版），VMWare v5企业版，EMC SAN存储，其中驱动器映射到vmdk文件，commvault处理备份以及源目录中的.6TB数据。这是我们内部托管的第三方应用程序。修改它们的结构通常是不赞成的。用户不能不查询数据库而拒绝通过主动标识他们监视的表来进行工作而受到约束。 目前，我们的DBA纯粹是承包商。专职人员已经起航，我们还没有替换他们。应用程序管理员对SQL Server的知识并不精通，我们的存储/ VM管理员团队可以帮助/阻碍这一工作。开发团队目前不参与，但可以根据该方法征募他们。因此，更易于实现和维护解决方案将是可取的。 我，我站在惯例的发展方面，所以我只能提出方法，而不必处理行政方面的问题。因此，没有时间在管理程序上，我很犹豫地说一种方法要优于另一种方法-根据这些论文，它们看起来都很棒。我完全愿意按照大家的建议去做，因为正如我所看到的那样，这只会使我作为数据库专家更加有价值。我有一辆独轮车，但没有大屠杀披风。 相关问题 /programming/525637/what-are-the-scenarios-for-using-mirroring-log-shipping-replication-and-cluste /programming/434982/mirroring-vs-replication /programming/4303020/sync-databases-mirroring-replication-log-shipping /programming/4303020/sync-databases-mirroring-replication-log-shipping …
1
为什么NOT IN与包含NULL的集合总是返回FALSE / NULL？
我有一个查询（针对Postgres和Informix），其中NOT IN包含一个子查询，该子查询在某些情况下返回NULL值，导致该子句（和整个查询）无法返回任何内容。 理解这一点的最好方法是什么？我认为NULL这是没有价值的事情，因此并不期望查询会失败，但是显然，这不是正确的思考方式NULL。
1
CREATE DATABASE与CREATE ANY BASEBASE权限
在Microsoft SQL Server中，CREATE DATABASE和CREATE ANY DATABASE权限之间有什么区别？ 我找不到权威的答案。我所能推断的最好是（a）CREATE ANY暗示我可以创建该数据库以由另一个用户拥有，而CREATE（b）在Sybase / SQL Server早期的原始权限是CREATE ANY并且CREATE被别名为符合ANSI。
5
有人在生产中使用HierarchyId吗？它可靠吗？
是否有人在实际生产中使用HierarchyId，并且表的大小合理，有几千行？它可靠/性能好吗？到目前为止，我还没有发现任何与该供应商无关的人推荐它，Paul Nielsen 在此建议不要这样做。 您在实际生产系统中使用HierarchyId有什么经验？ 在选择HierarchyId替代方案时使用了哪些条件？
8
“即使在MS SQL Server Management Studio中创建了存储过程，也找不到存储过程”
我testtable在数据库内部创建了一个testbase具有以下结构的表： product_no (int, not null) product_name (varchar(30), not null) price (money, null) expire_date (date, null) expire_time (time(7), null) 我使用了Microsoft SQL Server 2008 Management Studio。 我创建了一个存储过程testtable_pricesmaller，如下所示 use testbase go create procedure testtable_pricesmaller @pricelimit money as select * from testtable where price = @pricelimit; go 并能够Object Explorer在Microsoft SQL Server Management Studio 上查看存储过程。（它在的以下树结构中列出Object …
5
在数据库中存储单位的最佳方法
我继承了一个大型（SQLServer）数据库，其中包含数百个列，这些列代表一件事或另一件事的数量。这些值的单位（例如“加仑”，“英寸”等）存储在扩展属性的MS_Description字段中。我想知道是否有更好的方法来存储此信息。我认为这对于文档目的来说是很好的，但是很难基于此数据进行可靠的单位转换计算。目前，我还没有准备好进行侵入性更改，但是如果有机会，我在这方面建议的最佳实践是什么？在我头顶上方的选项可能包括： 将列名称更改为包含的单位（例如，“ TotalVolumeInGallons”。这将使该信息更容易获得，但对我而言似乎仍然很薄弱。） 添加一个单独的“单位”列以对应于每个“金额”列（此列可以是nvarchar，也可以是一个单独的“单位”表的外键，这可能使计算单位转换更加容易。许多列可以使我的数据库大小增加一倍-拥有非常冗余的数据。） 在扩展属性中专门为单位创建一个新字段。（不幸的是，我认为这不是Units表的外键。） 我还有其他想法要忽略吗？ 更新：阅读@Todd Everett的答案后，我想到了一个可能的解决方案，所以我将继续回答自己的问题。（见下文）
2
SQL Server不会在两个等效分区的表上优化并行合并联接
此问题是从Stack Overflow 迁移而来的，因为可以在Database Administrators Stack Exchange上回答。 迁移 7年前。 非常抱歉，非常详细的问题。我已包含查询以生成用于重现该问题的完整数据集，并且我在32核计算机上运行SQL Server 2012。但是，我不认为这是特定于SQL Server 2012的，对于此特定示例，我已将MAXD​​OP强制设置为10。 我有两个使用相同分区方案进行分区的表。当在用于分区的列上将它们连接在一起时，我注意到SQL Server无法像人们期望的那样优化并行合并连接，因此选择使用HASH JOIN。在这种特殊情况下，我可以通过基于分区函数将查询分为10个不相交的范围并在SSMS中同时运行每个查询，来手动模拟一个更优化的并行MERGE JOIN。使用WAITFOR精确地同时运行它们，结果是所有查询在原始并行HASH JOIN使用的总时间的约40％内完成。 对于等效分区的表，是否有任何方法可以使SQL Server自行进行此优化？我了解到，SQL Server通常会为了使MERGE JOIN并行而产生大量开销，但是在这种情况下，似乎有一种非常自然的分片方法，开销很小。也许仅仅是一个特殊的情况，优化器还不够聪明以至于无法识别？ 下面是设置简化数据集以重现此问题的SQL： /* Create the first test data table */ CREATE TABLE test_transaction_properties ( transactionID INT NOT NULL IDENTITY(1,1) , prop1 INT NULL , prop2 FLOAT NULL ) /* …
3
公用表表达式（CTE）的好处？
此问题是从Stack Overflow 迁移而来的，因为可以在Database Administrators Stack Exchange上回答。 迁移 7年前。 来自msdn： 与派生表不同，CTE可以是自引用的，并且可以在同一查询中多次引用。 我已经大量使用了CTE，但是我从来没有考虑使用它们的好处。 如果我在同一查询中多次引用CTE： 有什么性能上的好处？ 如果我正在执行自我联接，SQL Server将扫描目标表两次吗？
21 sql-server  cte 
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.