在设置新的 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 Sharepoint database, you MUST specify MAXDOP=1
(URL wrapped for readability)
http://blogs.msdn.com/b/rcormier/archive/2012/10/25/
you-shall-configure-your-maxdop-when-using-sharepoint-2013.aspx
Biztalk (all versions, including 2010):
MAXDOP = 1 is only required on the BizTalk …Run Code Online (Sandbox Code Playgroud) 我可以看到电流search_path:
show search_path ;
Run Code Online (Sandbox Code Playgroud)
我可以search_path为当前会话设置:
set search_path = "$user", public, postgis;
Run Code Online (Sandbox Code Playgroud)
同样,我可以search_path为给定的数据库永久设置:
alter database mydb set search_path = "$user", public, postgis ;
Run Code Online (Sandbox Code Playgroud)
我可以使用以下命令永久设置search_path给定角色(用户):
alter role johnny set search_path = "$user", public, postgis ;
Run Code Online (Sandbox Code Playgroud)
但我想知道如何在更改数据库和角色设置search_path之前确定它们是什么(相对于)?
我有以下内容 ~/.my.cnf
[client]
password="somepass"
Run Code Online (Sandbox Code Playgroud)
但这不是我用于连接到的每个 user@host/database 的密码。有没有办法在配置中为不同的东西指定不同的密码,所以我不必输入它们?
大部分的论坛和榜样的网上总是建议同时拥有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 行版本控制)?
你如何计算 mysql max_connections ?
你有什么考虑?
首先要做的事情是:我将 MS SQL Server 2008 与兼容级别为 80 的数据库一起使用,并使用 .Net 的System.Data.SqlClient.SqlConnection.
出于性能原因,我创建了一个索引视图。因此,视图中引用的表的更新需要使用ARITHABORT ON. 但是,探查器显示 SqlClient 正在连接ARITHABORT OFF,因此对这些表的更新失败。
是否有使 SqlClient 使用的中央配置设置ARITHABORT ON?我能找到的最好方法是在每次打开连接时手动执行该操作,但是更新现有代码库以执行此操作将是一项相当大的任务,因此我很想找到更好的方法。
sql-server-2008 sql-server ado.net configuration compatibility-level
我在服务器组中列出了大量已配置的连接,有没有办法保存它?不仅保存密码,还保存服务器组设置

我们在 SQL 2005 上有一个生产数据库服务器。一切正常运行了一段时间,但几周后我们看到性能显着下降。只有重新启动 SQL Server 才能使性能恢复正常。
一些背景:
我们在非高峰时间尝试了几件事: - 运行 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 …
根据和参数的文档,min_wal_sizemax_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')
Run Code Online (Sandbox Code Playgroud)
给出结果:
name | setting | unit
----------------------------------
max_wal_size | 64 |
min_wal_size | 5 |
Run Code Online (Sandbox Code Playgroud)
我有两个问题:
1) 为什么这些值与文档中显示的默认值不匹配?我从来没有改变过配置设置。
2) 为什么unit这些参数的列是空的/NULL?在这种情况下,64 和 5 值是什么意思?MB? GB? 或者是什么?
为什么这不像例如 work_mem参数,当一切都清楚时:
name | setting | unit
----------------------------------
work_mem | 4096 | kB
Run Code Online (Sandbox Code Playgroud) 在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.)
Run Code Online (Sandbox Code Playgroud)
这里似乎提到了这样的事情: MySQL 实例停滞“做 SYNC 索引”
我的问题是:当在日志中看到此注释时,应该采取什么措施(如果有)?
MySQL 和操作系统版本:
mysql-community-server- 5.7.9 -1.el7.x86_64
centos-release-7-1.1503.el7.centos.2.8.x86_64
运行SHOW VARIABLES LIKE 'innodb%'; 如建议所示:
innodb_page_cleaners | 1
Run Code Online (Sandbox Code Playgroud) configuration ×10
sql-server ×4
mysql ×3
postgresql ×3
ado.net ×1
innodb ×1
logs ×1
maxdop ×1
my.cnf ×1
optimization ×1
performance ×1
pgadmin ×1