为啥ogg格式删除不了，或者删除时间长

原创已于 2024-03-21 16:00:41 修改 · 1.7k 阅读

24 ·

CC 4.0 BY-SA版权

文章标签：

#microsoft

于 2024-03-21 15:59:31 首次发布

文章讲述了在Windows系统中，如果遇到ogg格式文件无法删除或导致资源管理器卡顿的问题，可以通过卸载WEB媒体扩展应用来解决，具体步骤涉及在Windows设置中找到并移除相关软件。

这里写自定义目录标题

为啥ogg格式删除不了，或者删除时间长
若不需要使用，可在 Windows 设置 - 应用 - 应用和功能将其卸载WEB媒体扩展软件，即可解决 OGG 文件导致资源管理器未响应的问题
在这里插入图片描述

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

empe_lee

关注关注

7
点赞
踩
24

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

OGG的mgr进程删除trail文件失效

FC_BarceIona的博客

04-10

1504

环境描述：系统：HP-UX 数据库：oracle 11gR2 11.2.0.4.0 OGG版本：11.2.1.0.33 故障描述： mgr配置的purgeoldextracts删除策略失效，源端有几个一个失效的trail文件一直未被删除。故障原因：源端的抽取进程产生的trail文件和对于的投递进程在目标段产生的trail文件同名都为./dirda...

OGG 手动删除trail文件

leo__1990的博客

06-13

3453

1. OGG手动删除trail文件 OGG mgr定期清理trail 文件可参考以下链接https://www.cndba.cn/leo1990/article/2853 1.1. 查看源端trail文件信息 GGSCI (cndba) 45> INFO EXTTRAIL * Extract Trail: ./dirdat/et Extra...

参与评论您还未登录，请先登录后发表或查看评论

windows碰到ogg文件无法正常删除

2403_89815416的博客

04-16

242

无法删除ogg文件

ogg不能自动删除trail文件解决一例

bigger王的博客

06-22

2561

问题描述：巡检的时候发现ogg挂的gg目录使用率85%了，经排查发现是ogg不能自动删除trail文件导致目录使用率告警。 [oracle@host01 ~]$ df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/ggvg-lv_gg 468G 375G 70G 85% /gg /dev/sda1 194M 33M 152M 18% /boot gg目录...

oracle ogg删除进程,删除ogg 无法删除的进程

weixin_33286064的博客

04-07

1894

