达梦delete没有物理删除数据

达梦数据库里啊，关于删数据的操作，得说个事儿。
用DELETE语句删除数据，它其实是个“温柔”的操作，默认是逻辑删除。
啥意思呢？就是你在数据库里标记这条数据是“已删除”的状态，但并没有真的把它从硬盘上抹掉。
这些被标记的数据啊，其实还老老实实待在数据库里，只不过你用普通的SELECT语句去查的时候，是看不到它们的。

这么做的好处还挺多的。
首先能保证整个数据库的数据保持完整和一致，不会因为删数据而出岔子。
其次呢，万一以后发现删错了，或者需要查个之前的记录做审计，这些“已删除”的数据还能找回来，挺方便的。

那要真想彻底把数据给干掉，不留任何痕迹怎么办呢？这时候就得用TRUNCATE或者DROP这两个语句了。
TRUNCATE呢，是让你把表里的所有数据“哗”一下全给清空，但是表这个“容器”本身还在。
而DROP呢，那就厉害了，它不光能把表里的数据全删，连带着表的结构也一起给删得干干净净，彻底消失。

达梦数据库main.dbf怎么清理

哈喽小伙伴们，今天来聊聊达梦数据库里那个头疼的main.dbf文件清理问题。
咱们可以从几个实用的小技巧入手：
1 . 巧妙规划表空间：别让所有宝贝都堆在MAIN表空间里，给不同的业务数据单独建个“小屋”，这样管理起来才轻松，还能更好地把握磁盘空间。

2 . 用RESIZE来瘦身（但MAIN表空间不适用）：数据删除后，非MAIN表空间的文件大小可以用RESIZE命令来缩一缩，省下不少磁盘空间。
不过，MAIN表空间这个大招可能就不管用了。

3 . 数据搬家大法：如果MAIN表空间让磁盘爆满，那就来个数据大搬家。
先把数据导出来，然后关掉实例，再新建一个，把数据重新导入到新表空间里。

4 . 定期检查，定期清理：定期查查表空间，有问题早处理。
该删的表、索引就别客气，给磁盘来个“大扫除”。
要是只想清空数据，不图释放空间，TRUNCATETABLE或DELETEFROM命令就够用了。
但别忘记，这些只是清空数据，磁盘空间还是得自己动手来清理。

记得哦，操作前备份是必须的，以防万一。
不懂的地方，咱们就找专业的数据库大牛或达梦技术团队聊聊吧。

达梦什么时候会清理执行计划缓存

亲们，注意啦！达梦数据库在以下几种情况下会自动清除执行计划缓存哦：
1 ️⃣ 更新统计信息时：执行DBMS_STATS.GATHER_TABLE_STATS等命令收集统计信息，若参数设置不对，执行计划缓存会被清掉，这可是为了确保我们最新的统计数据准确反映数据分布，以便生成更妙的执行计划呢！
2 ️⃣ 手动清理：当小可爱们发现SQL执行不爽快，或者速度突然变慢时，可以手动清除缓存，试试看能否让查询性能恢复元气！
3 ️⃣ 数据迁移或大表调整后：比如数据迁移导致大表数据变动，或者优化了执行计划但速度依旧不理想，这时也可以考虑清除缓存，让数据库重新根据新的数据分布来优化查询。

小贴士：清除缓存虽好，但也要注意，它可能会导致之前编译好的SQL语句需要重新编译，可能会暂时影响性能。
所以，清理缓存时，可要选好时机，别在高峰期动手哦！
达梦数据库也贴心地提供了查看和导出执行计划的方法，还有PLNDUMP等工具，方便大家分析缓存中的SQL执行计划，更好地提升数据库性能哦！

达梦误删了表数据怎么恢复

