sql2000 数据备份间歇性异常，删除系统操作日志，收缩数据库后；隔一段时间数据库又快速增大（约50M/天）

Posted 2023-03-17

用 exec sp_spaceused 查询结果如下：

database_name database_size unallocated_space

DB_QGJ_MultipleShop 1171.9MB 106.5 MB

reserved data index_size unused
1089936 KB 418824 KB 2240 KB 668872KB

收缩数据库后再查询； unallocated_space 为0.51MB；
数据库备份为：完全。请各位大虾看看是什么问题，谢谢！

参考技术A 数据库备份和还原就是创建完整数据库的复本，以便用于以后重新创建数据库的需要。数据备份是为了防“万一”，所以即使硬件既可靠又有冗余，数据备份和还原永远都是保护数据的重要手段之一。在SQL Server 中，提供数据备份与还原的多种方式，无论你的数据库有多大、改变是否频繁，都有满足你的要求的备份策略，有关这些方面的内容不是本文要描述的，本文只是介绍采用手工数据备份与还原过程的操作步骤。 　 一、数据库备份 1、点击“程序》Microsoft SQL Server》企业管理》”，打开企业管理器 2、展开服务器组，然后展开服务器，选中要备份的数据库 3、点击鼠标右键“所有任务》备份数据库” 4、选项设置 “备份”选择“数据库-完全”。 在“目的-备份到”中，您可以将备份文件存于当前默认路径；如果要更改路径，则请先删除当前路径，在点击“添加”，选择备份文件的存放路径。 “重写”中，如果将备份文件存于当前默认路径，则请选择“重写现有媒体选择”；如果更改路径，选择“追加到媒体”或“重写现有媒体选择”均可。 “调度”这里不介绍，您自己可以打开企业管理跟着向导做。 5、在“选项”中，请您选择“完成后验证备份” 6、点击“确定”立即开始备份并自动验证。 参考技术B 收缩数据库操作主要是收缩的日志文件，有操作就有日志，日志文件增长很正常，而且你这1G的数据库1天增长50M根本不算多嘛。追问

正常的备份数据为500多M，每天增加10--30M左右；最近一周剧增，每天大几十M，到今天就1G了。。。以往最多3G多/天。。。

追答

从你上面的数据可以看出数据实际使用的不多，可能是什麼操作让数据异常增长，触发了数据库自动增长的条件。
数据异常增长是和操作有关系的，所以这个东西你需要和你们的业务那边沟通一下，看看是不是有人在做什麼。

本回答被提问者和网友采纳

WebResource.axd 上的“填充无效且无法删除”异常

【中文标题】WebResource.axd 上的“填充无效且无法删除”异常

【英文标题】："Padding is Invalid and cannot be removed" exception on WebResource.axd

【发布时间】：2010-09-23 12:24:49

【问题描述】：

我有一个在本地环境中运行良好的 ASP.NET 2.0 应用程序。当发布到测试服务器时，我们会在服务器上遇到间歇性错误。

这是最常见的：

填充无效，无法删除。 说明：执行当前 Web 请求期间发生未处理的异常。请查看堆栈跟踪以获取有关错误及其源自代码的位置的更多信息。

异常详情： System.Security.Cryptography.CryptographicException： 填充无效，不能 已删除。

来源错误：

产生了一个未处理的异常 在当前执行期间 网络请求。有关的信息 异常的起源和位置 可以使用异常识别 下面的堆栈跟踪。

堆栈跟踪：

[CryptographicException: 填充是 无效，无法删除。] System.Security.Cryptography.RijndaelManagedTransform.DecryptData（字节[] 输入缓冲区，Int32 输入偏移量，Int32 输入计数，字节 []& 输出缓冲区， Int32 outputOffset, PaddingMode paddingMode, Boolean fLast) +1545747 System.Security.Cryptography.RijndaelManagedTransform.TransformFinalBlock（字节[] 输入缓冲区，Int32 输入偏移量，Int32 输入计数）+257 System.Security.Cryptography.CryptoStream.FlushFinalBlock() +30 System.Web.Configuration.MachineKeySection.EncryptOrDecryptData（布尔 fEncrypt, Byte[] buf, Byte[] 修饰符, Int32 开始，Int32 长度，布尔值 使用ValidationSymAlgo) +164 System.Web.UI.Page.DecryptString（字符串 s) +83 System.Web.Handlers.AssemblyResourceLoader.System.Web.IHttpHandler.ProcessRequest(HttpContext 上下文）+148 System.Web.CallHandlerExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +358 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean & completedSynchronously) +64

这发生在对特定 WebResource.axd 请求的请求上。

我们看到的另一个错误是：

视图状态 MAC 验证失败。 如果此应用程序由 Web 托管 场或集群，确保 配置指定 相同的validationKey和validation 算法。无法使用自动生成 在一个集群中。 描述：一个 期间发生未处理的异常 当前网络的执行 要求。请查看堆栈跟踪 有关错误的更多信息 以及它起源于代码的位置。

