远程数据恢复
  • 首页
  • 服务范围
  • 服务案例
  • 技术文章
  • 关于我们
  • 菜单 菜单
您现在的位置: 主页1 / Blog22 / Blog Multi Author
yzm

mongodb无法启动数据库恢复3

案例

odb无法启动数据库恢复  mongo数据库删除集合恢复  mongodb数据库误删除恢复

 
客户名称 保密
 
数据类型 mongodb 4.x
 
数据容量 15 GB
 
故障类型 用户误操作导致集合被删除,客户用数据恢复软件已经无法找到原始文件。
 
修复结果 使用极佳mongo数据库恢复工具从客户分区收集全部集合json数据完成恢复,恢复完整度接近100%
 
耗费工时 3 小时
 
深圳极佳数据救援中心友情提醒:重要数据一定要勤备份,遇到数据丢失 数据损坏 等问题,要第
 
一时间联系专业人士。对于各类主流数据库,我们可以做最底层的数据恢复及数据修复,对于数据库
 
的某些特定故障我们保证数据库100%原模原样恢复,无论多大的数据库都立等可取。

 

 

2026-10-19/由 yzm
https://www.recoverydata.cn/wp-content/uploads/2026/10/tst_10066.jpg 200 382 yzm https://www.recoverydata.cn/wp-content/uploads/2026/10/logo2-1.png yzm2026-10-19 21:39:322026-10-19 21:39:32mongodb无法启动数据库恢复3
yzm

mongodb无法启动数据库恢复 2

案例

odb无法启动数据库恢复  mongo数据库删除集合恢复  mongodb数据库误删除恢复

 
客户名称 保密
 
数据类型 mongodb 4.x
 
数据容量 15 GB
 
故障类型 用户误操作导致集合被删除,客户用数据恢复软件已经无法找到原始文件。
 
修复结果 使用极佳mongo数据库恢复工具从客户分区收集全部集合json数据完成恢复,恢复完整度接近100%
 
耗费工时 3 小时
 
深圳极佳数据救援中心友情提醒:重要数据一定要勤备份,遇到数据丢失 数据损坏 等问题,要第
 
一时间联系专业人士。对于各类主流数据库,我们可以做最底层的数据恢复及数据修复,对于数据库
 
的某些特定故障我们保证数据库100%原模原样恢复,无论多大的数据库都立等可取。

 

 

2026-10-19/由 yzm
https://www.recoverydata.cn/wp-content/uploads/2026/10/tst_10066.jpg 200 382 yzm https://www.recoverydata.cn/wp-content/uploads/2026/10/logo2-1.png yzm2026-10-19 21:39:192026-10-19 21:39:19mongodb无法启动数据库恢复 2
yzm

mongodb无法启动数据库恢复

案例

odb无法启动数据库恢复  mongo数据库删除集合恢复  mongodb数据库误删除恢复

 
客户名称 保密
 
数据类型 mongodb 4.x
 
数据容量 15 GB
 
故障类型 用户误操作导致集合被删除,客户用数据恢复软件已经无法找到原始文件。
 
修复结果 使用极佳mongo数据库恢复工具从客户分区收集全部集合json数据完成恢复,恢复完整度接近100%
 
耗费工时 3 小时
 
深圳极佳数据救援中心友情提醒:重要数据一定要勤备份,遇到数据丢失 数据损坏 等问题,要第
 
一时间联系专业人士。对于各类主流数据库,我们可以做最底层的数据恢复及数据修复,对于数据库
 
的某些特定故障我们保证数据库100%原模原样恢复,无论多大的数据库都立等可取。

 

 

2026-10-17/由 yzm
https://www.recoverydata.cn/wp-content/uploads/2026/10/tst_10066.jpg 200 382 yzm https://www.recoverydata.cn/wp-content/uploads/2026/10/logo2-1.png yzm2026-10-17 21:35:432026-10-18 19:56:54mongodb无法启动数据库恢复
yzm

oracle ASH与AWR性能调优脚本

ORACLE, 性能优化, 技术文章

ASH与AWR性能调优脚本

下面列出了一些我认为对性能调优非常有用的SQL查询。这些查询利用了Active Session History V$视图来获取当前的性能状况,同时还会使用DBA_HIST_* AWR历史表来获取过去某一时间段内的性能数据。

