Questions tagged «performance»

我在4个vCPU VM运行Microsoft SQL Server 2016 SP2-CU6（13.0.5292.0）与max degree of parallelism设置为2和cost threshold for parallelism设置为50。 早晨，当尝试显示SELECT TOP 100查询的估计执行计划时，我遇到了大量的等待，渲染估计计划的操作需要花费几分钟，通常是5到7分钟。同样，这不是查询的实际执行，这只是显示“ 估计的执行计划”的过程。 sp_WhoIsActive将显示PAGEIOLATCH_SH等待或LATCH_EX [ACCESS_METHODS_DATASET_PARENT]等待，当我在操作期间运行Paul Randal的WaitingTasks.sql脚本时，它将显示CXPACKET等待，而工作线程显示PAGEIOLATCH_SH等待： *资源描述字段= exchangeEvent id=Port5f6069e600 WaitType=e_waitPortOpen waiterType=Coordinator nodeId=1 tid=0 ownerActivity=notYetOpened waiterActivity=waitForAllOwnersToOpen 工作线程看起来是将整个stats表都放入内存中（因为从Paul Randal的查询中显示的那些页号以及后续页号都指向该stats表的集群键）。一旦计划恢复，即使在stats剩余的各种记录（我认为由于类似查询的查找操作而将其拉出）的情况​​下，大部分缓存都从高速缓存中消失之后，一天中的剩余时间基本上都是瞬时的。 如果查询实际上是使用SCAN运算符的计划执行的，我会期望出现这种初始行为，但是为什么在评估执行计划时才这样做（如上面链接的计划所示），以达到SEEK运算符呢？我该怎么办（除了在办公时间之前运行此语句，以便适当地缓存我的数据），以帮助提高此处的性能？我假设一对覆盖索引将是有益的，但是它们真的可以保证行为的任何改变吗？我必须在这里在一些存储和维护窗口限制内工作，并且查询本身是从供应商解决方案生成的，因此，此时欢迎任何其他建议（除了更好的索引编制）。

13 sql-server  performance  sql-server-2016 

我已经开始对2012 SQL Server上的各种活动进行一些长期跟踪，并且发现增量备份期间批处理请求的增加。 可以说，正常情况下，每天我们大约有10-20个批处理请求，但是在我们的差异备份运行期间，它跳到了每秒100-130个。 我知道这不是很多，但令我好奇的是它增加了10倍。 不知道您可能需要什么信息来帮助解决此问题。

13 sql-server  performance  backup 

我正在使用的数据处理系统存在一些性能问题。我从一个小时的周期中收集了等待统计信息，其中显示了大量CXPACKET和LATCH_EX等待事件。 该系统由3个处理SQL Server组成，这些SQL Server进行了大量的数字运算和计算，然后将数据馈送到中央群集服务器中。处理服务器可以一次最多运行6个作业。这些等待统计数据是针对我认为正在引起瓶颈的中央集群的。中央群集服务器具有16个核心和64GB RAM。MAXDOP设置为0。 我猜CXPACKET来自正在运行的多个并行查询，但是我不确定LATCH_EX等待事件指示什么。从我读到的内容来看，这可能是非缓冲等待？ 谁能说出这种等待统计的原因是什么，我应该采取什么行动来调查这个性能问题的根本原因？ 顶部查询结果是等待的总计统计信息，底部查询结果是1小时内的统计信息

13 sql-server  performance  query-performance  parallelism  wait-types 

