标签: archive

任务

从一组大表中归档除滚动 13 个月之外的所有内容。存档数据必须存储在另一个数据库中。

• 数据库处于简单恢复模式
• 这些表从 5000 万行到几十亿行，在某些情况下每个表占用数百 GB。
• 表当前未分区
• 每个表在不断增加的日期列上都有一个聚集索引
• 每个表额外有一个非聚集索引
• 对表的所有数据更改都是插入
• 目标是最大限度地减少主数据库的停机时间。
• 服务器是 2008 R2 Enterprise

“归档”表将有大约 11 亿行，“活”表大约有 4 亿行。显然存档表会随着时间的推移而增加，但我希望活动表也能合理快速地增加。至少在接下来的几年里说 50%。

我曾考虑过 Azure 扩展数据库，但不幸的是我们在 2008 R2 并且可能会在那里停留一段时间。

当前计划

• 创建一个新的数据库
• 在新数据库中创建按月（使用修改日期）分区的新表。
• 将最近 12-13 个月的数据移动到分区表中。
• 对两个数据库进行重命名交换
• 从现在的“归档”数据库中删除移动的数据。
• 对“归档”数据库中的每个表进行分区。
• 将来使用分区交换来归档数据。
  • 我确实意识到我必须换出要存档的数据，将该表复制到存档数据库，然后将其交换到存档表中。这是可以接受的。

问题： 我正在尝试将数据移动到初始分区表中（实际上我仍在对其进行概念验证）。我正在尝试使用 TF 610（根据数据加载性能指南）和一个INSERT...SELECT语句来移动数据，最初认为它会被最少记录。不幸的是，每次我尝试它都被完全记录。

在这一点上，我认为我最好的选择可能是使用 SSIS 包移动数据。我试图避免这种情况，因为我正在处理 200 个表，并且我可以通过脚本轻松生成和运行任何我可以做的事情。

我的总体计划中是否遗漏了任何内容，SSIS 是快速移动数据和最少使用日志（空间问题）的最佳选择吗？

没有数据的演示代码

-- Existing structure
USE [Audit]
GO

