在归档模式下删除非系统文件的恢复
歸檔
恢復
我們
文件
模式
系統
众所周知，我们的核心生产数据库通常都是在归档模式下运行的，更不用说还配置DG环境的了。开启归档，并保证所有归档不丢失，就能保证我们对数据库所做的任何修改不会丢失，归档日志可谓是恢复的根本，如果丢失归档，那么即使RMAN功能再强大，也无法对丢失的数
众所周知，我们的核心生产数据库通常都是在归档模式下运行的，更不用说还配置DG环境的了。开启归档，并保证所有归档不丢失，就能保证我们对数据库所做的任何修改不会丢失，归档日志可谓是恢复的根本，如果丢失归档，那么即使RMAN功能再强大，也无法对丢失的数据进行恢复。所以我们通常配置的RMAN策略就是全备+归档+控制文件自动备份。这里的归档不是指数据库创建以来生成的归档(那量也太大了)，而是当进行RMAN非一致性备份时新产生的那部分归档日志，用来保证数据库可以前推到一致性状态，这样才能顺利open数据库。以下的测试只是想说明归档日志对恢复数据的重要性，并没有用到RMAN来进行恢复。测试一：归档日志健全未丢失
--连接到Oracle，确保是运行在归档模式下 [oracle@ora10g ~]$ sqlplus / as sysdba
SQL*Plus: Release 10.2.0.1.0 - Production on 8 13:46:53 2014
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Production With the Partitioning, OLAP and Data Mining options
SQL> archive log list Database log mode Archive Mode --归档模式 Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 172 Next log sequence to archive 174 Current log sequence 174 SQL> set lin 130 pages 130 SQL> col name for a45 SQL> select file#,name from v$datafile;
FILE# NAME ---------- --------------------------------------------- 1 /u01/app/oracle/oradata/ora10g/system01.dbf 2 /u01/app/oracle/oradata/ora10g/undotbs01.dbf 3 /u01/app/oracle/oradata/ora10g/sysaux01.dbf 4 /u01/app/oracle/oradata/ora10g/users01.dbf 5 /u01/app/oracle/oradata/ora10g/example01.dbf
--创建测试表空间、用户、表 SQL> create tablespace zlm_test datafile '/u01/app/oracle/oradata/ora10g/zlm01.dbf' size 50m;
Tablespace created.
SQL> create user zlm identified by zlm default tablespace zlm_test;
User created.
SQL> grant connect,resource to zlm; --赋权限
Grant succeeded.
SQL> select file#,name from v$datafile;
FILE# NAME ---------- --------------------------------------------- 1 /u01/app/oracle/oradata/ora10g/system01.dbf 2 /u01/app/oracle/oradata/ora10g/undotbs01.dbf 3 /u01/app/oracle/oradata/ora10g/sysaux01.dbf 4 /u01/app/oracle/oradata/ora10g/users01.dbf 5 /u01/app/oracle/oradata/ora10g/example01.dbf 6 /u01/app/oracle/oradata/ora10g/zlm01.dbf --新增了6号文件作为测试表存放的物理介质
6 rows selected.
SQL> create table zlm.test1 as select rownum as id,object_name from dba_objects where rownum Table created.
SQL> col object_name for a15
SQL> select * from zlm.test1;
ID OBJECT_NAME ---------- --------------- 1 ICOL$ 2 I_USER1 3 CON$ 4 UNDO$ 5 C_COBJ#
--查看当前online日志文件状态 SQL> select group#,status,archived from v$log;
GROUP# STATUS ARC ---------- ---------------- --- 1 INACTIVE YES 2 INACTIVE YES 3 CURRENT NO --当前日志组为3，未归档
--归档当前日志（多次） SQL> alter system archive log current;
System altered.
SQL> alter system archive log current;
System altered.
SQL> alter system archive log current;
System altered.
这里进行了3次归档当前日志文件的操作，目的是使online日志被刷新，强制其归档，写到归档日志中去，因为我们要测试的是归档，否则恢复文件时，会自动去online日志中查找，即便是非归档模式，只要online日志还未被刷新，依旧是可以恢复的
SQL> select group#,status,archived from v$log;
GROUP# STATUS ARC ---------- ---------------- --- 1 INACTIVE YES 2 INACTIVE YES 3 CURRENT NO --虽然看起来和刚才上一步一致，但此时其实已经把第3组online日志刷新掉了
--保险起见，再归档一次（可选） SQL> alter system archive log current;
System altered.
SQL> select group#,status,archived from v$log;
GROUP# STATUS ARC ---------- ---------------- --- 1 CURRENT NO 2 INACTIVE YES 3 ACTIVE YES --现在新一轮的第3组的日志也已经归档了
--一致性关闭数据库，在OS级别删除测试文件datafile 6 SQL> shutdown immediate
Database closed. Database dismounted. ORACLE instance shut down. SQL> ! [oracle@ora10g ~]$ cd $ORACLE_BASE/oradata/ora10g [oracle@ora10g ora10g]$ ll -lrth total 1.7G -rw-r----- 1 oracle oinstall 51M Sep 5 10:13 test02.dbf -rw-r----- 1 oracle oinstall 301M Sep 5 10:13 test01.dbf -rw-r----- 1 oracle oinstall 201M Sep 16 16:56 temp01.dbf -rw-r----- 1 oracle oinstall 51M Sep 18 13:49 redo02.log -rw-r----- 1 oracle oinstall 51M Sep 18 13:51 redo03.log -rw-r----- 1 oracle oinstall 51M Sep 18 13:51 zlm01.dbf -rw-r----- 1 oracle oinstall 31M Sep 18 13:51 users01.dbf -rw-r----- 1 oracle oinstall 166M Sep 18 13:51 undotbs01.dbf -rw-r----- 1 oracle oinstall 561M Sep 18 13:51 system01.dbf -rw-r----- 1 oracle oinstall 271M Sep 18 13:51 sysaux01.dbf -rw-r----- 1 oracle oinstall 51M Sep 18 13:51 redo01.log -rw-r----- 1 oracle oinstall 101M Sep 18 13:51 example01.dbf -rw-r----- 1 oracle oinstall 7.2M Sep 18 13:52 control03.ctl -rw-r----- 1 oracle oinstall 7.2M Sep 18 13:52 control02.ctl -rw-r----- 1 oracle oinstall 7.2M Sep 18 13:52 control01.ctl [oracle@ora10g ora10g]$ rm -f zlm01.dbf [oracle@ora10g ora10g]$ exit exit
--重启数据库 SQL> startup ORACLE instance started.
Total System Global Area 285212672 bytes Fixed Size 1218992 bytes Variable Size 88082000 bytes Database Buffers 192937984 bytes Redo Buffers 2973696 bytes Database mounted. ORA-01157: cannot identify/lock data file 6 - see DBWR trace file ORA-01110: data file 6: '/u01/app/oracle/oradata/ora10g/zlm01.dbf'
可以看到，此时是无法open数据库的，因为数据库文件物理上已经不存在，而在控制文件中是有记录的，这里提示的是“cannot identify/lock data file 6”，而当如果仅仅是物理上存在，数据文件头中的信息与控制文件中记录的数据文件头信息不一致时，会提示xxx文件需要恢复
--手动创建一个datafile 6 SQL> alter database create datafile 6;
Database altered.
注意，此时仅仅是创建了一个不一致的datafile 6而已，也可以通过RMAN的restore datafile 6;命令来实现，作用是一样的
--恢复datafile 6 SQL> recover datafile 6; ORA-00279: change 983806 generated at 09/18/2014 13:47:22 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_174_%u_.arc ORA-00280: change 983806 for thread 1 is in sequence #174
Specify log: {
Log applied. Media recovery complete. SQL> alter database open;
Database altered.
SQL> select * from zlm.test1;
ID OBJECT_NAME ---------- --------------- 1 ICOL$ 2 I_USER1 3 CON$ 4 UNDO$ 5 C_COBJ#
尽管online日志没有了，但由于归档日志从头至尾都没有删除过，很快地数据库完成了介质恢复，顺利地open了，测试表数据也未丢失
测试二：更改表内容后的归档日志全部丢失
--删除测试表中第5条记录并提交 SQL> delete from zlm.test1 where id=5;
1 row deleted.
SQL> commit;
Commit complete.
SQL> select * from zlm.test1;
ID OBJECT_NAME ---------- --------------- 1 ICOL$ 2 I_USER1 3 CON$ 4 UNDO$
SQL> select group#,status,archived from v$log;
GROUP# STATUS ARC ---------- ---------------- --- 1 CURRENT NO 2 INACTIVE YES 3 INACTIVE YES
--同样的，切3次归档，把online日志刷到归档去 SQL> alter system archive log current;
System altered.
SQL> alter system archive log current;
System altered.
SQL> alter system archive log current;
System altered.
SQL> select group#,status,archived from v$log;
GROUP# STATUS ARC ---------- ---------------- --- 1 CURRENT NO --此处online日志已经被刷新 2 ACTIVE YES 3 ACTIVE YES
--关闭数据库，在os级别删除datafile 6以及新增的归档日志文件 SQL> shutdown immediate Database closed. Database dismounted. ORACLE instance shut down. SQL> ! [oracle@ora10g ~]$ cd $ORACLE_BASE/oradata/ora10g [oracle@ora10g ora10g]$ rm -f zlm01.dbf [oracle@ora10g ora10g]$ cd $ORACLE_BASE/flash_recovery_area/ORA10G/archivelog/2014_09_18 [oracle@ora10g 2014_09_18]$ ll -lrth total 9.5M -rw-r----- 1 oracle oinstall 2.4M Sep 18 10:10 o1_mf_1_172_b1nhskdd_.arc -rw-r----- 1 oracle oinstall 469K Sep 18 10:14 o1_mf_1_173_b1nj0wxp_.arc -rw-r----- 1 oracle oinstall 6.1M Sep 18 13:49 o1_mf_1_174_b1nwmrpv_.arc -rw-r----- 1 oracle oinstall 1.0K Sep 18 13:49 o1_mf_1_175_b1nwmzo4_.arc -rw-r----- 1 oracle oinstall 2.5K Sep 18 13:49 o1_mf_1_176_b1nwn43r_.arc -rw-r----- 1 oracle oinstall 37K Sep 18 13:51 o1_mf_1_177_b1nwpwxb_.arc -rw-r----- 1 oracle oinstall 477K Sep 18 14:01 o1_mf_1_178_b1nx9ry9_.arc -rw-r----- 1 oracle oinstall 1.0K Sep 18 14:01 o1_mf_1_179_b1nx9y1k_.arc -rw-r----- 1 oracle oinstall 7.0K Sep 18 14:01 o1_mf_1_180_b1nxb6q1_.arc
这里14:01生成的3个归档日志，是我在删除测试表数据库后归档current online日志生成的
--为了方便恢复，移走这3个归档日志（未真正删除） [oracle@ora10g 2014_09_18]$ mv *178* ../ [oracle@ora10g 2014_09_18]$ mv *179* ../ [oracle@ora10g 2014_09_18]$ mv *180* ../ [oracle@ora10g 2014_09_18]$ ll -lrth total 9.0M -rw-r----- 1 oracle oinstall 2.4M Sep 18 10:10 o1_mf_1_172_b1nhskdd_.arc -rw-r----- 1 oracle oinstall 469K Sep 18 10:14 o1_mf_1_173_b1nj0wxp_.arc -rw-r----- 1 oracle oinstall 6.1M Sep 18 13:49 o1_mf_1_174_b1nwmrpv_.arc -rw-r----- 1 oracle oinstall 1.0K Sep 18 13:49 o1_mf_1_175_b1nwmzo4_.arc -rw-r----- 1 oracle oinstall 2.5K Sep 18 13:49 o1_mf_1_176_b1nwn43r_.arc -rw-r----- 1 oracle oinstall 37K Sep 18 13:51 o1_mf_1_177_b1nwpwxb_.arc [oracle@ora10g 2014_09_18]$ exit exit
--启动数据库 SQL> startup ORACLE instance started.
Total System Global Area 285212672 bytes Fixed Size 1218992 bytes Variable Size 88082000 bytes Database Buffers 192937984 bytes Redo Buffers 2973696 bytes Database mounted. ORA-01157: cannot identify/lock data file 6 - see DBWR trace file ORA-01110: data file 6: '/u01/app/oracle/oradata/ora10g/zlm01.dbf'
--再次创建数据文件datafile 6 SQL> alter database create datafile 6;
Database altered.
--对数据文件datafile 6进行介质恢复 SQL> recover datafile 6; ORA-00279: change 983806 generated at 09/18/2014 13:47:22 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_174_%u_.arc ORA-00280: change 983806 for thread 1 is in sequence #174
Specify log: {
ORA-00279: change 983927 generated at 09/18/2014 13:49:51 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_176_%u_.arc ORA-00280: change 983927 for thread 1 is in sequence #176 ORA-00278: log file '/u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_175_b1nwmzo4_.arc' no longer needed for this recovery
ORA-00279: change 983931 generated at 09/18/2014 13:49:56 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_177_%u_.arc ORA-00280: change 983931 for thread 1 is in sequence #177 ORA-00278: log file '/u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_176_b1nwn43r_.arc' no longer needed for this recovery
ORA-00279: change 983974 generated at 09/18/2014 13:51:24 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_178_%u_.arc ORA-00280: change 983974 for thread 1 is in sequence #178 ORA-00278: log file '/u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_177_b1nwpwxb_.arc' no longer needed for this recovery
ORA-00308: cannot open archived log '/u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_178_b1nx9ry9_.arc' ORA-27037: unable to obtain file status Linux Error: 2: No such file or directory Additional information: 3
当执行auto后，第一个建议的归档位置是174，然后到175、176、177，都没有问题，一直到178，提示文件无法找到，由于178、179、180这3个归档日志被移走了，模拟被删除的情况，数据库无法自动获取到这3个归档日志，也就无法把datafile 6前推到数据库正常关闭前的一致性状态，这个时候想要恢复，就只能通过BBED工具来修改数据文件头信息来实现了，数据库自身以无法完成这个任务，如果这个数据文件对整个数据库而言并不是非常重要，那么可以先offline该文件，然后一致性打开数据库，当然，这个数据文件中的数据也就丢失了
--使datafile 6 offline SQL> alter database datafile 6 offline;
Database altered.
SQL> alter database open;
Database altered.
SQL> select file#,name,status from v$datafile;
FILE# NAME STATUS ---------- --------------------------------------------- ------- 1 /u01/app/oracle/oradata/ora10g/system01.dbf SYSTEM 2 /u01/app/oracle/oradata/ora10g/undotbs01.dbf ONLINE 3 /u01/app/oracle/oradata/ora10g/sysaux01.dbf ONLINE 4 /u01/app/oracle/oradata/ora10g/users01.dbf ONLINE 5 /u01/app/oracle/oradata/ora10g/example01.dbf ONLINE 6 /u01/app/oracle/oradata/ora10g/zlm01.dbf OFFLINE
6 rows selected.
SQL> select * from zlm.test1; select * from zlm.test1 * ERROR at line 1: ORA-00376: file 6 cannot be read at this time ORA-01110: data file 6: '/u01/app/oracle/oradata/ora10g/zlm01.dbf'
虽然打开了数据库，但测试数据表还是丢失了，丢失了归档，又没有备份过归档，那么丢数据库是在所难免得了，又一次证明了归档对数据恢复的重要性，由于刚才并未真正地删除归档，只是使了一个trick，那么就当我们之前对归档做了个手动备份，现在来恢复丢失的归档（mv回原归档路径）
SQL> shutdown immediate
Database closed. Database dismounted. ORACLE instance shut down. SQL> ! cd[oracle@ora10g ~]$ cd $ORACLE_BASE/flash_recovery_area/ORA10G/archivelog [oracle@ora10g archivelog]$ ll -lrth total 516K drwxr-x--- 2 oracle oinstall 4.0K Sep 12 10:33 2014_09_12 drwxr-x--- 2 oracle oinstall 4.0K Sep 15 17:19 2014_09_15 drwxr-x--- 2 oracle oinstall 4.0K Sep 17 12:30 2014_09_16 drwxr-x--- 2 oracle oinstall 4.0K Sep 18 10:15 2014_09_17 -rw-r----- 1 oracle oinstall 477K Sep 18 14:01 o1_mf_1_178_b1nx9ry9_.arc -rw-r----- 1 oracle oinstall 1.0K Sep 18 14:01 o1_mf_1_179_b1nx9y1k_.arc -rw-r----- 1 oracle oinstall 7.0K Sep 18 14:01 o1_mf_1_180_b1nxb6q1_.arc drwxr-x--- 2 oracle oinstall 4.0K Sep 18 14:25 2014_09_18 [oracle@ora10g archivelog]$ mv *.arc ./2014_09_18 [oracle@ora10g archivelog]$ cd 2014_09_18 [oracle@ora10g 2014_09_18]$ ll -lrth total 9.5M -rw-r----- 1 oracle oinstall 2.4M Sep 18 10:10 o1_mf_1_172_b1nhskdd_.arc -rw-r----- 1 oracle oinstall 469K Sep 18 10:14 o1_mf_1_173_b1nj0wxp_.arc -rw-r----- 1 oracle oinstall 6.1M Sep 18 13:49 o1_mf_1_174_b1nwmrpv_.arc -rw-r----- 1 oracle oinstall 1.0K Sep 18 13:49 o1_mf_1_175_b1nwmzo4_.arc -rw-r----- 1 oracle oinstall 2.5K Sep 18 13:49 o1_mf_1_176_b1nwn43r_.arc -rw-r----- 1 oracle oinstall 37K Sep 18 13:51 o1_mf_1_177_b1nwpwxb_.arc -rw-r----- 1 oracle oinstall 477K Sep 18 14:01 o1_mf_1_178_b1nx9ry9_.arc -rw-r----- 1 oracle oinstall 1.0K Sep 18 14:01 o1_mf_1_179_b1nx9y1k_.arc -rw-r----- 1 oracle oinstall 7.0K Sep 18 14:01 o1_mf_1_180_b1nxb6q1_.arc [oracle@ora10g 2014_09_18]$ exit exit
SQL> startup mount
ORACLE instance started.
Total System Global Area 285212672 bytes Fixed Size 1218992 bytes Variable Size 88082000 bytes Database Buffers 192937984 bytes Redo Buffers 2973696 bytes Database mounted. SQL> alter database datafile 6 online;
Database altered.
SQL> recover datafile 6; ORA-00279: change 983974 generated at 09/18/2014 13:51:24 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_178_%u_.arc ORA-00280: change 983974 for thread 1 is in sequence #178
Specify log: {
Database altered.
SQL> select * from zlm.test1;
ID OBJECT_NAME ---------- --------------- 1 ICOL$ 2 I_USER1 3 CON$ 4 UNDO$
当恢复了归档后，再次对datafile 6进行介质恢复，再open数据库以后，之前丢失的数据又回来了。 注意：当归档路径在OS上物理存在，只是默认位置不是FRA指定的路径，那么当执行recover datafile 6后，可以手动指定一个归档路径的位置，如： SQL> recover datafile 6; ORA-00279: change 983806 generated at 09/18/2014 13:47:22 needed for thread 1 ORA-00289: suggestion : /u01/app/oracle/flash_recovery_area/ORA10G/archivelog/2014_09_18/o1_mf_1_174_%u_.arc ORA-00280: change 983806 for thread 1 is in sequence #174
Specify log: {
Specify log: {
Specify log: {
Specify log: {
Specify log: {
总结：鉴于归档日志对于数据库的恢复非常重要，因此对归档日志的备份也要重视起来。可以这么说，归档日志就是对online日志的备份，对于那些写入数据文件的脏数据，和不一致数据而言，都是要通过归档日志来前滚到一致性状态的，只有当数据库的所有数据文件与关闭数据库时是一致的，才可以无需备份归档日志文件。
本網站聲明
本文內容由網友自願投稿，版權歸原作者所有。本站不承擔相應的法律責任。如發現涉嫌抄襲或侵權的內容，請聯絡admin@php.cn
熱AI工具
Undresser.AI Undress
人工智慧驅動的應用程序，用於創建逼真的裸體照片
AI Clothes Remover
用於從照片中去除衣服的線上人工智慧工具。
Undress AI Tool
免費脫衣圖片
Clothoff.io
AI脫衣器
Video Face Swap
使用我們完全免費的人工智慧換臉工具，輕鬆在任何影片中換臉！
熱門文章
Windows 11 KB5054979中的新功能以及如何解決更新問題
3 週前
By DDD
如何修復KB5055523無法在Windows 11中安裝？
2 週前
By DDD
Inzoi：如何申請學校和大學
4 週前
By DDD
如何修復KB5055518無法在Windows 10中安裝？
2 週前
By DDD
Roblox：Dead Rails - 如何召喚和擊敗Nikola Tesla
4 週前
By 尊渡假赌尊渡假赌尊渡假赌
熱工具
記事本++7.3.1
好用且免費的程式碼編輯器
SublimeText3漢化版
中文版，非常好用
禪工作室 13.0.1
強大的PHP整合開發環境
Dreamweaver CS6
視覺化網頁開發工具
SublimeText3 Mac版
神級程式碼編輯軟體(SublimeText3)
CUDA之通用矩陣乘法：從入門到熟練！
Mar 25, 2024 pm 12:30 PM
通用矩陣乘法（GeneralMatrixMultiplication，GEMM）是許多應用程式和演算法中至關重要的一部分，也是評估電腦硬體效能的重要指標之一。透過深入研究和優化GEMM的實現，可以幫助我們更好地理解高效能運算以及軟硬體系統之間的關係。在電腦科學中，對GEMM進行有效的最佳化可以提高運算速度並節省資源，這對於提高電腦系統的整體效能至關重要。深入了解GEMM的工作原理和最佳化方法，有助於我們更好地利用現代計算硬體的潛力，並為各種複雜計算任務提供更有效率的解決方案。透過對GEMM性能的優
抖音怎麼恢復聊天火花
Mar 16, 2024 pm 01:25 PM
在抖音這個充滿創意與活力的短影片平台上，我們不僅可以欣賞到各種精彩內容，還能與志同道合的朋友展開深入的交流。其中，聊天火花作為衡量雙方互動熱度的重要指標，常常在不經意間點燃我們與好友之間的情感連結。然而，有時由於一些原因，聊天火花可能會斷開，那麼如果我們想要恢復聊天火花究竟該如何操作呢，這篇教程攻略就將為大家帶來詳細的內容攻略介紹，希望能幫助到大家。抖音聊天火花斷了怎麼恢復？ 1.開啟抖音的訊息頁面，選擇好友聊天。 2、互發訊息聊天。 3.連續發送訊息3天，就可以獲得火花標識。在3天基礎上，互發圖片或視
华为乾崑 ADS3.0 智驾系统 8 月上市 享界 S9 首发搭载
Jul 30, 2024 pm 02:17 PM
7月29日，在AITO问界第四十万台新车下线仪式上，华为常务董事、终端BG董事长、智能汽车解决方案BU董事长余承东出席发表演讲并宣布，问界系列车型将于今年8月迎来华为乾崑ADS3.0版本的上市，并计划在8月至9月间陆续推送升级。8月6日即将发布的享界S9将首发华为ADS3.0智能驾驶系统。华为乾崑ADS3.0版本在激光雷达的辅助下，将大幅提升智驾能力，具备融合端到端的能力，并采用GOD(通用障碍物识别)/PDP(预测决策规控)全新端到端架构，提供车位到车位智驾领航NCA功能，并升级CAS3.0全
出現0x80004005錯誤代碼怎麼辦 小編教你0x80004005錯誤代碼解決方法
Mar 21, 2024 pm 09:17 PM
在電腦中刪除或解壓縮資料夾，時有時會彈出提示對話框“錯誤0x80004005：未指定錯誤”，如果遇到這中情況應該怎麼解決呢？提示錯誤碼0x80004005的原因其實很多，但大部分因為病毒導致，我們可以重新註冊dll來解決問題，下面，小編給大夥講解0x80004005錯誤代碼處理經驗。有使用者在使用電腦時出現錯誤代碼0X80004005的提示，0x80004005錯誤主要是由於電腦沒有正確註冊某些動態連結庫文件，或電腦與Internet之間存在不允許的HTTPS連接防火牆所引起。那麼如何
夸克網盤的檔案怎麼轉移到百度網盤？
Mar 14, 2024 pm 02:07 PM
夸克網盤和百度網盤都是現在最常用的儲存文件的網盤軟體，如果想要將夸克網盤內的文件保存到百度網盤，要怎麼操作呢？本期小編整理了夸克網盤電腦端的檔案轉移到百度網盤的教學步驟，一起來看看是怎麼操作吧。 夸克網盤的檔案怎麼存到百度網盤？要將夸克網盤的文件轉移到百度網盤，首先需在夸克網盤下載所需文件，然後在百度網盤用戶端中選擇目標資料夾並開啟。接著，將夸克網盤中下載的檔案拖放到百度網盤用戶端開啟的資料夾中，或使用上傳功能將檔案新增至百度網盤。確保上傳完成後在百度網盤中查看檔案是否已成功轉移。這樣就
hiberfil.sys是什麼檔案？ hiberfil.sys可以刪除嗎？
Mar 15, 2024 am 09:49 AM
最近有很多網友問小編，hiberfil.sys是什麼文件？ hiberfil.sys佔用了大量的C碟空間可以刪除嗎？小編可以告訴大家hiberfil.sys檔是可以刪除的。下面就來看看詳細的內容。 hiberfil.sys是Windows系統中的隱藏文件，也是系統休眠文件。通常儲存在C盤根目錄下，其大小與系統安裝記憶體大小相當。這個檔案在電腦休眠時被使用，其中包含了當前系統的記憶體數據，以便在恢復時快速恢復到先前的狀態。由於其大小與記憶體容量相等，因此它可能會佔用較大的硬碟空間。 hiber
常用常新！華為Mate60系列升級HarmonyOS 4.2：AI雲端增強、小藝方言太好用了
Jun 02, 2024 pm 02:58 PM
4月11日，華為官方首次宣布HarmonyOS4.2百機升級計劃，此次共有180餘款設備參與升級，品類覆蓋手機、平板、手錶、耳機、智慧螢幕等設備。過去一個月，隨著HarmonyOS4.2百機升級計畫的穩定推進，包括華為Pocket2、華為MateX5系列、nova12系列、華為Pura系列等多款熱門機型也已紛紛展開升級適配，這意味著會有更多華為機型用戶享受到HarmonyOS帶來的常用常新體驗。從使用者回饋來看，華為Mate60系列機種在升級HarmonyOS4.2之後，體驗全方位躍升。尤其是華為M
蘋果16系統哪個版本最好
Mar 08, 2024 pm 05:16 PM
蘋果16系統中版本最好的是iOS16.1.4，iOS16系統的最佳版本可能因人而異添加和日常使用體驗的提升也受到了很多用戶的好評。蘋果16系統哪個版本最好答：iOS16.1.4iOS16系統的最佳版本可能因人而異。根據公開的消息，2022年推出的iOS16被認為是一個非常穩定且性能優越的版本，用戶對其整體體驗也相當滿意。此外，iOS16中新功能的新增和日常使用體驗的提升也受到了許多用戶的好評。特別是在更新後的電池續航力、訊號表現和發熱控制方面，使用者的回饋都比較正面。然而，考慮到iPhone14