我想补充一点:这些查询语句是我根据从同事和同行那里获得的SQL脚本自行定制的。如果我的做法侵犯了任何人的版权,请告诉我,我会立即删除相关内容。另外,如果有人有类似且实用的开源脚本愿意分享给大家使用,也请发给我,我会把它们添加到这个页面上。

 

最近的等待事件排行

col EVENT format a60 

select * from (
select active_session_history.event,
sum(active_session_history.wait_time +
active_session_history.time_waited) ttl_wait_time
from v$active_session_history active_session_history
where active_session_history.event is not null
group by active_session_history.event
order by 2 desc)
where rownum < 6
/

自实例启动以来的最高等待事件数

col event format a60

select event, total_waits, time_waited
from v$system_event e, v$event_name n
where n.event_id = e.event_id
and n.wait_class !='Idle'
and n.wait_class = (select wait_class from v$session_wait_class
 where wait_class !='Idle'
 group by wait_class having
sum(time_waited) = (select max(sum(time_waited)) from v$session_wait_class
where wait_class !='Idle'
group by (wait_class)))
order by 3;

当前正在等待的用户列表

col username format a12
col sid format 9999
col state format a15
col event format a50
col wait_time format 99999999
set pagesize 100
set linesize 120

select s.sid, s.username, se.event, se.state, se.wait_time
from v$session s, v$session_wait se
where s.sid=se.sid
and se.event not like 'SQL*Net%'
and se.event not like '%rdbms%'
and s.username is not null
order by se.wait_time;

查找特定时间间隔内的主要数据库等待事件

首先确定所涉时段的快照ID值。

In this example we need to find the SNAP_ID for the period 10 PM to 11 PM on the 14th of November, 2012.

select snap_id,begin_interval_time,end_interval_time
from dba_hist_snapshot
where to_char(begin_interval_time,'DD-MON-YYYY')='14-NOV-2012'
and EXTRACT(HOUR FROM begin_interval_time) between 22 and 23;

set verify off
select * from (
select active_session_history.event,
sum(active_session_history.wait_time +
active_session_history.time_waited) ttl_wait_time
from dba_hist_active_sess_history active_session_history
where event is not null
and SNAP_ID between &ssnapid and &esnapid
group by active_session_history.event
order by 2 desc)
where rownum

Top CPU Consuming SQL During A Certain Time Period

Note – in this case we are finding the Top 5 CPU intensive SQL statements executed between 9.00 AM and 11.00 AM

select * from (
select
SQL_ID,
 sum(CPU_TIME_DELTA),
sum(DISK_READS_DELTA),
count(*)
from
DBA_HIST_SQLSTAT a, dba_hist_snapshot s
where
s.snap_id = a.snap_id
and s.begin_interval_time > sysdate -1
and EXTRACT(HOUR FROM S.END_INTERVAL_TIME) between 9 and 11
group by
SQL_ID
order by
sum(CPU_TIME_DELTA) desc)
where rownum

Which Database Objects Experienced the Most Number of Waits in the Past One Hour

set linesize 120
col event format a40
col object_name format a40

select * from 
(
  select dba_objects.object_name,
 dba_objects.object_type,
active_session_history.event,
 sum(active_session_history.wait_time +
  active_session_history.time_waited) ttl_wait_time
from v$active_session_history active_session_history,
    dba_objects
 where 
active_session_history.sample_time between sysdate - 1/24 and sysdate
and active_session_history.current_obj# = dba_objects.object_id
 group by dba_objects.object_name, dba_objects.object_type, active_session_history.event
 order by 4 desc)
where rownum < 6;

按物理读取量排序的顶级细分领域

col segment_name format a20
col owner format a10 
select segment_name,object_type,total_physical_reads
 from ( select owner||'.'||object_name as segment_name,object_type,
value as total_physical_reads
from v$segment_statistics
 where statistic_name in ('physical reads')
 order by total_physical_reads desc)
 where rownum

过去一小时中最常用的5条SQL语句