我是一家小公司的一员，因此像往常一样担任许多不同的职务。最新的一项是为.NET Web应用程序购买专用的SQL Server盒。我们已经引用了双Xeon E5-2620（六核）2.00 GHz CPU配置（总共12核），32 GB的RAM。这使我们在磁盘阵列上的预算有限，它实际上由RAID 1配置中的两个2​​.5英寸SAS 300 GB驱动器（15k RPM）组成。 我知道磁盘设置对于SQL Server来说不是最佳选择，我真的很想推动RAID 10，因此我们可以将数据库，日志文件和tempdb放在自己的驱动器上。为了使它与我们的预算兼容，我应该考虑减少CPU内核数吗？还是我会为保留内核并使用更少的驱动器而付出更多的钱，也许在双RAID 1设置中可以使用4个？ 以下是一些其他统计信息 SQL Server数据库倾向于大量读写操作，分别可能是80％和20％。当前的DB大​​小目前约为10 GB 26 GB，并且以每月250 MB的速度增长。 当前运行在与Web服务器共享的单个四核Xeon盒上的SQL Server 2008 R2 Standard（12 GB Ram，RAID 1中的2 x 10k 300GB SAS驱动器）上，希望迁移到SQL Server 2012 Standard。 数据库可以为大约100-150个并发用户提供一些后台调度任务。阅读这篇文章，我认为12个内核严重过头了！ 我将整个应用程序部署到链接到SQL Azure DB的Azure云服务（2个小实例）。尽管在测试时性能是合理的（几乎为零负载），但由于我已经读了太多的不可预测性，所以我失去了在生产中使用的勇气。使用横向扩展方法可能会更好，但是只有10 GB的数据库，我现在可以避免扩展并节省一些现金。 我最初忽略了许可成本，却没有意识到SQL Server 2012许可是基于内核数量的。我有一个带有SQL Server 2012 Standard许可证的BizSpark MSDN订阅，因此我需要了解开箱即用的几个内核。

13 sql-server  performance  configuration  hardware 

我正在尝试比较两个查询： 查询1： SELECT a,b,c,d,e FROM tableA LEFT JOIN tableB ON tableA.a=tableB.a WHERE tableA.b=tableB.b AND tableA.c=tableB.c AND tableA.d=tableB.d AND tableA.e=tableB.e 查询2： SELECT a,b,c,d,e FROM tableA LEFT JOIN tableB ON tableA.a=tableB.a AND tableA.b=tableB.b AND tableA.c=tableB.c AND tableA.d=tableB.d WHERE tableA.e=tableB.e 我是否可以正确地说这两个查询给出相同的结果？ 进一步说第一个查询建立一个更大的表并对其做更大的WHERE条件是否正确；而第二种情况是我们有一个较小的构造表，WHERE然后将其应用于简单表。 假设结果相同，则应首选哪个查询？是否存在明显的性能问题？

13 mysql  performance 

我正在构建一个Web应用程序（项目管理系统），并且在性能方面一直想知道这一点。 我有一个Issues表，里面有12个外键链接到其他各种表。在其中的8个中，我需要加入才能从其他表中获取title字段，以便使记录在Web应用程序中有意义，但是，这意味着进行8个加入似乎非常繁琐，尤其是因为我只是在拉入这些联接中的每个联接都有1个字段。 现在，出于永久性的原因，我还被告知要使用自动递增的主键（除非考虑到分片，在这种情况下我应该使用GUID），但是在性能上使用varchar（最大长度为32）有多糟糕？我的意思是，这些表中的大多数可能不会有很多记录（其中大多数应该在20以下）。另外，如果我使用标题作为主键，则不必在95％的时间内进行联接，因此对于95％的sql，我什至会发生任何性能下降（我认为）。我唯一能想到的缺点是我将拥有更高的磁盘空间使用率（但是一天下来确实是一件大事）。 我将查找表用于很多此类而不是枚举的原因是因为我需要最终用户可以通过应用程序本身配置所有这些值。 将varchar用作不包含很多记录的表的主键有什么弊端？ 更新-一些测试 因此，我决定对此做一些基本测试。我有100000条记录，这些是基本查询： 基本VARCHAR FK查询 SELECT i.id, i.key, i.title, i.reporterUserUsername, i.assignedUserUsername, i.projectTitle, i.ProjectComponentTitle, i.affectedProjectVersionTitle, i.originalFixedProjectVersionTitle, i.fixedProjectVersionTitle, i.durationEstimate, i.storyPoints, i.dueDate, i.issueSecurityLevelId, i.creatorUserUsername, i.createdTimestamp, i.updatedTimestamp, i.issueTypeId, i.issueStatusId FROM ProjectManagement.Issues i 基本INT FK查询 SELECT i.id, i.key, i.title, ru.username as reporterUserUsername, au.username as assignedUserUsername, p.title as projectTitle, pc.title as ProjectComponentTitle, …

13 mysql  performance  innodb  primary-key 