异常详情： System.Web.HttpException：验证 视图状态 MAC 失败。如果这 应用程序由 Web Farm 托管或 集群，确保 配置指定相同 验证密钥和验证 算法。无法使用自动生成 在一个集群中。

在发布表单时偶尔会发生此错误。

现在，在您介入并告诉我此错误的明显（通常）答案之前，请考虑一下：

应用程序部署到 IIS6 上的 Windows Server 2003 它不在网络场中。此处仅使用一台网络服务器。 应用程序池标识是一个自定义服务帐户，我确实在服务器上运行了aspnet_regiss -ga <username>。没有效果。

【问题讨论】：

为此添加了明确的答案，请查看:)

还有什么解决方案吗？关于您报告的第一个错误，我在 25 分钟内收到了 15 份 Exceptioneer 报告。在安装 fx3.5 sp1 后，Rackspace supposed 昨晚重新启动，我认为这些都是从那里开始的。但是，我刚刚发现他们“忘记”按照我们的票重新启动它。这是我们关于错误的报告之一的链接 - exceptioneer.com/Share/…。

我从来没有解决过这个问题。它只是从来没有在我们的优先列表中。现在我在做一个不同的项目，所以......我知道的帮助不多。

【参考方案1】：

该错误是因为您的 appdomain 已被回收/重新启动。当发生这种情况时，应用程序和机器密钥设置为自动，它会改变。这会影响资源 url (.axd) 的 url 中信息的解密。设置一个固定的机器密钥将防止它再次发生。

请查看此以获取有关类似案例的更多信息（解释是视图状态验证存在问题，但原因相同）：http://www.developmentnow.com/blog/InvalidViewstate+Or+Unable+To+Validate+Data+Error.aspx

我也想了很久。在我看到这个问题之后，它又让我想到了：Is this an attempt to break my ASP.Net site's security? ... 我刚刚回答的非常相似。我有一种感觉，它是在重新启动某些东西，因为当我们发布了一些回收应用程序的东西时，日志中显示了错误，但我没有任何其他来源说明它的关系（今天我在 invalidviewstate 上发现了这种情况，因为机器键更改:))

附言。上面终于在单个服务器上解释了它:)

【讨论】：

我会做一些调查，但我认为这不是问题所在。如果服务器在 machine.config 中指定了机器密钥，则它永远不应更改。不过感谢您的提示，我会调查一下。

你是对的，如果你指定机器密钥，它不会改变（这是修复，但几乎每个来源都只适用/解释它到多服务器），只是认为你使用 auto 作为密钥正如您强调“它不在网络农场上。这里只有一个网络服务器在使用。” ...

回过头来看这个问题，这很可能是场景

我只是想补充一点，一旦你完成了 Freddy 推荐的所有事情（很好的答案，顺便说一句！） - 不要忘记清除你的 cookie 和缓存。对我来说，问题是由添加 ASP.NET MVC AntiForgeryToken 引起的……这显然添加了一个 cookie，即使您遵循 Freddy 的所有说明，您也会看到同样的错误。 Unitl...您清除 cookie 和缓存！

非常感谢！就我而言，我在两种不同的解决方案中拥有相同的 .csproj 的副本。当我打开两者时，一个接管了另一个的端口。由于饼干仍然存在 - 繁荣！不同的“机器”键。解决方法：删除 cookie。

【参考方案2】：

当页面在浏览器中完全加载之前生成帖子时会出现此问题。看看this的问题。

【讨论】：

这就是我对次要问题的想法，但它发生的频率比舒适的要多。这并不能解释第一个错误，这在我们的案例中要严重得多。

我认为 WebResource.axd 使用一些加密参数来验证使用 Rijndael 算法的请求。也许您可以查看 IIS 日志，看看您是否有一些池回收导致您的请求无法验证。

【参考方案3】：

本，

对于您的第一个问题，我发现这似乎更符合您所看到的问题，因为该问题是偶尔发生的。 您应该可以在 http://www.codeproject.com/KB/security/Cryptor.aspx#aes 找到对此的完整解释。

您真正需要做的是将 RijndaelAlg.Padding 设置为 PaddingMode.ISO10126、PaddingMode.PKCS7 或 PaddingMode.ANSIX923。如果在加密和解密时使用相同的值，这 3 个值中的任何一个都应该起作用。其他值适用于某些数据，但不适用于所有数据。上面的 URL 解释了原因。

我不明白 Microsoft 提供有时不起作用的选项的原因，或者至少为什么它们不默认为可靠选项的原因。

【讨论】：

我自己没有进行任何压缩或加密，这就是为什么这令人困惑。这只发生在对各种 WebResource.axd URL 的请求上。

您是否在使用任何第三方组件？