在V$LOGMNR_CONTENTS字典视图中TIMESTAMP和COMMIT_TIMESTAMP列是DATE数据类型 - 没有任何时区信息。那么它们位于哪个时区 - 数据库时区、主机时区还是 UTC？是否有数据库参数来配置他们的时区？
问问题
301 次
2 回答
2
我猜这是数据库服务器操作系统的时区。仅仅因为SYSDATE可能用于插入的哪个也可以在数据库服务器操作系统的时区中返回。
也许 Oracle出于历史原因使用DATE数据类型而不是数据类型。TIMESTAMP我不知道什么时候TIMESTAMP介绍的，但肯定DATE来得更早。
于 2020-06-24T11:56:22.540 回答
1
当对 V$LOGMNR_CONTENTS 视图执行 SELECT 语句时，归档重做日志文件将按顺序读取。这些归档重做日志文件是归档日志目标中存在的文件。来自重做日志文件的翻译记录在此视图中作为行返回。这将一直持续到满足启动时指定的过滤条件（EndTime 或 endScn）或到达归档日志文件的末尾。
字段 TIMESTAMP 是进行数据库更改时的时间戳。此时间戳对应于 SCN 转换 SCN_TO_TIMESTAMP，因此对于给定的 SCN，您有一个对应的时间戳。
COMMIT_TIMESTAMP 字段是事务提交时的时间戳；只有在 DBMS_LOGMNR.START_LOGMNR() 调用中选择了 COMMITTED_DATA_ONLY 选项时才有意义。如您所知，查询重做日志和归档日志需要您在日志挖掘器会话中调用此包。
实际上，Oracle 有时会使用 DATE 数据类型，而它可能应该在许多不同的字典字段中使用 TIMESTAMP。为什么 ？老实说，我不知道，当它们用于某些字典视图所有者、其他 table_owner 和其他 owner_name 时是一样的。
DBTIMEZONE 在 CREATE DATABASE 语句中指定，因此在您创建数据库的那一刻。您可以使用 ALTER DATABASE 更改 DBTIMEZONE
alter database set time_zone = 'EST';
请记住，更改数据库时区只会在关机/启动后生效，不建议这样做。
TIMESTAMP WITH TIME ZONE 是 TIMESTAMP 的变体，其值中包含时区区域名称或时区偏移量。时区偏移是本地时间和 UTC（协调世界时，以前的格林威治标准时间）之间的差异（以小时和分钟为单位）。
当数据存储在磁盘上时，Oracle 数据库会将所有新的 TIMESTAMP WITH LOCAL TIME ZONE 数据规范化到数据库的时区。Oracle 数据库不会自动将数据库中的现有数据更新到新的时区。因此，如果数据库中有任何 TIMESTAMP WITH LOCAL TIME ZONE 数据，则无法重置数据库时区。您必须先删除或导出 TIMESTAMP WITH LOCAL TIME ZONE 数据，然后重置数据库时区。因此，Oracle 不鼓励您更改包含数据的数据库的时区。
我的案例示例：我在 Azure 中有一个 Oracle 数据库（所有服务器都使用 UTC） 在我的案例中，我选择使用 UTC 而不是使用不同的 DBTIMEZONE。然后我创建了一个函数来将存储在任何表中的任何时间戳转换为我的时区。
我想知道为什么你需要阅读重做/归档日志，你必须恢复一些丢失的事务吗？我希望解释是令人满意的，请不要犹豫发表评论或询问您可能有的任何其他疑问。
于 2020-06-22T16:52:30.857 回答