Questions tagged «configuration»

选择数据库系统的硬件,固件,软件或其他组件的设置。

8
SQL Server的MAXDOP设置算法
设置新的SQL Server时,我使用以下代码来确定设置的良好起点MAXDOP: /* This will recommend a MAXDOP setting appropriate for your machine's NUMA memory configuration. You will need to evaluate this setting in a non-production environment before moving it to production. MAXDOP can be configured using: EXEC sp_configure 'max degree of parallelism',X; RECONFIGURE If this instance is hosting a …


3
给定数据库和用户的search_path是什么?
我可以看到当前search_path: show search_path ; 我可以使用search_path以下命令为当前会话设置: set search_path = "$user", public, postgis; 同样,我可以通过search_path以下方式为给定数据库永久设置: alter database mydb set search_path = "$user", public, postgis ; 我可以通过search_path以下方式为给定角色(用户)永久设置: alter role johnny set search_path = "$user", public, postgis ; 但是,我想知道在更改数据库和角色设置(相对于search_path)之前如何确定它们?


4
ALLOW_SNAPSHOT_ISOLATION和READ_COMMITTED_SNAPSHOT
大部分的论坛和榜样的网上总是建议同时拥有ALLOW_SNAPSHOT_ISOLATION并READ_COMMITTED_SNAPSHOT设置为ON,每当别人问快照,行版本或类似的问题。 我猜这两种设置中的SNAPSHOT这个词都会让人有些困惑。我认为,为了使数据库引擎使用行版本控制而不是READ_COMMITTED默认行为的锁定,无论使用什么设置,数据库READ_COMMITTED_SNAPSHOT都设置为ON 。ALLOW_SNAPSHOT_ISOLATION 该ALLOW_SNAPSHOT_ISOLATION设定被设定为ON只允许快照隔离启动事务(例如SET TRANSACTION ISOLATION级快照)时无论的READ_COMMITTED_SNAPSHOT设置。 将这两个设置设置为ON的唯一原因是当它需要具有READ COMMITTED行版本控制和 快照隔离功能时。 我的问题是,我的理解在某种程度上不正确吗?并且这两个设置必须始终一起设置为ON(特别是对于READ COMMITTED行版本控制)?

6
将SqlClient默认设置为ARITHABORT ON
首先,第一件事:我将MS SQL Server 2008与兼容级别为80的数据库一起使用,并使用.Net的数据库进行连接System.Data.SqlClient.SqlConnection。 出于性能原因,我创建了索引视图。结果,需要使用对视图中引用的表进行更新ARITHABORT ON。但是,探查器显示SqlClient正在与进行连接ARITHABORT OFF,因此对这些表的更新失败。 是否有使SqlClient使用的中央配置设置ARITHABORT ON?我能找到的最好的方法是在每次打开连接时手动执行该操作,但是更新现有代码库来执行此操作将是一项相当大的任务,因此我渴望找到一种更好的方法。


5
为什么需要定期重启才能保持实例正常运行?
此问题是从Stack Overflow 迁移而来的,因为可以在Database Administrators Stack Exchange上回答。 迁移 7年前。 我们已经在SQL 2005上提供了一个生产数据库服务器。一切正常运行了一段时间,但是几周后,我们发现性能明显下降。仅重新启动SQL Server才能使性能恢复正常。 一些背景: 运行1200多个数据库(大多数是单租户,一些是多租户)。在任何人只讲讲多租户讲座之前,有充分的理由保持这种结构…… RAM是16 GB。重新启动后,SQL Server很快就可以恢复到15 GB的使用率。 活动的数据库连接大约有80个连接-考虑到每个进程每个Web服务器有一个连接池,我们认为这很健康-因此我们没有连接泄漏问题。 我们在非高峰时间尝试了几种方法:-运行DBCC DROPCLEANBUFFERS(带有CHECKPOINT)以清除数据缓存。它无效,也不会清除任何RAM使用情况。-运行FREEPROCCACHE和FREESYSTEMCACHE清除查询计划和存储的proc缓存。没有效果。 显然,在活动的生产环境中重新启动SQL Server是不理想的。我们缺少了一些东西。还有其他人经历吗? 更新:2012年4月28日 仍在解决此问题。我已将SQL Server的内存降低到10 GB,只是为了排除与操作系统的争用。我正在接近缩小范围,但是下一步需要一些帮助。 这是我发现的,重新启动SQL Server之后,页面文件在12.3 GB和12.5 GB之间徘徊。它将保持这种状态数天。服务器线程总数将介于850和930之间-连续几天也稳定且一致(sqlserver取决于流量,稳定在55和85之间)。 然后,有一个“事件”。我不知道事件是什么,我无法在日志中看到它,并且在事件发生的一周中的任何一天或时间都看不到任何一致的信息,但是突然之间,他的页面文件跳到了14.1或14.2。 GB,并且线程数跳到1750和1785之间。 在发生这种情况时检查perfom,其中有900多个线程是sqlserver。所以我去sp_who2看看这些线程是从哪里来的...而且只有大约80个使用过的数据库连接。 所以....有谁知道我如何找到SQL Server上这900个线程的其余位置以及它们在做什么? 更新:2012年6月1日 仍在与问题作斗争。对于仍然阅读此书的人来说,线程跳转的问题已得到解决。这是由自动的ComVault备份软件引起的。它正在创建一个线程,尝试备份不再存在的数据库(它正在维护以前的数据库列表),而不是仅备份当前数据库。 但是-问题仍然存在,我们必须每周重新启动,花几天时间。与Rackspace团队合作,看看他们是否可以阐明任何想法。


3
MySQL InnoDB page_cleaner设置可能不是最佳的
在mysqld.log中看到此注释: [Note] InnoDB: page_cleaner: 1000ms intended loop took 15888ms. The settings might not be optimal. (flushed=200 and evicted=0, during the time.) 似乎在这里提到了这样的事情: MySQL实例停滞“正在执行SYNC索引” 我的问题是:如果在日志中看到此注释,应该采取什么措施(如果有)? MySQL和OS版本: mysql-community-server- 5.7.9 -1.el7.x86_64 centos-release-7-1.1503.el7.centos.2.8.x86_64 运行显示变量,例如“ innodb%”;如建议显示: innodb_page_cleaners | 1

5
由于WHERE子句中的条目超过100,000个,导致SQL Server错误8632
我的问题(或至少是错误消息)与查询处理器用尽内部资源非常相似-极长的sql查询。 我的客户正在使用SQL选择查询,其中包含一个正好有100,000个条目的子句。 查询失败,出现错误8632和错误消息 内部错误:已达到表达式服务限制。请在查询中查找可能复杂的表达式,然后尝试简化它们。) 我非常奇怪地抛出此错误消息,恰好在100,000个条目处,所以我想知道这是否是可配置的值。是这种情况,如果是的话,如何将该值增加到更高的值? 在MSDN上,建议重新编写查询,但我想避免这种情况。 同时,我发现我正在谈论的条目列表包含自然数,其中有些看起来似乎是连续的(例如(1,2,3,6,7,8,9,10,12, 13,15,16,17,18,19,20)。 这使得SQL的子句类似于: where entry in (1,2,3,6,7,8,9,10,12,13,15,16,17,18,19,20) 我可以将其转换为: where (entry between 1 and 3) OR (entry between 6 and 10) OR (entry between 12 and 13) OR (entry between 15 and 20) 可以通过以下方式将其缩短: where entry in (1,...,3,6,...,10,12,13,15,...,20) ...或类似的东西?(我知道这是一个长期的尝试,但这会使软件更新更容易且更具可读性) 供您参考:where子句中的数据是在另一个表上完成的计算结果:首先在该表的开头读取并过滤该表的条目,然后再进行一些额外的处理(使用SQL),这种额外处理的结果是更多的过滤,其结果在where子句中使用。由于不可能用SQL编写完整的过滤,因此使用了上述方法。显然,子句的内容可能在每个处理过程中都发生变化,因此需要动态解决方案。

1
了解postgresql.conf文件中的“ max_wal_size”和“ min_wal_size”参数默认值
根据文档min_wal_size和max_wal_size参数,默认值为: 对于max_wal_size:The default is 1 GB 对于min_wal_size:The default is 80 MB 然后,从数据库配置中查看以下参数: select name, setting, unit from pg_settings where name in ('min_wal_size', 'max_wal_size') 给出结果: name | setting | unit ---------------------------------- max_wal_size | 64 | min_wal_size | 5 | 我有两个问题: 1)为什么这些值与docs中显示的默认值不匹配?我根本没有更改配置设置。 2)为什么unit这些参数的列为空/ NULL?在这种情况下,什么是64和5值?MB?GB?还是什么? work_mem当一切都清楚后,为什么这不像示例 参数: name | setting | unit ---------------------------------- …

4
SQL Server最大内存,页面文件,最大并行度
希望您的DBA宇宙大师可以回答以下三个问题: 我知道设置SQL Server的最大内存是最佳实践。因此,如果具有44 GB RAM的服务器安装了SQL Server,则应将SQL Server最大内存设置为大约37GB。 但是,如果SQL Analysis Service和SQL Reporting Services与SQL Server安装在同一服务器上,我们应该设置什么?那么是否最好将SQL Server的最大内存设置为22GB RAM,以便Analysis可以占用其他22GB RAM? 在运行带有44 GB RAM的SQL Server的服务器上,设置页面文件大小的最佳实践是什么?我在Brent Ozar(http://www.brentozar.com/archive/2014/06/sql-server-setup-checklist-free-ebook-download/)上阅读了以下内容: SQL Server不需要巨型页面文件。如果要在服务器上安装其他应用程序(不建议这样做,则应隔离SQL Server)。您可能需要更大的页面文件。如果SQL Server是包装盒上运行的唯一主要服务,则通常在系统驱动器上创建2GB大小的页面文件。 微软表示,我们应该将页面文件系统设置为RAM的1.5倍,这与Remus的建议相符(请参见-> http://rusanu.com/2009/11/22/system-pagefile-size-on-machines-with -large-ram /)。 因此,在具有44GB RAM的服务器上,我们在SQL Analysis Service和SQL Reporting Services旁边安装了SQL Server。我们应将页面文件设置为什么大小? 对于SharePoint是SharePoint场的一部分的SQL Server以及SharePoint存储数据库的位置,应该将最大并行度设置为1。现在,我们拥有的服务器不属于SharePoint场的一部分(称为sql2)。服务器上安装了SQL Server,SQL Analysis and Reporting。SharePoint不会在其服务器上存储其数据库,但是我们确实创建了SharePoint读写的报告和分析数据库/多维数据集。 布伦特·奥扎尔(Brent Ozar)说: 经验法则:将此值设置为硬件上的单个NUMA节点(处理器)插槽中的物理内核数或更少 当该SQL Server实例具有4个VCPU时,应在该SQL Server实例上为最大并行度配置什么? 希望你们不仅给我,而且让更多的SQL管理员对最佳实践的了解比与Internet上的丛林有关。

3
为什么我的.my.cnf设置不起作用?
我的桌面上的主目录中有一个.my.cnf文件,该文件包括: [dbid] user = myusername password = mypassword database = dbname host = server.location.com 如果我没记错的话,在从Ubuntu 10.04升级到11.04之前,我能够使用以下命令 mysql dbid 直接连接到数据库 但是今天我得到了这个错误: ERROR 1049 (42000): Unknown database 'dbname' 我做错什么了吗?

1
pg_restore期间检查点的发生过于频繁
在PostgreSQL 9.2.2(Windows 32位)下,我有一个pg_restore命令,该命令系统地导致有关检查点频率的日志警告,例如: LOG: checkpoints are occurring too frequently (17 seconds apart) HINT: Consider increasing the configuration parameter "checkpoint_segments". 该数据库大小约为3.3 Gb,具有112个表/ 160个视图,并在大约14分钟内恢复。 这在正常情况下发生是正常的pg_restore吗?

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.