DanBennett's questions

我的部门目前严重依赖 SQL Server 作业中的 CmdExec 步骤，称为使用 SQL Server 登录。

例如

osql /e /n /S SERVER01 /U USER /P PA$$$ /d DATABASE_01 /i "\\LOCATION\OF\SQL\SCRIPT\scriptfile.sql" /o "\\LOCATION\OF\SQL\LOG\scriptfile.log"

出于很多原因（尤其是安全性和预期此方法将过时），我希望我们放弃此模型并替换为存储过程和 SSIS 包的混合体。

我已经多次提出这个建议，我总是被告知，如果我们可以通过上述方法重新创建可能的日志记录细节，我们只能朝这个方向前进，我们的部门已经非常依赖这种方法。上面的方法在上下文中输出脚本的内容以及任何服务器消息，包括所有行数和错误消息。

诚然，这确实意味着对于 SQL Server 而言不算作错误的错误更容易被拾取 - 意外的低行数等。您可以根据需要进行尽可能多的错误处理，并且永远不会像从这个方法记录，所以我可以看到参数的这一面。

为了让我的老板远离 cmdexec 步骤，我想找到一种方法来重新创建类似于 cmdexec 当前提供给我们的日志记录输出的方法 - 也许是 SQL 表而不是文件（尽管两者都可以） - 在SSIS 包和存储过程。

我熟悉使用 raiserror 进行错误处理——我在存储过程中广泛使用它——但这里的任务不仅仅是捕获 SQL 错误，而是捕获所有 cmdexec 日志记录捕获，最好是在正在执行的脚本的上下文中。 . 除了编写存储过程并在每个脚本的每个步骤之后执行它之外，我看不到这样做的方法。

此外，我很想听听有关为不使用 cmdexec 步骤的人进行日志记录的最佳实践方法。我在这个部门学习过 SQL，这是我所知道的唯一做事方式。

为了我自己的开发，我越来越多地尝试编写带有错误处理的存储过程。如果我遇到不会引发错误的问题，我会通过在开发服务器上以交互方式重新运行代码来进行故障排除，这样我就可以监控分步信息。这不如我们从 cmdexec 获得的完整日志记录方便，但更安全。

其他人做的比这更多吗？有没有更好的办法？

有谁知道是否有可能（并且建议）更新服务器上作业中的所有 cmdexec 字符串？

我们想更改我们的日志记录位置，原则上我认为这可以通过更改/O "\\LOCATION\file.log"字符串来非常简单地完成。

事实上我知道你会怎么做

USE MSDB
GO
update dbo.sysjobsteps
set [command] = replace([command], '\\OLDLOCATION\... ', '\\NEWLOCATION\... ')
WHERE...

但是我已经被告知你永远不应该手动更新 sys 表，所以这样做的想法让我非常紧张。对于其他任何事情，我会使用 dbo.sp_update_job proc （http://msdn.microsoft.com/en-gb/library/ms188745.aspx对于那些迷路在这里寻找其他工作相关的人），但那个过程似乎无法处理这个。

我有一种预感，这可能是“从不更新系统表”规则的一个例外？我无法想象 cmdexec 字符串隐含在任何进一步的关系中，例如，启用/禁用状态显然是。妄想？

所以我不确定，而且我似乎无法找出答案。有人知道或有这方面的经验吗？

谢谢丹

我们正在将 SQL Server 2005 数据库移动到新服务器并升级到 2008，我正在寻求一些建议和保证我们的方法是正确的。

我继承了这个数据库，它让我有点乱，说实话 - 最重要的是，我基本上学会了成为这台服务器上的 SQL Server 开发人员（没有计算方面的教育背景）所以我做了很多我自己的错误就可以了。作为一个部门（公共部门），我们资金不足，因​​此缺乏专业知识，只能靠自力更生。数据库最初只是一个后台的东西，但对我们的组织来说已经变得非常重要，鉴于此，性能坦率地说是令人尴尬的。

所以我们有这样的问题

• Autoshrink 使用历史
• 存储空间不足的历史 - 服务器上从来没有足够的空间来增长数据库，所以我猜这些文件可能在内部非常分散。
• 有多种排序规则类型（没有充分理由），
• 到处都是不合适text的数据类型（很多Nvarchar, nchar,ntext当我们不需要 ascii 字符时，text哪里varchar更合适）

新服务器是一个 64 位的虚拟服务器，存储在 RAID 上。

安装和升级后我的计划是：

• 删除大量我们已确定（有信心）为冗余的表（大约 1/3 的数据库大小！）
• 将归类规范化为一种类型（经过一些分析和测试，我们确定这不会给我们带来问题——我们不需要区分大小写）
• text将数据类型规范化为varchar/char
• 将数据库文件大小设置为未来 2 年的预期使用量加上 50%

在这些过程之后/之前，还有什么我应该考虑的吗？这里的任何决定是否看起来不合时宜？例如文件大小问题——这是我在 RAID 上需要担心的问题吗？