之前不知道是谁添加的进程，在抽取里面添加了R进程，参数文件已经被删除了，但是info all 还是能看到进程在，无法删除报错表或者视图不存在 10046 发现执行下面的sql，但是数据库里面就根本没有这个表SELECT count(*) FROM dba_goldengate_inbound WHERE server_name = :1 and rownum = 1GGSCI (orcl...

ogg配置自动删除队列，重新同步数据

三朝看客

01-18

1329

配置自动删除队列进入安装目录执行./ggsci；执行edit param mgr编辑管理进程参数，加入或修改以下行 purgeoldextracts /<goldengate安装目录>/dirdat/*, usecheckpoint, minkeepdays 7 其中，第一个参数为队列位置，*可匹配备份中心所有队列文件；第二个参数表示是首先要保证满足检查点需要，不能删除未处理队列；第三个参数表示最小保留多少天，后面的数字为天数。例如，如果希望只保留队列/ggs/dirdat

【音乐文件格式深度解析】：为什么华为荣耀手机偏爱OGG格式

![华为荣耀手机内置铃声OGG格式]...特别对OGG格式进行了详解，从其起源、特点到编码原理，再到实际应用案例，揭示了OGG格式在不同设备上的表现和在流媒体平台的应用。进一步探讨了华为荣耀手机与OGG

如何保证ogg抽取进程不丢归档

myy10146的专栏

10-30

1822

Oracle Goldengate是绝佳的数据实时同步工具，支持各种数据库和常用平台。OGG本身的灵活性加上其内置的大量函数，可以满足DBA各种同步、过滤、转换需求。在OGG的同步逻辑中，数据的来源是数据库的增量日志（对于oracle数据库就是archivelog)。在实际运维中各类故障都好处理，但是一旦源端的归档日志被前提删除，抽取进程报找不到归档日志，这将是特别棘手的问题。特别是归档日志无备份直接delete的情况，简直是运维人员的恶梦！哪些情况OGG抽取进程需要旧的归档日志呢：抽取进程aben

Oracle GoldenGate（OGG）- 超级详细

热门推荐

erainm

10-30

3万+

1. OGG简介 2. 应用场景 3. 基本原理 4. 基本架构 5. 常用的拓扑结构 6. 支持的环境 7. OGG安装部署 7.1 配置Oracle11gR2数据库 7.2 安装OGG源端 7.3 配置OGG源端 7.4 配置OGG目标端 7.5 OGG测试 8. 初始化业务数据 8.1 安装OGG源端 8.2 配置OGG源端 8.3 配置OGG目标端 8.4 OGG测试

OGG报错 OGG-01151映射失败参数dynamicresolution和getupdatebefores对数据同步的影响分析！

Jackyimi的博客

08-21

803

当 OGG 19c 抽取进程因 dynamicresolution和 getupdatebefores组合突报 OGG-01151 错误，本文直击表级补充日志配置陷阱，通过系统性四步排查法锁定元数据缺陷，并给出根治方案。DBA 避坑必读！

创建与处理处理删不掉的文件夹大全

11-28

一。创建一个打不开删不掉的文件夹\如何删除删不掉的文件夹二、建一个不带"." 功能与带"." 的"bug文件夹"。三。如何删除及批处理删除

如何清理ogg日志文件

beiduofen2011的专栏

11-09

2944

进入目标端ogg文件目录，/usr/local/ogg/dirdat，删除hr000009674之前的文件，不要都全部删掉，最好保留5-6个最新文件。ogg分为源端和目标端，由于目标端和kafka部署在一机器上，ogg日志文件使这台机器磁盘频繁的被占满，导致kafka 进程被杀死。之前配置的是3天就把已经完成推送的日志给删除，现在改成1小时就把已经完成推送的日志给删除。接下来的话 ./dirdat/* 日志文件就不会频繁的把磁盘占满了。其中一个文件500M。可以看到消费到哪个文件。

win10一些文件总是删不掉

qq_46570737的博客

04-17

1316

很多时候我们会遇到想删除某些文件但是又删除不了。显示需要管理员权限，授权后又提示需要什么什么权限进行更改，遇到这种情况就非常的烦恼。提供解决因every one权限无法删除文件的方法。 1.选择要删除的文件，右键选择属性，点击属性框的安全一栏。 2.选择组或用户名的SYSTEM，点击高级 3.进入改高级安全设置，点击更改。 4.在编辑框输入E，点击检查名称。 5.编辑框会弹出Everyone的对象名称，点击确定。 6.选择“替换子容器和对象的使用者所有者”、“禁用继承”、“使用可以从此对象集成继承的权限

oracle ogg 删除,OGG导致归档无法RMAN删除一例

weixin_39564527的博客

04-08

806

用户的SIEBEL RAC系统中配置了OGG 11.1.1.1.2 ，在最近发现备份脚本未正常将归档日志备份后删除掉，示例日志如下：iece handle=al_18090002_1_848331814 tag=TAG20140523T154330 comment=API Version 2.0,MMS Version 5.0.0.0channel ch00: backup set complet...

OGG-卸载

Expec-乐的博客

02-14

3469

1.停止所有进程 stop * stop mgr 2. 删除OGG目录 rm -rf /u01/app/oracle/ogg 3.删除用户，触发器删除触发器 drop trigger ggs_ddl_trigger_before; 删除用户 drop user ogg cascade; 如果报错： SQL> drop user ogg cascade; drop user...

问题：删除 ogg 用户的时候报错

没刮胡子的程序员专栏

04-13

486

问题描述删除用户报错 SQL> drop user ogg cascade; drop user ogg cascade * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 2 ORA-20782: Oracle GoldenGate DDL Replication Error: Code :ORA- 20...

2020-11-20 OGG无法自动清理trail文件问题的解决

weixin_37650796的博客

11-20

3482

OGG自动清理trail文件

删除OGG用户的时候，提示ORA-00604,ORA-20782,ORA-06512等错误

文档搬运工

11-07

1069

之前有一环境配置了OGG，现在做测试，需要把之前的OGG相关信息干掉。在删除ogg帐号的时候，发现提示有一些错误 SYS@test>drop user ggs cascade; drop user ggs cascade * ERROR at line 1: ORA-00604: error occurred at recursive SQL level 2 ORA-20782: O...

删除Ogg用户报ORA-00604、ORA-20782、ORA-20782、ORA-06512错误的解决方法

weixin_40913898的博客

01-13

1876

删除Ogg用户报ORA-00604、ORA-20782、ORA-20782、ORA-06512错误的解决方法一、背景搭建了一套ogg进行数据同步，并开启了DDL功能，后来因为不需要使用ogg，想将数据库里的ogg用户删除掉，结果删除报以下错误： SQL> drop user ogg cascade; drop user ogg cascade * 第 1 行出现错误: ORA-00604: 递归 SQL 级别 2 出现错误 ORA-20782: Oracle GoldenGate DDL Rep

ogg 删除归档报RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process

最新发布

11-20

<think> 我们正在处理一个关于OGG（Oracle GoldenGate）删除归档日志时出现RMAN-08137警告的问题。根据引用内容，这个警告通常发生在归档日志被标记为需要用于备用数据库（Standby）或上游捕获进程（upstream capture process）的情况下，因此RMAN不允许删除。从引用[3]中我们得知，在Oracle 12c中，由于修复了bug16082541（RMAN删除尚未应用到延迟备用数据库的归档日志），行为发生了变化。因此，我们需要检查归档日志是否仍然被备用数据库或捕获进程需要。引用[4]提供了一个查询v$managed_standby视图的方法，以查看当前备用数据库的应用状态。我们可以通过这个视图确认是否有进程正在使用这些归档日志。但是，请注意用户的问题是关于OGG的。在OGG环境中，可能有Extract进程（捕获进程）正在读取归档日志，因此RMAN不允许删除。我们需要确认OGG的抽取进程是否还在使用这些归档日志。解决方案步骤： 1. **确认归档日志是否被OGG Extract进程需要**： - 检查OGG的Extract进程是否配置为从归档日志中捕获数据。如果是，并且这些归档日志还没有被处理完，那么就不能删除。 - 使用OGG命令查看Extract进程的状态，确认它正在读取的归档日志序列号。 2. **检查备用数据库（如果有）**： - 如果环境中有备用数据库（如Data Guard），那么需要确保归档日志已经应用到备用数据库。可以通过引用[4]中的查询来检查备用数据库的应用状态。 3. **手动删除归档日志**： - 如果确认归档日志不再需要（即已经应用到备用数据库并且OGG Extract进程已经处理过），但RMAN仍然不让删除，可以考虑使用`DELETE FORCE`选项（但需谨慎）。 - 例如：`RMAN> DELETE ARCHIVELOG ... FORCE;` 4. **调整OGG Extract进程**： - 如果问题是由于OGG Extract进程读取归档日志较慢，导致积压，可以考虑优化Extract进程的性能，或者增加归档日志保留策略的时间。 5. **调整RMAN保留策略**： - 设置RMAN的保留策略，使其保留足够长时间的归档日志以供OGG使用。例如：`CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;` 6. **使用OGG的`PURGEOLDEXTRACTS`参数**： - 在OGG的Manager参数文件中设置`PURGEOLDEXTRACTS`参数，可以自动清理已经被处理过的归档日志。这样，当OGG处理完归档日志后，会标记为可删除。然而，引用中提到的查询是针对Data Guard的，我们需要针对OGG进行查询。在OGG中，我们可以使用以下命令查看Extract进程的状态： ```sql GGSCI> INFO EXTRACT <extract_name>, DETAIL ``` 在输出中，我们可以查看`Current Log Read`部分，它显示了当前正在读取的归档日志的序列号。另一种方法：在数据库中查询OGG Extract进程的会话信息，看看它们当前打开的归档日志文件。注意：在OGG中，如果Extract进程配置为从归档日志中读取，那么它会保持归档日志文件处于打开状态，直到处理完毕。因此，我们需要确保这些归档日志已经被处理完。如果确定归档日志不再需要，但RMAN仍然不允许删除，可以尝试以下命令强制删除： ```sql RMAN> DELETE ARCHIVELOG ALL FORCE; ``` 但是，强制删除可能会导致数据丢失或OGG抽取失败，因此务必谨慎。另外，引用[3]提到这是Oracle 12c的一个功能变更。如果环境是12c或更高版本，那么需要确保在删除归档日志之前，它们已经被应用到备用数据库（如果有的话）并且OGG也已经处理完毕。总结步骤： 1. 检查OGG Extract进程的状态，确认其已经处理完要删除的归档日志。 2. 如果有备用数据库，检查日志应用是否已经完成（通过v$managed_standby视图）。 3. 如果确认不再需要，尝试使用RMAN的`DELETE FORCE`命令（谨慎使用）。 4. 调整RMAN保留策略，确保保留足够时间供OGG使用。 5. 在OGG中配置自动清理参数（如`PURGEOLDEXTRACTS`）。由于用户的问题是针对OGG的，我们重点放在OGG的检查上。下面，我们将提供详细的解决步骤。 </think>### 解决OGG删除归档时报错 RMAN-08137 的方法当OGG删除归档日志时出现`RMAN-08137: WARNING: archived log not deleted, needed for standby or upstream capture process`警告，说明归档日志被备用数据库或上游捕获进程（如OGG Extract）标记为仍需使用。以下是系统化的解决方案： #### 1. **确认归档日志使用状态** ```sql -- 查询备用数据库日志应用状态 SELECT PROCESS, STATUS, SEQUENCE#, THREAD#, BLOCK#, BLOCKS FROM V$MANAGED_STANDBY WHERE STATUS LIKE 'APPLYING%'; ``` - 若`STATUS`显示`APPLYING_LOG`且`BLOCK#`持续变化，表示备用库仍在消费日志[^4] - 若`SEQUENCE#`显示日志号，说明该序列日志尚未应用完成 #### 2. **检查OGG Extract进程状态** 在OGG命令行执行： ```bash GGSCI> INFO EXTRACT <extract_name>, DETAIL ``` 关注输出中的： ``` Current Log Read Checkpoint # 当前读取的归档日志序列号 Redo Flags # 是否依赖归档日志 ``` 确认Extract是否仍在读取目标归档日志[^1] #### 3. **解决方案** ##### 方法一：等待进程完成消费 - 当备用库完成日志应用或OGG Extract处理完日志后，RMAN会自动允许删除 - 通过以下脚本监控进度： ```sql -- 监控日志应用差距 SELECT ARCH.THREAD# "Thread", ARCH.SEQUENCE# "Last Archived", APPL.SEQUENCE# "Last Applied" FROM (SELECT THREAD# ,SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1) ARCH, (SELECT THREAD# ,SEQUENCE# FROM V$LOG_HISTORY) APPL WHERE ARCH.THREAD# = APPL.THREAD#; ``` ##### 方法二：强制删除归档（谨慎使用） ```sql RMAN> DELETE ARCHIVELOG SEQUENCE <seq#> THREAD <thread#> FORCE; ``` > **警告**：仅确认日志不再需要时使用，否则可能导致数据丢失[^3] ##### 方法三：调整保留策略 ```sql -- 设置RMAN保留窗口为更短时间 CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS; ``` #### 4. **OGG配置优化** 在Extract参数文件中添加： ```properties TRANLOGOPTIONS EXCLUDEUSER ggs_admin # 排除特定用户减少日志量 TRANLOGOPTIONS MINEFROMACTIVEDG # 优先使用在线日志 ``` #### 5. **归档空间紧急处理** 若空间不足需立即清理： ```sql -- 释放已应用的归档 ALTER DATABASE CLEAR UNARCHIVED LOGFILE GROUP <group#>; ``` ### 根本预防措施 1. 启用OGG自动清理： ```properties -- manager.prm 添加 PURGEOLDEXTRACTS /ogg/dirdat/*, USECHECKPOINTS, MINKEEPHOURS 4 ``` 2. 配置Data Guard实时应用： ```sql ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT; ``` 3. 增加归档目标空间或添加多路归档路径 > **关键点**：该报错本质是保护机制，确保日志在被下游消费前不被删除。通过`V$ARCHIVED_LOG.APPLIED`和`V$MANAGED_STANDBY`状态确认日志消费进度是核心解决思路[^2][^3]。