我正在计划将2TB数据库实时迁移到分区表的过程。从广义上讲，该系统是一个文档存储，其中大部分空间分配给了50kb至500kb之间的LOB，其中很小的一部分位于500kb至1MB范围内。迁移的一部分将涉及从旧数据库到新数据库的BCPing数据。 BCP是首选方法，因为数据的当前/历史划分允许在最终切换之前分阶段（在较安静的时段）提取较旧的数据，从而将对实时系统的影响降至最低。数据量和存储的可用性排除了对分区方案进行原位重建的麻烦。 我怀疑由于BLOB内容的原因，尝试KILOBYTES_PER_BATCH而不是ROWS_PER_BATCH可能会带来一些性能提升。BCP文档中建议SQL可以基于该值优化操作。 我找不到关于这些优化的性质或从哪里开始测试的任何指导。在缺乏建议的情况下，我将尝试从4/8/16/32 / 64mb边界开始进行短期运行。 更改数据包大小可能会带来一些好处（BCP-一个参数，而不是服务器级别设置），但除非有人采用更规范的方法，否则我倾向于将此值提高到最大值65535。

13 sql-server  performance  bcp 

对于我们的一位客户，我们的应用程序遇到了一些性能问题。这是一个.NET 3.5 Web应用程序，正在使用和更新SQL Server数据库上的数据。当前，我们的生产环境由一台Windows 2008 R2计算机作为前端，而在后端则是一个SQL Server 2008 R2群集。我们的应用程序使用COM +和MSDTC连接到数据库。 这是正在发生的事情：我们的最终用户有时会抱怨应用程序运行缓慢。某些页面的加载时间比预期的要多。在尝试找出正在发生的事情时，我设法找出了数据库方面的一些奇怪行为，这可能是性能下降的原因。我注意到有时有些SQL语句需要花费更多的时间才能运行。我设法使用探查器跟踪（带有TSQL_Duration模板）来识别长时间运行的查询，从而识别其中一些语句（主要是对应用程序存储过程的调用）。 问题是，当我直接在SQL Management Studio的数据库上运行这些存储过程时，有时它们会花费很长时间（大约7/8秒），而其他时候它们却很快（不到1秒）。我不知道为什么会这样，这让我发疯，因为其他任何应用程序都没有使用SQL机器（4核，32 GB），并且这些查询的运行时间不会太长。 不是DBA或SQL Server专家，我一直在尝试研究一些可以帮助我理解问题的东西。这是我尝试解决问题以及到目前为止发现的步骤： 应用程序调用的所有TSQL代码都是在存储过程中编写的。 我在SQL Server事件探查器上确定了一些长时间运行的查询，但是，当我在Management Studio上运行这些查询时，它们要么运行很长时间（从4到10秒），要么运行很快（不到1秒）。我正在使用参数中传递的相同数据运行完全相同的查询。这些查询主要是存储过程，其中包含选择语句。 我尝试查看等待和排队统计信息，以尝试确定是否有某些资源在等待进程。我运行了以下查询： WITH Waits AS (SELECT wait_type, wait_time_ms / 1000.0 AS WaitS, (wait_time_ms - signal_wait_time_ms) / 1000.0 AS ResourceS, signal_wait_time_ms / 1000.0 AS SignalS, waiting_tasks_count AS WaitCount, 100.0 * wait_time_ms …

13 performance  sql-server-2008 

我有一个SQL Server 2005，它最近已经变得不可预测，并且我为之why恼。在几秒钟内执行的查询正在更改计划并花费数分钟（花费时间进行全表扫描或索引假脱机）。现在最明显的是，统计数据已过时，导致优化程序感到困惑，但我坚信情况并非如此-首先，因为基础数据没有发生重大变化（例如，将一年的数据添加到一年的数据之上）已经存在于表格中），其次是因为“自动创建统计信息”和“自动更新统计信息”均为true。然而，优化器变得混乱了。在Tuning Advisor中运行SQL给了我许多CREATE STATISTICS似乎可以解决它的多列语句（直到下一个SQL行为异常）。 有什么我可以用来解决根本原因的策略构想吗？为什么“正常”统计数据还不够？

13 sql-server-2005  performance 

我们试图找出运行缓慢的sql服务器查询从以下配置之一托管的服务器（大小为300 GB）中命中/获取数据的根本原因： Windows Server 2003 R2，SP2，企业版，16 GB RAM，12 CPU 32位 SQL Server 2005 SP4企业版32位。 我们已经通知企业升级到64位需要一个多月的时间。 但是对于当前问题，如果可以解决内存压力或最终得出结论以增加RAM，则我们正在尝试收集数据。 完成的操作：重新索引和更新统计信息适用于此数据库。 如下图所示，我们已经注意到过去5天在加载时间内运行的信号量等待类型： 以下查询后很少有信息：缓冲区大小= 137272 SELECT SUM(virtual_memory_committed_kb) FROM sys.dm_os_memory_clerks WHERE type='MEMORYCLERK_SQLBUFFERPOOL' 和以下每个查询的信号量内存= 644024 SELECT SUM(total_memory_kb) FROM sys.dm_exec_query_resource_semaphores 以下是从dm_exec_query_resource_semaphores和sys.dm_exec_query_memory_grantsdvv 收集的更多信息 因此，从上面收集的信息和每个SP_Blitz数据来看，资源信号似乎是问题所在。 与可用的16 GB RAM相比，是否为资源信号ID分配的内存'target_memory_kb'太低。 注意*运行8小时的每次分析“ target_memory_kb”始终小于1 GB，而可用的16 GB是多少？ 这里可能是什么问题以及如何解决，请提出建议 谢谢

13 sql-server  performance  sql-server-2005 

我想使用任何可能的RDBMS创建数据库。它将有一个大约150列的表格。目的是对某些其他对象执行最近邻搜索。因此，它是150维空间中的NNS。 我已经尝试使用一些显而易见的方法，例如L1或L2距离，但是对于具有多行的表，当然会花费很多时间。另外，我尝试查看KD树（请注意，我没有对其进行测试）和PG-Strom，但它们并不是多维数据的良好解决方案。 我可以使用数学方法（例如KD-tree）或技术方法（例如PG-Strom）以某种方式提高描述搜索的速度吗？ 我将尝试使用允许提高NNS速度的任何RDBMS。但是MySQL和PostgreSQL是最适合我的DBMS。

13 database-design  performance  nearest-neighbor 

我听说有人说您不想使用动态SQL。您能举一个具体的例子还是真实的例子？我个人在数据库中编写了几次代码。我认为可以，因为它具有灵活性。我的猜测是关于SQL注入或性能的。还要别的吗？

13 sql-server  performance  stored-procedures  dynamic-sql  sql-injection 

我从博客文章中得到了这个查询： SELECT object_name, counter_name, cntr_value FROM sys.dm_os_performance_counters WHERE [object_name] LIKE '%Buffer Manager%' AND [counter_name] = 'Buffer cache hit ratio' 该帖子说，这将使我对缓存的命中率有所提高。似乎表明它将是0-100的值（结果显示为87）。 但是当我运行它时，我得到的数字很高。这是一个例子： object_name counter_name cntr_value SQLServer:Buffer Manager Buffer cache hit ratio 9990 这是否意味着99.90％？ 如果没有，那是什么意思？我如何获得真正的价值？ 注意：我得到的值低至257和高至352363 如果相关，则还有其他一些服务器统计信息： 网页预期寿命：145 页面每秒读取数：1,380,009,009

12 sql-server  performance  sql-server-2012 

考虑数据库性能时，VLF有多重要？什么将描述VLF的最佳情况？

12 sql-server  performance  transaction-log 

我正在优化工作票的Firebird 2.5数据库。它们存储在这样声明的表中： CREATE TABLE TICKETS ( TICKET_ID id PRIMARY KEY, JOB_ID id, ACTION_ID id, STATUS str256 DEFAULT 'Pending' ); 我通常想查找尚未处理的第一张票证并且处于Pending状态。 我的处理循环将是： 取回第一张票 Pending 使用票务。 更新故障单状态=> Complete 重复。 没什么好看的。如果在此循环运行时正在观察数据库，则可以看到每次迭代的索引读取次数都在增加。据我所知，性能似乎并没有显着下降，但是我正在测试的机器很快。但是，我从一些用户那里收到了性能随时间下降的报告。 我在上有一个索引Status，但看起来仍然像它在Ticket_Id每次迭代时向下扫描列。似乎我正在忽略某些内容，但是我不确定是什么。是这种预期的索引读取数目攀升，还是索引行为异常？ -编辑评论- 在Firebird中，您可以限制行检索，例如： Select First 1 Job_ID, Ticket_Id From Tickets Where Status = 'Pending' 因此，当我说“第一”时，我只是在询问它在哪里的有限记录集Status = 'Pending'。

12 performance  index  firebird