select * from (
select active_session_history.sql_id,
 dba_users.username,
 sqlarea.sql_text,
sum(active_session_history.wait_time +
active_session_history.time_waited) ttl_wait_time
from v$active_session_history active_session_history,
v$sqlarea sqlarea,
 dba_users
where 
active_session_history.sample_time between sysdate -  1/24  and sysdate
  and active_session_history.sql_id = sqlarea.sql_id
and active_session_history.user_id = dba_users.user_id
 group by active_session_history.sql_id,sqlarea.sql_text, dba_users.username
 order by 4 desc )
where rownum

过去一天中I/O量最大的SQL查询

select * from 
(
SELECT /*+LEADING(x h) USE_NL(h)*/ 
       h.sql_id
,      SUM(10) ash_secs
FROM   dba_hist_snapshot x
,      dba_hist_active_sess_history h
WHERE   x.begin_interval_time > sysdate -1
AND    h.SNAP_id = X.SNAP_id
AND    h.dbid = x.dbid
AND    h.instance_number = x.instance_number
AND    h.event in  ('db file sequential read','db file scattered read')
GROUP BY h.sql_id
ORDER BY ash_secs desc )
where rownum

过去一天中CPU占用最高的查询

select * from (
select 
	SQL_ID, 
	sum(CPU_TIME_DELTA), 
	sum(DISK_READS_DELTA),
	count(*)
from 
	DBA_HIST_SQLSTAT a, dba_hist_snapshot s
where
 s.snap_id = a.snap_id
 and s.begin_interval_time > sysdate -1
	group by 
	SQL_ID
order by 
	sum(CPU_TIME_DELTA) desc)
where rownum

查询在特定报告时间点上排名最高的SQL语句是什么。

首先确定所涉时段的快照ID值。

在那个示例中,我们需要找出2012年11月14日晚上10点至11点这一时段的SNAP_ID。

select snap_id,begin_interval_time,end_interval_time
from dba_hist_snapshot
where to_char(begin_interval_time,'DD-MON-YYYY')='14-NOV-2012'
and EXTRACT(HOUR FROM begin_interval_time) between 22 and 23;
select * from
 (
select
 sql.sql_id c1,
sql.buffer_gets_delta c2,
sql.disk_reads_delta c3,
sql.iowait_delta c4
 from
dba_hist_sqlstat sql,
dba_hist_snapshot s
 where
 s.snap_id = sql.snap_id
and
 s.snap_id= &snapid
 order by
 c3 desc)
 where rownum < 6 
/

分析特定的SQL ID,查看过去一天的趋势。

select
 s.snap_id,
 to_char(s.begin_interval_time,'HH24:MI') c1,
 sql.executions_delta c2,
 sql.buffer_gets_delta c3,
 sql.disk_reads_delta c4,
 sql.iowait_delta c5,
sql.cpu_time_delta c6,
 sql.elapsed_time_delta c7
 from
 dba_hist_sqlstat sql,
 dba_hist_snapshot s
 where
 s.snap_id = sql.snap_id
 and s.begin_interval_time > sysdate -1
 and
sql.sql_id='&sqlid'
 order by c7
 /

对于同一个SQL ID,我们是否有多个计划哈希值?如果是这样的话,那么可能是变更后的计划导致了性能下降。

select 
  SQL_ID 
, PLAN_HASH_VALUE 
, sum(EXECUTIONS_DELTA) EXECUTIONS
, sum(ROWS_PROCESSED_DELTA) CROWS
, trunc(sum(CPU_TIME_DELTA)/1000000/60) CPU_MINS
, trunc(sum(ELAPSED_TIME_DELTA)/1000000/60)  ELA_MINS
from DBA_HIST_SQLSTAT 
where SQL_ID in (
'&sqlid') 
group by SQL_ID , PLAN_HASH_VALUE
order by SQL_ID, CPU_MINS;

根据ADDM的建议,过去一周内的前5大查询词

/*
Top 10 SQL_ID's for the last 7 days as identified by ADDM
from DBA_ADVISOR_RECOMMENDATIONS and dba_advisor_log
*/

