【发布时间】:2022-12-01 01:21:58
【问题描述】:
我知道每个人都想在这个问题上换个角度看。如果您继续阅读,我将不胜感激。当然,当向大表中添加字段时,日志会增长。让我解释一下我最好的能力:
我们有一个部署给客户的数据库升级实用程序。在该实用程序中,我们使用特定于我们版本的更改来操作数据库。
我们的测试部门在本地与虚拟机和虚拟机与虚拟机之间看到了不同的结果。一些 VM 的日志增长不大,而其他 VM 增长了 30gb。数据库设置为 SIMPLE。 “技术上”不应使用事务日志。我知道日志被用作缓存,直到光盘有足够的空间来接受请求的更改。我知道在 SQL 方面没什么可做的。升级完成后,我们不得不使用某种收缩来处理更改。
我很好奇为什么 Physical 和 VM 会有不同的行为,以及在 VM 环境中寻找什么来查看这是否会出现问题。我看看光盘上的东西,MSINFO32,CPU?我已经查看以确保 VM 上没有压缩。我还做了配置文件并查看了 fn_dblog 以查看在特定表上增长的索引。我只是想不通为什么有些呈指数增长,而另一些则没有增长。此外,如果您知道任何 DB_Owner 权限级别收缩样式命令,我将不胜感激。目前我们正在测试一个检查点,因为 ShrinkDB 由于权限级别而无法使用。
--table has usually has between 10 and 20 million records. It is a table that has 10 fields strictly typed
IF col_length('[dbo].[foo]','Field1') IS NULL
BEGIN
ALTER TABLE [dbo].[foo] ADD [Field1] smalldatetime NOT NULL CONSTRAINT [df_Field1] DEFAULT (GETDATE())
END
--This has growth and can get a bit out of control on VM. Physical machines it does not affect as much.
--Try 2 hoping Getdate was the issue
IF col_length('[dbo].[foo]','Field1') IS NULL
BEGIN
ALTER TABLE [dbo].[foo] ADD [Field1] smalldatetime NULL
END
DECLARE @TheDate smalldatetime = GETDATE()
UPDATE [dbo].[foo] SET [Field1] = @TheDate
--This was even more problematic to the log and took considerably longer
【问题讨论】:
-
只是个人的烦恼......专栏而不是领域
标签: sql sql-server virtual-machine