如果不幸在达梦数据库里误删了表数据，别慌！跟着我这几步走，就能慢慢把数据给救回来啦！👇
第一步，赶紧看看咱们的数据库备份做得怎么样。
要是最近有全量和日志备份，那就太棒了，直接用备份恢复工具，跟着提示走，指定备份文件，选好恢复模式，就能开始修复啦！
第二步，要是没找到合适的备份，那也没关系。
只要你的数据库开启了归档模式，就可以用归档日志来恢复。
达梦数据库的日志分析工具超级方便，能帮你找到误删数据的具体时间点，然后从这个点开始往回恢复数据。

第三步，如果达梦数据库版本支持闪回功能，而且你之前开启了它，那就有福了！在指定的时间范围内，执行个闪回语句，数据库就能自动把表数据恢复到删除前的状态。

记得在动手恢复之前，先好好评估一下数据库的状态，测试一下恢复流程，别让正在运行的业务系统受到什么影响哦。
还有，以后可得加强备份策略的管理，别让这样的乌龙事件再发生啦！🙅‍♂️🙅‍♀️

dm通过归档日志找到删除数据

在达梦数据库里，要是想知道哪些数据被删了，可以通过归档日志来查。
主要得用DBMS_LOGMNR这个包，对归档日志做个“深挖”，把那些DDL、DML之类的操作给重构出来，这样就能找到你想知道的信息了。

具体操作步骤是这样的：首先得把数据库“挂”起来，用ALTER DATABASE MOUNT这个命令。
然后开启归档模式，执行ALTER DATABASE ARCHIVELOG。
接下来，得给归档日志加点配置，比如ALTER DATABASE ADD ARCHIVELOG 'DEST=/data/data5 /DAMENG/arch, TYPE=local, FILE_SIZE=1 02 4 , SPACE_LIMIT=2 04 8 0'。
最后，把数据库打开，用ALTER DATABASE OPEN。

还有一个参数得改一下，那就是RLOG_APPEND_LOGIC。
可以用SP_SET_PARA_VALUE(1 , 'RLOG_APPEND_LOGIC', 1 )这个命令来改。
这个参数的值可以根据你的需求来选，1 到4 不同值有不同的记录规则。

归档日志解析的部分是这样的：先创建一个测试表A，然后往里面插点数据，提交一下。
这样做的目的是为了模拟删除操作，方便后续的挖掘测试。
然后，可以用SELECT NAME, FIRST_TIME, NEXT_TIME, FIRST_CHANGE, NEXT_CHANGE FROM V$ARCHIVED_LOG这个命令来查看已有的归档日志信息。
接着，用DBMS_LOGMNR.ADD_LOGFILE(''/data/data5 /DAMENG/arch/ARCHIVE_LOCAL1 _0x7 4 E6 7 B6 4 _EP0_2 02 4 -1 0-1 2 _1 0-3 7 -1 0.log'')这样的命令来添加需要分析的归档日志文件。
你可以通过V$LOGMNR_LOGS这个视图来查看已经添加的归档日志信息。
然后，用DBMS_LOGMNR.START_LOGMNR(OPTIONS=>2 1 2 8 , STARTTIME=>TO_DATE('2 02 5 -01 -1 4 1 4 :3 5 :00', 'YYYY-MM-DDHH2 4 :MI:SS'), ENDTIME=>TO_DATE('2 02 5 -01 -1 4 1 4 :4 0:00', 'YYYY-MM-DDHH2 4 :MI:SS'))这个命令来挖掘特定时间段的日志。
最后，通过SELECT OPERATION_CODE, SCN, SQL_REDO等语句来查找相关的操作记录，这样就能找到删除数据的信息了。

不过，这里也有一些限制需要注意。
首先，日志类型有限制，DBMS_LOGMNR目前只支持对归档日志进行分析。
其次，配置归档后，还得把dm.ini中的RLOG_APPEND_LOGIC选项置为1 、2 、3 或4 ，不同值有不同的记录规则。
再就是环境限制，DMMPP环境下不支持DBMS_LOGMNR这个包。
最后，如果是DMDPC环境，使用DBMS_LOGMNR时，DBMS_LOGMNR.ADD_LOGFILE只能添加同一个节点的多个日志同时进行分析，不支持同时分析不同节点的日志。