错误

尝试删除包含无效时间戳的元组

DELETE FROM comments WHERE date > '1 Jan 9999' OR date < '1 Jan 2000' OR date_found > '1 Jan 9999' OR date_found < '1 Jan 2000';

结束于

ERROR:  attempted to delete invisible tuple

有一个 2009 年的邮件列表讨论了完全相同的错误消息，OP 修复了它，但我没有找到关于他是如何做到的或可能导致此错误的原因的解释。

由于谷歌搜索量不足以及我对 PostgreSQL 的了解有限，我很无助。

是什么导致了腐败

我在 Debian 8 上运行了 PostgreSQL 9.5.5 服务器（~4TB 数据，所有默认设置，内存限制除外），当时操作系统内核崩溃了——可能是在重建 /dev/md1 时交换所在的位置。在此之前，PostgreSQL 用一个 400GB 的日志文件吃光了几乎所有的磁盘空间。操作系统再也没有启动过，磁盘检查没问题，所以我从 LiveCD 启动并将每个块设备备份到映像，以防万一。我已经成功地从 /dev/md2 重建了 / 目录，fsck 显示了一个干净的文件系统，并且我已经将 PGDATA 文件夹备份到了一个外部硬盘上。

我做了什么来尝试恢复

在我格式化 md 设备并重新安装操作系统和新的 postgresql-9.5 之后，我停止了 PostgreSQL 服务器，将 PGDATA 文件夹移动并更改为 …

（幸运的是，我们目前并未处于这种情况，只是提前计划，看看如果发生这种情况，我们的选择是什么。）

对于使用透明日期加密 (TDE) 加密的数据库，除非您有用于加密它的证书的备份，否则数据库备份的副本是不可恢复的。

如果你没有那个怎么办？还有其他选择吗？

如果整个服务器发生故障，在新硬件上恢复 MASTER 数据库的备份是否也会恢复证书？

我正在审查我们公司的 DR 程序，当我在网上查找 Always On 群集丢失仲裁的解决方案时，进行比较。在找到关于集群与事务复制与可用性组主题的第一篇 SE 帖子之前，我在谷歌搜索结果中翻了三页，该帖子仅略微涉及丢失法定人数的主题。

虽然每个人都同意失去法定人数是糟糕的，并且有一些降低潜力的建议，但它仍然可能发生。我正在寻找一个经过同行评审的良好答案，以了解从 Always On 集群仲裁丢失中恢复的最佳途径。

犯了一个错误，错误地为 tempdb 输入了一个更改数据库命令。

现在实例不会启动。我无法使用 -m 在单用户模式下启动，因为它指出找不到 tempdb。我尝试使用：

net start msqsqlserver /f /t3608

但是我实际上根本无法使用sqlcmd或连接到实例ssms。

我使用 pg_upgrade（就地）升级了 Postgres DB 9.3.2-->10.5。我根据文档和 pg_upgrade 给出的说明做了一切。一切顺利，但后来我意识到索引没有在其中一个表中使用（也许其他表也受到影响）。

所以我ANALYZE昨天在那个桌子上开始了一个仍在运行的桌子上（超过 22 小时）......！

问题：ANALYZE执行时间这么长正常吗？

该表包含大约 30M 条记录。结构是：

CREATE TABLE public.chs_contact_history_events (
    event_id bigint NOT NULL
           DEFAULT nextval('chs_contact_history_events_event_id_seq'::regclass),
    chs_id integer NOT NULL,
    event_timestamp bigint NOT NULL,
    party_id integer NOT NULL,
    event integer NOT NULL,
    cause integer NOT NULL,
    text text COLLATE pg_catalog."default",
    timestamp_offset integer,
    CONSTRAINT pk_contact_history_events PRIMARY KEY (event_id)
);

ALTER TABLE public.chs_contact_history_events OWNER to c_chs;

CREATE INDEX ix_chs_contact_history_events_chsid
    ON public.chs_contact_history_events USING hash (chs_id)
    TABLESPACE pg_default;

CREATE INDEX ix_chs_contact_history_events_id
    ON …

我们的所有生产数据库都采用简单恢复模型，对此我们感到非常高兴，因为它完全满足我们的 RPO 和 RTO。

现在我们想为我们的数据库实施 AG DR 解决方案，我们发现完全恢复模型是一个要求。

我的问题是为什么？从理论上讲，AG 或其他 SQL Server DR 解决方案（日志传送、数据库镜像）不应该与简单恢复模型一起使用是否存在任何技术原因？

我找不到有关是否可以备份 SQL Server 中的代理作业的文档。如果没有，我如何备份它们以便在将来发生实例故障时恢复？

我有一个客户，他拥有一个现有的 1.5Tb 数据仓库，目前正计划在新环境中完全更新 DW。他们的基础架构经理组织了 2 个服务器，每个服务器都采用 SQL 2017 标准，现在要求我为新的 DW 数据库/实例规划一个 HA/DR 计划。

我立即想到了使用 AlwaysOn 可用性组，尽管我以前从未使用过它们，而且我读过的文章都没有讨论典型的数据仓库工作负载——都是 OLTP 应用程序。在当前 DW 上运行大型每日 ETL 流程和较小的日内 ETL 流程时，这是否会影响我们处理此问题的方式？

谢谢 - 在这里为我指明正确方向的任何帮助都是有益的！

建议我的 DR 计划的最佳方法。目前我们有一组数据库 (6) 用于我们的应用程序，我们正在构建 DR 和 HA 计划。由于我们是小型企业，我们使用的是 2012 年标准版，因此无法使用 AG 功能。

谢谢你的帮助。

我们不小心删除了rm -rf /data/db 我们的MongoDB 路径目录，多亏了 extundelete，我们恢复了它并得到了目录/data/db。

这是我们在目录中的文件，文件是在 MongoDB 3.4 版本下生成的。

文件夹diagnostic.data：

文件夹journal：

第 1 步：尝试正常运行 mongod

a)我们运行mongod --port 27017 --dbpath /data/db --bind_ip_all和mongo，并期望应该有一个用户定义的数据库wecaXX，但是，它没有出现。

> show dbs
admin   0.000GB
config  0.000GB
local   0.000GB

在 Robo3T 中

b)然后我尝试运行mongod --port 27017 --dbpath /data/db --bind_ip_all --repair. 结果是：

2019-03-25T14:10:02.170+0800 I CONTROL  [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2019-03-25T14:10:02.191+0800 …