col SQL_ID form a16
col Benefit form 9999999999999
select * from (
select b.ATTR1 as SQL_ID, max(a.BENEFIT) as "Benefit" 
from DBA_ADVISOR_RECOMMENDATIONS a, DBA_ADVISOR_OBJECTS b 
where a.REC_ID = b.OBJECT_ID
and a.TASK_ID = b.TASK_ID
and a.TASK_ID in (select distinct b.task_id
from dba_hist_snapshot a, dba_advisor_tasks b, dba_advisor_log l
where a.begin_interval_time > sysdate - 7 
and  a.dbid = (select dbid from v$database) 
and a.INSTANCE_NUMBER = (select INSTANCE_NUMBER from v$instance) 
and to_char(a.begin_interval_time, 'yyyymmddHH24') = to_char(b.created, 'yyyymmddHH24') 
and b.advisor_name = 'ADDM' 
and b.task_id = l.task_id 
and l.status = 'COMPLETED') 
and length(b.ATTR4) > 1 group by b.ATTR1
order by max(a.BENEFIT) desc) where rownum < 6;
2026-10-16/由 yzm
https://www.recoverydata.cn/wp-content/uploads/2026/10/QQ20261026-095431.png 287 539 yzm https://www.recoverydata.cn/wp-content/uploads/2026/10/logo2-1.png yzm2026-10-16 11:10:382026-10-26 10:00:10oracle ASH与AWR性能调优脚本

This is a post with post format of type Link

News

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus et magnis dis parturient montes, nascetur ridiculus mus. Donec quam felis, ultricies nec, pellentesque eu, pretium quis, sem. Nulla consequat massa quis enim.

Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor. Aenean massa. Cum sociis natoque penatibus.

2012-01-17/由 yzm
https://www.recoverydata.cn/wp-content/uploads/2026/10/tst_10013.jpg 200 382 yzm https://www.recoverydata.cn/wp-content/uploads/2026/10/logo2-1.png yzm2012-01-17 20:00:252026-10-18 18:19:11This is a post with post format of type Link
yzm

Oracle 12c至19c数据库升级详细手册截图

ORACLE, 补丁升级

数据库管理员可以通过执行四步迁移流程,从而提升性能与稳定性,并延长系统的支持周期。甲骨文从12c升级到长期支持版本19c,主要依靠可视化的、自动化的数据库升级助手(DBUA)来完成。

  • 升级前的准备工作包括:完成完整的RMAN数据库备份,备份重要的配置文件(listener.ora、tnsnames.ora),运行19c版本的预安装程序,同时检查SYSTEM和SYSAUX数据表空间中的可用空间。
  • Oracle 19c软件的安装步骤包括创建新的Oracle安装目录、解压下载的软件,以及通过响应文件来执行静默安装。
  • 核心迁移过程会使用数据库升级助手(DBUA)来处理各项准备工作,包括必要的检查、配置选项(如网络设置等);在用户提供SYSDBA权限后,该工具还会负责实际的升级操作。
  • 升级后的验证步骤包括:检查数据库组件的dba_registry编号,核实/etc/oratab文件的状态,删除临时恢复点(PRE_UPGRADE),并将COMPATIBLE参数设置为“19.0.0”。

使用数据库升级助手(DBUA)可以提供直观的图形界面,从而自动完成许多手动操作;不过,管理员仍需在操作完成后检查数据库状态,并应用所需的SQL补丁

引言

Oracle Database 19c is a long-term support version offering improved performance, stability, and security. Upgrading to 19c ensures extended support and compatibility with modern features. This post walks through upgrading your Oracle 12c database to 19c using DBUA, complete with visual placeholders.

环境设置

参数 价值
主机名 <您的主机名>
数据库名称 <你的数据库名称>
当前版本 12.2.0.1
Oracle主页 /u01/app/oracle/product/12.2.0/db_1
数据文件位置 /path/to/oradata/CID
目标版本 19.4.0.0.0
目标Oracle主目录 /u01/app/oracle/product/19.0.0/db_1

从12c逐步升级到Oracle 19c数据库的指南

1. 升级前的准备工作

💡提示:在升级之前,务必先进行完整的RMAN备份。

rman target /
backup database plus archivelog;

备份配置文件

这些文件对网络和数据库的连接至关重要。

运行以下命令:

cd /u01/app/oracle/product/12.2.0/db_1/network/admin/
cp -p listener.ora sqlnet.ora tnsnames.ora /u01/backup/
ls -ltr /u01/backup/*.ora
cd /u01/app/oracle/product/12.2.0/db_1/dbs/
cp -p spfileoracle12c.ora orapworacle12c /u01/backup/

运行19c预安装包

确保满足所有操作系统级别的先决条件:

yum install -y oracle-database-preinstall-19c
yum update -y

启用Xming和X11转发以打开DBUA图形界面。

验证表空间大小

查看SYSTEM和SYSAUX数据表空间中的可用空闲空间:

set line 1000
set pages 5000
col tablespace_name for a30
col file_name for a80
select c.tablespace_name,a.file_name,a.total_space,b.free_space, round(b.free_space/a.total_space *100,2) "Free%" from dba_data_files
 a, dba_free_space b where a.file_id=b.file_id(+) order by tablespace_name;

检查无效对象

SELECT COUNT(*) FROM dba_objects WHERE status='INVALID';

收集词典统计信息

EXECUTE DBMS_STATS.GATHER_DICTIONARY_STATS;

创建回放恢复点

ALTER SYSTEM SET db_recovery_file_dest_size=10G;
CREATE RESTORE POINT pre_upgrade GUARANTEE FLASHBACK DATABASE;

2. 安装Oracle 19c软件

🧱 第一步:创建Oracle 19c安装目录并设置权限:

mkdir -p /u01/app/oracle/product/19.3/db_home
chown -R oracle:oinstall /u01/app/oracle

🧩 第二步:下载该软件并解压:

cd /u01/app/oracle/product/19.3/db_home
unzip -qo /tmp/LINUX.X64_193000_db_home.zip

🛠️ 第3步:执行静默安装:

./runInstaller -ignorePrereq -waitforcompletion -silent \
-responseFile ${ORACLE_HOME}/install/response/db_install.rsp \
ORACLE_HOME=/u01/app/oracle/product/19.3/db_home \
ORACLE_BASE=/u01/app/oracle DECLINE_SECURITY_UPDATES=true

3. 使用数据库升级助手(DBUA)进行升级

从19c主界面启动DBUA:

cd /u01/app/oracle/product/19.3.0/db_home/bin
./dbua

步骤1:选择数据库,并提供SYSDBA登录凭证。

步骤2:等待前置条件检查完成,并解决出现的任何问题。

步骤3:选择升级与恢复选项。

第4步:配置监听器和网络设置。

第5步:查看摘要并开始升级。

步骤6:等待DBUA完成升级。

第7步:查看结果,然后点击“关闭”。

4. 升级后的任务

📂 确认/etc/oratab是否反映了新的19世纪风格住宅:

cat /etc/oratab | grep -i prod

检查数据库组件

SELECT COMP_ID, COMP_NAME, VERSION, STATUS FROM dba_registry;

删除恢复点

DROP RESTORE POINT PRE_UPGRADE;

设置兼容参数

⚠️ 注意:请在确认系统稳定后再进行更改。

ALTER SYSTEM SET COMPATIBLE = '19.0.0' SCOPE=SPFILE;
SHUTDOWN IMMEDIATE;
STARTUP;

结论

使用DBUA进行Oracle升级,可以借助直观的图形界面自动完成许多手动操作。升级完成后,务必检查数据库状态、识别无效对象,并运行datapatch以应用最新的SQL补丁。

2012-01-14/由 yzm
https://www.recoverydata.cn/wp-content/uploads/2012/01/282-8.jpg 632 890 yzm https://www.recoverydata.cn/wp-content/uploads/2026/10/logo2-1.png yzm2012-01-14 13:13:532026-10-26 10:24:49Oracle 12c至19c数据库升级详细手册截图
第2页,共4页1234

RD数据恢复  www.recoverydata.cn

备案号:苏ICP备15021567号-13

服务范围 / 方式 / 愿景

数据恢复 / 异常处理 / 安装配置

数据迁移 / 性能优化 / 巡检服务

服务方式:  远程 / 现场 / 电话

长期提供更专业更快速更低成本服务

本站技术标签

MySQL, ORACLE, Redis,SQLServer

Neo4j, MongoDB, PostgreSQL

达梦,无法启动, 断电故障, 检测失败

数据丢失,攻击勒索,误删除更新异常

 

技术、商务、投稿、侵权等联系!

滚动到顶部 滚动到顶部 滚动到顶部