CREATE TABLE [dbo].[AuditTable](
    [Col1] [bigint] NULL,
    [Col2] [int] NULL,
    [Col3] [int] NULL,
    [Col4] [int] NULL,
    [Col5] [int] …

继续我在上发布的一个问题，将高容量和高访问率的表移动到单独的数据库是个好主意吗？，我正在寻找可用于 PostgreSQL 数据库归档的不同技术/解决方案。

我能想到的几个解决方案是：

1. 表分区
2. 单独的表空间和/或模式
3. 将存档的记录/表移动到不同的硬盘

任何其他建议/指针/解决方案都非常受欢迎和赞赏。

注意：我们在 CentOS5.2 上运行 PostgreSQL v9.1.3

设想：

我们有两个表Tbl1&Tbl2在订阅服务器上。在Tbl1正在从出版商复制的Server A，它有两个触发器-插入和更新。触发器将数据插入和更新到Tbl2.

现在，我们必须清除（大约 9 亿条记录），Tbl2其中总共有 1000+ 万条记录。下面是一个月到一分钟的数据分布。

• 一个月 - 14986826 行
• 一天 - 483446 行
• 一小时 - 20143 行
• 一分钟 - 335 行

我在找什么；

在没有任何生产问题、数据一致性和可能没有停机时间的情况下清除该数据的最快方法。所以，我想按照以下步骤操作，但卡住了:(

脚步：

1. BCP 从现有表 Tbl2 中取出所需的数据（大约 1 亿条记录，可能需要大约 30 分钟）。
   • 假设我在 1Fab2018 晚上 10:00 开始做活动，它在 1Fab2018 晚上 10:30 结束。到活动完成时，表 Tbl2 将获得成为 delta 的新记录
2. 在数据库中创建一个名为 Tbl3 的新表
3. 导出数据中的 BCP 到新创建的表 Tbl3（大约 1 亿条记录，可能需要大约 30 分钟）
4. 停止复制作业

5. 一旦 BCP-in 完成，使用 tsql 脚本插入新的增量数据。

6. 挑战是 -如何处理增量“更新”语句？ …

我们将在接下来的几周内在我们的生产环境中实施日志传送。

我们每月执行一次数据库“清理”，将数据库设置为SIMPLE恢复模式，将记录复制到历史数据库，然后从原始数据库中删除以释放空间。

我知道将数据库恢复模型更改为 simple 会破坏日志传送（因为 LSN 链会被破坏）。在这种情况下，我必须在辅助服务器上恢复完整备份并重新开始日志传送过程。我不想这样做。

我是一个“偶然的 DBA”，继承了这个归档过程。该过程就像从实时数据库中选择行，将它们插入存档数据库，然后从实时数据库中删除它们一样简单。

我担心的是，如果我在删除过程中将数据库保持在完整恢复模式中，事务日志可能会以这样的方式增长，从而可能导致空间问题和/或使辅助服务器大大落后于主服务器。

我在这里有哪些选择？任何建议将被认真考虑。

最近我们有一个超过 1 TB 的审计数据库，由于我们有存储问题，管理层正在寻找选择。

我的建议是在每年年底我们进行备份并截断所有表，以保持数据库的可管理性。

拥有存档数据库不会有好处，因为它会再次消耗相同的空间。

我想对我可以向管理层提出的选项提出专家意见，即每年分配更多空间或截断整个数据库。

您好，我是 Oracle 数据库新手。使用Oracle 11g R2

我想知道在归档日志目标创建的归档日志的用途，以及它们对数据库备份有何帮助。

假设我将生产数据库备份到“2014 年 9 月 15 日”，并且我想将开发数据库数据恢复到“2014 年 9 月 20 日”，如何使用备份文件和存档日志恢复数据。

我们从开发组那里得到了一个要求，要执行以下操作：

• 经常（每 30 分钟）将事务数据从实时数据库移到另一个数据库
• 辅助数据库将用于 Ad-Hoc 查询和报告
• 如果数据从实时数据库中删除，他们不想从这个辅助报告数据库中删除数据

我们的数据库服务器在 SQL Server 2012 企业版上。

这将确保最终用户不会查询实时数据，从而导致阻塞问题。开发人员将在不久的将来致力于获取分析数据，但他们希望快速实施一些措施以使实时数据尽可能小。

实现这一目标的建议是什么？

谢谢，

生命值

我有一张包含 100 万条记录的表格。每次针对每种类型的事件（有很多）发生事件时，每天都会创建和更新新记录。我经常需要在许多记录中找到总和，并且执行这些查询的时间逐渐变慢，即使在某些地方有多个索引。由于现在存储了几年的数据，我正在考虑将超过 6 个月的记录迁移到单独的“存档”表，并为每个事件类型创建新记录，其中包括每月聚合（即行的总和）在 2014 年 1 月存储的 31 条记录中，将存储在 1 条记录中）。这有望提高搜索速度，但有更好的策略吗？这种归档方式常见吗？

我们在 SQL Server 2008 R2 标准服务器中有一个非常大的表，我通过将它们复制到单独磁盘上的另一个数据库中来存档行，然后使用 SSIS 数据流从原始表中删除它们。该表有一个 bigint 主键，并且正在按照该键的数字顺序删除行。然而，当我删除行时，表的整体索引大小正在稳步增加，我不知道为什么。在整个过程中，数据大小保持不变。

以下是表的详细信息：

行数：~300,000,000
数据大小：~65 GB
索引大小：~65 GB

行正在以每小时约 350,000 的速度被删除。

列定义使用以下数据类型：smallint、int、bigint、char、varchar、nvarchar、uniqueidentifier、bit、datetime

该表有一个主键，即表上的聚集键以及 4 个非聚集索引。

该表也是复制维护计划的一部分。表的复制副本的数据大小和索引大小都在减少！

上周我在另一个表上执行了相同的过程，当我删除行时，我可以看到该表的数据大小和索引大小都在减少。

在这种情况下，是否有任何解释为什么索引大小会不断上升？

我想知道我们使用的任何数据库中存档和清除之间的主要区别。

我无法访问分区功能，但考虑一个支持工单系统，每天打开数万张工单，解决问题需要大约一周到几个月的时间。显然，如果我从一开始就试图将它们全部放在一张桌子上，那么这张桌子就会变得很大。

我的问题是：

1. 一旦票得到解决，我是否应该将其移出原始表？或者
2. 我是否应该在 90 个月后将已解决的票从原始表中移出？或者
3. 我是否应该在 90 个月后将所有已解决或未解决的内容移动到另一个表中，并在UNION 每次寻求未解决的查询时执行某种操作？

切换到存档模式（从循环模式到将存档日志保存在磁盘上）后，我们有 C0000000 文件夹，其中复制了存档日志。现在我注意到创建了文件夹 C0000001、C0000002、C0000003 和 C0000004，其中 C0000001 和 C0000002 和 C0000003 只有一个日志文件。存档日志不断进入 C0000004 子文件夹。

这些文件夹的创建时间是一些随机时间（例如不是执行在线备份的时间）。

为什么会创建这些 C000000x 文件夹，这是常规行为还是我们应该关注？

谢谢

目前，我们的数据库服务器中有一个大约有 20 列（其中一列是 timestamptz 数据类型）的表，该表有 8.34 亿行。就大小而言，这是一个很大的表（大约 250GB（包括索引等）。

我想找到最有效和最好的方法来删除超过 2 年的旧数据，但如果我们需要它用于报告目的，也可以定期保留这些数据，该表也有 FK 约束。

处理这个问题的最佳方法是什么？我们希望能够在需要时查看这些数据。可能位于也可能不在同一服务器上。

最好首先运行选择数据的 COPY

COPY (SELECT * FROM TABLENAME WHERE CAST((timecreated_on AT TIME ZONE 'GMT') AS date) > DATE '2020-01-01 00:00:01') TO '/path/to/a/dump/file';

那么删除表中的数据呢？

DELETE FROM TABLENAME where CAST((timecreated_on AT TIME ZONE 'GMT') AS date) > DATE '2020-01-01 00:00:01'

我只是在寻找一种方法，这是一个自动化的过程，我可以通过 Linux 服务器上的 cronjob 安排每年之后删除超过 1 年的数据。

知道这可能不是最好的方法，但需要查看如何管理 FK 键约束，我是否会删除它们并重新应用，这可能会导致数据完整性问题？

任何帮助深表感谢。