如果我在 SQL 2005 Server 上备份数据库,然后将该备份还原到同一数据库服务器实例上的不同(新)数据库,则不会保留哪些内容(例如缓存的执行计划、统计信息等)。 .)
我有一个包含超过一百万条记录的表,并带有全文索引。
这张表过去被一分为二,每年年底,超过某个日期的数据会被移到另一个具有完全相同结构的单独数据库中的表中。第二个表有大约 3+ 百万条记录。
我只能猜测为什么要这样做,但现在我被要求将这两个表合并回一个表,并对其进行分区。我正在运行 SQL Server 2005。
全文搜索在分区表中是否有效?
对这种情况有什么建议,或者我应该注意什么?
有一个有趣的 SQL 大师在那里。现在这个搜索只需要几秒钟,但它非常密集,必须有更好的方法。可能是我期望太高了?
简单的假期搜索应用程序。200 万假期。分页/排序大约 600,000 行。
这是表的架构
CREATE TABLE [dbo].[Holiday](
[Id] [int] NOT NULL,
[PropertyId] [int] NOT NULL,
[Price] [int] NOT NULL,
[Rating] [int] NOT NULL,
[Country] [char](2) NOT NULL,
[ResortId] [int] NOT NULL,
[DepartureAirport] [char](3) NOT NULL,
[DestinationAirport] [char](3) NOT NULL,
[DepartureDate] [datetime] NOT NULL,
[Basis] [char](2) NOT NULL,
[Duration] [int] NOT NULL,
CONSTRAINT [PK_Holiday] PRIMARY KEY CLUSTERED ([Id] ASC)
)
Run Code Online (Sandbox Code Playgroud)
如您所见,非常简单。我们有属性、价格、持续时间、出发/目的地机场等。现在,提供的字段越多,搜索速度就越快。如果我有出发机场、财产和日期,那么搜索速度非常快。但是,如果我只有一个国家而不是其他任何东西,则需要处理大量数据。
使用我的表格的这个CSV 导出,总共有 200 万行,大约 666k 仅国家代码为 FR,这是我的例子。
这是搜索查询。它返回两个表。第一个是摘要,因此符合您的条件的假期总数以及有多少独特的属性。第二个表包含搜索的实际结果。
--Build a temp table, and store …Run Code Online (Sandbox Code Playgroud) 我正在使用一个旧数据库,该数据库已针对名为ColorList的表实现了查询通知。
在为不相关的问题运行服务器端跟踪时,我注意到查询
SELECT color FROM ColorList
Run Code Online (Sandbox Code Playgroud)
每 10 毫秒执行一次。
这是查询通知的工作方式吗?SQL Server 是否存储原始查询的结果,然后无休止地运行查询,直到检测到更改?
我们有两个数据库表ErrorLog,Audit并且在过去几年中都变得相当大。所以为了减少数据库的大小,我必须编写一个脚本来清除这两个表中所有超过 6 个月的行。
这就是我想出的:
ALTER DATABASE StudioWebTest SET RECOVERY SIMPLE;
DELETE FROM [Audit] WHERE AuditDate < DATEADD(M, -6, GETDATE());
DELETE FROM [ErrorLog] WHERE ErrorDate < DATEADD(M, -6, GETDATE());
ALTER DATABASE StudioWebTest SET RECOVERY FULL;
Run Code Online (Sandbox Code Playgroud)
在我的开发机器 (SQL Server 2008 R2) 上,无论是否更改恢复模式,数据库大小都会增长 2-3 倍。但是,如果我立即使用收缩命令进行跟踪,它会将数据库的大小减少到原始大小的一半(在删除记录之前)。
但是,如果我推迟几天进行收缩,收缩几乎没有那么有效,因为虽然数据库大小减少了,但它仍然几乎是原来大小的两倍(在删除记录之前)。不太了解 SQL Server 如何使用它分配的空间,我认为这与使用已释放的额外空间有关。
除了一件事,这一切都可以。当我们在使用 SQL Server 2005 的生产测试环境中运行它时,shrink 命令不会将数据库的大小减少到原始大小的一半。
作为替代方案,我也尝试使用TRUNCATE代替,DELETE但这似乎没有太大区别。语句完成后数据库仍然大量增长,我仍然必须缩小它以获得相同的结果。我们还没有在生产测试机器上尝试过这个,但是因为shrink 命令似乎没有削减它,所以这是否会产生任何改进似乎值得怀疑。
无论如何,我只是想知道是否有人可以解释为什么尽管更改了错误恢复设置,数据库还是增长了这么多?如何防止这种情况发生?或者,如果这不是解决此问题的最佳方法,则可能建议减少数据库大小的替代方法。
更新:
我只是使用TRUNCATE它进行了更多测试,现在似乎没有增加大小(也许是我想象的)。我仍然需要缩小数据库以查看整体大小的减少。我可能会在生产测试服务器上尝试这个。归根结底,只要规模缩小到一定程度,我的经理就会很高兴。
我正在寻找有关如何处理环境报告的建议。我们目前拥有 16 台服务器,其中包含 20 个 SQL Server 2005 实例。我们拥有 6,600 多个数据库,并且在这些实例中不断增长(每个客户 1 个数据库)。我们的大多数数据库运行的大小从 200 mb 到 7gb,其中大约 60 个数据库运行的最大大小从 11GB 到 110gb。
我们正在使用 SAN 进行存储,但在运行影响 IO 的报告时遇到了问题。
我们的一个想法是拉取 60 个更大的数据库,然后使用事务复制来复制这些数据库并在副本上运行报告。
这将使所有较小的数据库在没有较大数据库压力的情况下运行。在未来,我们相信不会再有基于我们公司目标的更大的数据库。
有什么想法吗?
我有一个存储过程,它由在某种 Java/WebSphere 类型平台上运行的应用程序远程访问。它需要一个参数,返回一些数据,就是这样。
最近有人谈论它可能运行缓慢 - 我非常有信心 SP 没有理由运行缓慢。但是我向数据库添加了一个日志表,并让 SP 在进入时写入它,并在SELECT完成后再次写入,这样我就可以看到调用需要多长时间。
此更改适用于我的 Windows 身份验证登录 - 当我使用远程应用程序正在使用的应用程序登录时,它也适用。但是,我是从 .Net 环境而不是从 Java 进行连接。
当我更改 SP 以进行日志记录时,我注意到我INSERT输入到日志表中的 ID正在跳跃 - 表明发生了失败的插入 - 大概是由远程应用程序引起的(因为这是唯一使用的这个SP)。
应用程序登录只有db_datareader分配给它的角色。我已经GRANT编EXEC到应用程序日志上,当然。
是不是INSERT因为访问的登录只有一个,SP就不能连续db_datareader?如果是这样,INSERT当我使用相同的登录时,SP 怎么办?
我在我们的一个生产数据库中有大约 40 个表,由于各种原因,这些表不是使用聚集索引创建的。
转换这些堆的最佳自动化方法是什么?
由于我天生是一名开发人员,我真的不想手动执行此操作。
我开始为此创建一个过程,如为什么此游标以不正确的顺序产生结果中所述?,然而我对那篇文章的回应让我怀疑我在做什么。
我们允许我们的用户dbo在他们自己的数据库中,但是这确实使他们能够删除他们自己的数据库。这并不经常发生,但我想阻止他们这样做。
我设计了以下触发器来防止这种情况发生,并将数据库删除到sysadmin角色成员:
CREATE TRIGGER [deny_customer_db_drop]
ON ALL SERVER
FOR DROP_database
AS
IF IS_SRVROLEMEMBER('sysadmin') = 0
BEGIN
PRINT 'You are not permitted to drop this database'
ROLLBACK
END
GO
Run Code Online (Sandbox Code Playgroud)
这有效,但我想知道是否有更优雅的方法来使用权限而不调整每个登录自己的特定权限?
在我们当前的设置中,我们在远程托管的 Web 服务器上有一个 SQL Server 2005 实例。我们还有另一个(非 MSSQL)数据库用于我们的 POS 系统,当事情(例如产品信息)发生变化时,它会自动更新 Web 服务器。这有两个问题:
我正在努力的解决方案是在公司总部本地设置第二个 SQL Server 实例(2005 或 2008),将 POS 系统指向它,并使用某种形式的复制来同步它们之间的更改。但是,我不知道我们应该使用合并复制还是事务性的。
合并或事务复制会更好地为我们服务吗?
我们的要求是:
哪一种更符合我们的要求?
replication sql-server-2005 sql-server merge-replication transactional-replication
sql-server-2005 ×10
sql-server ×6
replication ×2
backup ×1
heap ×1
partitioning ×1
permissions ×1
reporting ×1
role ×1