在归档模式下删除非系统文件的恢复
众所周知，我们的核心生产数据库通常都是在归档模式下运行的，更不用说还配置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日志的备份，对于那些写入数据文件的脏数据，和不一致数据而言，都是要通过归档日志来前滚到一致性状态的，只有当数据库的所有数据文件与关闭数据库时是一致的，才可以无需备份归档日志文件。
Heiße KI -Werkzeuge
Undresser.AI Undress
KI-gestützte App zum Erstellen realistischer Aktfotos
AI Clothes Remover
Online-KI-Tool zum Entfernen von Kleidung aus Fotos.
Undress AI Tool
Ausziehbilder kostenlos
Clothoff.io
KI-Kleiderentferner
AI Hentai Generator
Erstellen Sie kostenlos Ai Hentai.
Heißer Artikel
Heiße Werkzeuge
Notepad++7.3.1
Einfach zu bedienender und kostenloser Code-Editor
SublimeText3 chinesische Version
Chinesische Version, sehr einfach zu bedienen
Senden Sie Studio 13.0.1
Leistungsstarke integrierte PHP-Entwicklungsumgebung
Dreamweaver CS6
Visuelle Webentwicklungstools
SublimeText3 Mac-Version
Codebearbeitungssoftware auf Gottesniveau (SublimeText3)
Heiße Themen
1382
52
CUDAs universelle Matrixmultiplikation: vom Einstieg bis zur Kompetenz!
Mar 25, 2024 pm 12:30 PM
Die allgemeine Matrixmultiplikation (GEMM) ist ein wesentlicher Bestandteil vieler Anwendungen und Algorithmen und außerdem einer der wichtigen Indikatoren zur Bewertung der Leistung der Computerhardware. Eingehende Forschung und Optimierung der Implementierung von GEMM können uns helfen, Hochleistungsrechnen und die Beziehung zwischen Software- und Hardwaresystemen besser zu verstehen. In der Informatik kann eine effektive Optimierung von GEMM die Rechengeschwindigkeit erhöhen und Ressourcen einsparen, was für die Verbesserung der Gesamtleistung eines Computersystems von entscheidender Bedeutung ist. Ein tiefgreifendes Verständnis des Funktionsprinzips und der Optimierungsmethode von GEMM wird uns helfen, das Potenzial moderner Computerhardware besser zu nutzen und effizientere Lösungen für verschiedene komplexe Computeraufgaben bereitzustellen. Durch Optimierung der Leistung von GEMM
So stellen Sie den Chat-Funken auf TikTok wieder her
Mar 16, 2024 pm 01:25 PM
Auf Douyin, einer Kurzvideoplattform voller Kreativität und Vitalität, können wir nicht nur eine Vielzahl spannender Inhalte genießen, sondern auch intensiv mit gleichgesinnten Freunden kommunizieren. Unter anderem sind Chat-Funken ein wichtiger Indikator für die Intensität der Interaktion zwischen den beiden Parteien und entfachen oft ungewollt die emotionale Bindung zwischen uns und unseren Freunden. Aus bestimmten Gründen kann es jedoch vorkommen, dass der Chat-Funken unterbrochen wird. Was sollten wir also tun, wenn wir den Chat-Funken wiederherstellen möchten, in der Hoffnung, dass er allen hilft? Wie kann man den Funken des Douyin-Chats wiederherstellen? 1. Öffnen Sie die Douyin-Nachrichtenseite und wählen Sie einen Freund zum Chatten aus. 2. Senden Sie Nachrichten und chatten Sie miteinander. 3. Wenn Sie 3 Tage lang ununterbrochen Nachrichten senden, können Sie das Spark-Logo erhalten. Schicken Sie sich alle drei Tage gegenseitig Bilder oder Videos
Was tun, wenn der Fehlercode 0x80004005 angezeigt wird? Der Editor zeigt Ihnen, wie Sie den Fehlercode 0x80004005 beheben können.
Mar 21, 2024 pm 09:17 PM
Wenn Sie einen Ordner auf Ihrem Computer löschen oder dekomprimieren, wird manchmal das Dialogfeld „Fehler 0x80004005: Nicht spezifizierter Fehler“ angezeigt. Wie können Sie diese Situation lösen? Es gibt tatsächlich viele Gründe, warum der Fehlercode 0x80004005 angezeigt wird, aber die meisten davon werden durch Viren verursacht. Wir können die DLL erneut registrieren, um das Problem zu lösen. Nachfolgend erklärt Ihnen der Editor die Erfahrung beim Umgang mit dem Fehlercode 0x80004005 . Einige Benutzer erhalten bei der Verwendung ihres Computers den Fehlercode 0X80004005. Der Fehler 0x80004005 wird hauptsächlich dadurch verursacht, dass der Computer bestimmte Dynamic Link Library-Dateien nicht korrekt registriert oder dass eine Firewall keine HTTPS-Verbindungen zwischen dem Computer und dem Internet zulässt. Wie wäre es also?
Das intelligente Fahrsystem Qiankun ADS3.0 von Huawei wird im August auf den Markt kommen und erstmals auf dem Xiangjie S9 eingeführt
Jul 30, 2024 pm 02:17 PM
Am 29. Juli nahm Yu Chengdong, Huawei-Geschäftsführer, Vorsitzender von Terminal BG und Vorsitzender von Smart Car Solutions BU, an der Übergabezeremonie des 400.000sten Neuwagens von AITO Wenjie teil, hielt eine Rede und kündigte an, dass die Modelle der Wenjie-Serie dies tun werden Dieses Jahr auf den Markt kommen Im August wurde die Huawei Qiankun ADS 3.0-Version auf den Markt gebracht und es ist geplant, die Upgrades sukzessive von August bis September voranzutreiben. Das Xiangjie S9, das am 6. August auf den Markt kommt, wird erstmals mit dem intelligenten Fahrsystem ADS3.0 von Huawei ausgestattet sein. Mit Hilfe von Lidar wird Huawei Qiankun ADS3.0 seine intelligenten Fahrfähigkeiten erheblich verbessern, über integrierte End-to-End-Funktionen verfügen und eine neue End-to-End-Architektur von GOD (allgemeine Hinderniserkennung)/PDP (prädiktiv) einführen Entscheidungsfindung und Kontrolle), Bereitstellung der NCA-Funktion für intelligentes Fahren von Parkplatz zu Parkplatz und Aktualisierung von CAS3.0
Wie übertrage ich Dateien von Quark Cloud Disk auf Baidu Cloud Disk?
Mar 14, 2024 pm 02:07 PM
Quark Netdisk und Baidu Netdisk sind derzeit die am häufigsten verwendete Netdisk-Software zum Speichern von Dateien. Wenn Sie die Dateien in Quark Netdisk auf Baidu Netdisk speichern möchten, wie gehen Sie vor? In dieser Ausgabe hat der Herausgeber die Tutorial-Schritte zum Übertragen von Dateien vom Quark Network Disk-Computer auf die Baidu Network Disk zusammengestellt. Werfen wir einen Blick auf die Bedienung. Wie speichere ich Quark-Netzwerkfestplattendateien auf einer Baidu-Netzwerkfestplatte? Um Dateien von Quark Network Disk auf Baidu Network Disk zu übertragen, müssen Sie zunächst die erforderlichen Dateien von Quark Network Disk herunterladen, dann den Zielordner im Baidu Network Disk-Client auswählen und ihn öffnen. Ziehen Sie dann die von Quark Cloud Disk heruntergeladenen Dateien per Drag & Drop in den vom Baidu Cloud Disk-Client geöffneten Ordner oder verwenden Sie die Upload-Funktion, um die Dateien zu Baidu Cloud Disk hinzuzufügen. Überprüfen Sie nach Abschluss des Uploads unbedingt, ob die Datei erfolgreich in Baidu Cloud Disk übertragen wurde. Das ist es
Was ist die Datei hiberfil.sys? Kann hiberfil.sys gelöscht werden?
Mar 15, 2024 am 09:49 AM
Vor kurzem haben viele Internetnutzer den Herausgeber gefragt: Was ist die Datei hiberfil.sys? Kann hiberfil.sys viel Speicherplatz auf Laufwerk C beanspruchen und gelöscht werden? Der Editor kann Ihnen mitteilen, dass die Datei hiberfil.sys gelöscht werden kann. Werfen wir einen Blick auf die Details unten. hiberfil.sys ist eine versteckte Datei im Windows-System und auch eine System-Ruhezustandsdatei. Es wird normalerweise im Stammverzeichnis des Laufwerks C gespeichert und seine Größe entspricht der Größe des installierten Speichers des Systems. Diese Datei wird verwendet, wenn sich der Computer im Ruhezustand befindet, und enthält die Speicherdaten des aktuellen Systems, damit dieser bei der Wiederherstellung schnell wieder in den vorherigen Zustand versetzt werden kann. Da seine Größe der Speicherkapazität entspricht, nimmt er möglicherweise mehr Festplattenspeicher ein. hiber
Welche Version des Apple 16-Systems ist die beste?
Mar 08, 2024 pm 05:16 PM
Die beste Version des Apple 16-Systems ist iOS16.1.4. Die beste Version des iOS16-Systems kann von Person zu Person unterschiedlich sein. Die Ergänzungen und Verbesserungen im täglichen Nutzungserlebnis wurden auch von vielen Benutzern gelobt. Welche Version des Apple 16-Systems ist die beste? Antwort: iOS16.1.4 Die beste Version des iOS 16-Systems kann von Person zu Person unterschiedlich sein. Öffentlichen Informationen zufolge gilt iOS16, das 2022 auf den Markt kam, als eine sehr stabile und leistungsstarke Version, und die Benutzer sind mit dem Gesamterlebnis recht zufrieden. Darüber hinaus wurden die neuen Funktionen und Verbesserungen des täglichen Nutzungserlebnisses in iOS16 von vielen Benutzern gut angenommen. Insbesondere in Bezug auf die aktualisierte Akkulaufzeit, Signalleistung und Heizungssteuerung war das Feedback der Benutzer relativ positiv. Betrachtet man jedoch das iPhone14
Immer neu! Upgrade der Huawei Mate60-Serie auf HarmonyOS 4.2: KI-Cloud-Erweiterung, Xiaoyi-Dialekt ist so einfach zu bedienen
Jun 02, 2024 pm 02:58 PM
Am 11. April kündigte Huawei erstmals offiziell den 100-Maschinen-Upgradeplan für HarmonyOS 4.2 an. Dieses Mal werden mehr als 180 Geräte an dem Upgrade teilnehmen, darunter Mobiltelefone, Tablets, Uhren, Kopfhörer, Smart-Screens und andere Geräte. Im vergangenen Monat haben mit dem stetigen Fortschritt des HarmonyOS4.2-Upgradeplans für 100 Maschinen auch viele beliebte Modelle, darunter Huawei Pocket2, Huawei MateX5-Serie, Nova12-Serie, Huawei Pura-Serie usw., mit der Aktualisierung und Anpassung begonnen, was bedeutet, dass dass es mehr Benutzer von Huawei-Modellen geben wird, die das gemeinsame und oft neue Erlebnis von HarmonyOS genießen können. Den Rückmeldungen der Benutzer zufolge hat sich das Erlebnis der Modelle der Huawei Mate60-Serie nach dem Upgrade von HarmonyOS4.2 in allen Aspekten verbessert. Vor allem Huawei M
