ORA-600 kokiasg1故障分析---惜分飛

故障總結:客戶正常關閉數據庫,然后啟動報ORA-600 kokiasg1錯誤,通過對啟動分析確認是由于IDGEN1$序列丟失導致,修復該故障之后,數據庫啟動成功,但是后臺大量報ORA-600 12803,ORA-600 15264等錯誤,業務用戶無法登錄.經過深入分析,發現數據庫字典obj$中所有核心字典的序列全部被刪除,但是在seq$中這些對象的obj#記錄還存在.初步懷疑是有人惡意刪除了obj$中字典核心序列對象導致.
數據庫啟動報ORA-600 kokiasg1錯誤

SQL> startup ;

ORACLE 例程已經啟動。

Total System Global Area 1.4531E+10 bytes

Fixed Size????????????????? 2295256 bytes

Variable Size??????????? 2181040680 bytes

Database Buffers???????? 1.2314E+10 bytes

Redo Buffers?????????????? 33193984 bytes

數據庫裝載完畢。

ORA-01092: ORACLE instance terminated. Disconnection forced

ORA-00600: internal error code, arguments: [kokiasg1], [], [], [], [], [], [],

[], [], [], [], []

進程 ID: 5628

會話 ID: 122 序列號: 3

對應的alert日志信息

Thu Jul 03 16:35:25 2025

Shutting down instance (immediate)

Stopping background process SMCO

Shutting down instance: further logons disabled

Thu Jul 03 16:35:26 2025

Stopping background process CJQ0

Stopping background process QMNC

Stopping background process MMNL

Stopping background process MMON

License high water mark = 272

All dispatchers and shared servers shutdown

Thu Jul 03 16:35:54 2025

alter database close normal

Thu Jul 03 16:35:54 2025

SMON: disabling tx recovery

SMON: disabling cache recovery

Thu Jul 03 16:35:54 2025

Shutting down archive processes

Archiving is disabled

Archive process shutdown avoided: 0 active

Thread 1 closed at log sequence 296590

Successful close of redo thread 1

Completed: alter database close normal

alter database dismount

Shutting down archive processes

Archiving is disabled

Completed: alter database dismount

ARCH: Archival disabled due to shutdown: 1089

Shutting down archive processes

Archiving is disabled

ARCH: Archival disabled due to shutdown: 1089

Shutting down archive processes

Archiving is disabled

Thu Jul 03 16:36:02 2025

Stopping background process VKTM

Thu Jul 03 16:36:07 2025

Instance shutdown complete

Thu Jul 03 16:36:19 2025

Adjusting the default value of parameter parallel_max_servers

from 640 to 270 due to the value of parameter processes (300)

Starting ORACLE instance (normal)

LICENSE_MAX_SESSION = 0

LICENSE_SESSIONS_WARNING = 0

Initial number of CPU is 16

Number of processor cores in the system is 8

Number of processor sockets in the system is 1

Picked latch-free SCN scheme 3

Using LOG_ARCHIVE_DEST_1 parameter default value as USE_DB_RECOVERY_FILE_DEST

Autotune of undo retention is turned on.

IMODE=BR

ILAT =52

LICENSE_MAX_USERS = 0

SYS auditing is disabled

Starting up:

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options.

Windows NT Version V6.2?

CPU???????????????? : 16 - type 8664, 8 Physical Cores

Process Affinity??? : 0x0x0000000000000000

Memory (Avail/Total): Ph:24712M/32767M, Ph+PgF:14089M/39123M

System parameters with non-default values:

??processes??????????????? = 300

??sessions???????????????? = 480

??nls_language???????????? = "SIMPLIFIED CHINESE"

??nls_territory??????????? = "CHINA"

??sga_target?????????????? = 13920M

??control_files??????????? = "D:\APP\ADMINISTRATOR\ORADATA\orcl\CONTROL01.CTL"

??control_files??????????? = "D:\APP\ADMINISTRATOR\FAST_RECOVERY_AREA\orcl\CONTROL02.CTL"

??db_block_size??????????? = 8192

??compatible?????????????? = "11.2.0.4.0"

??db_recovery_file_dest??? = "D:\app\Administrator\fast_recovery_area"

??db_recovery_file_dest_size= 10G

??undo_tablespace????????? = "UNDOTBS1"

??remote_login_passwordfile= "EXCLUSIVE"

??db_domain??????????????? = ""

??dispatchers????????????? = "(PROTOCOL=TCP) (SERVICE=orclXDB)"

??job_queue_processes????? = 10

??audit_file_dest????????? = "D:\APP\ADMINISTRATOR\ADMIN\orcl\ADUMP"

??audit_trail????????????? = "DB"

??db_name????????????????? = "orcl"

??open_cursors???????????? = 300

??pga_aggregate_target???? = 4639M

??diagnostic_dest????????? = "D:\APP\ADMINISTRATOR"

Thu Jul 03 16:36:20 2025

PMON started with pid=2, OS id=13088

Thu Jul 03 16:36:20 2025

PSP0 started with pid=3, OS id=16168

Thu Jul 03 16:36:21 2025

VKTM started with pid=4, OS id=7948 at elevated priority

VKTM running at (10)millisec precision with DBRM quantum (100)ms

Thu Jul 03 16:36:21 2025

GEN0 started with pid=5, OS id=4192

Thu Jul 03 16:36:21 2025

DIAG started with pid=6, OS id=8232

Thu Jul 03 16:36:21 2025

DBRM started with pid=7, OS id=16436

Thu Jul 03 16:36:21 2025

DIA0 started with pid=8, OS id=11400

Thu Jul 03 16:36:21 2025

MMAN started with pid=9, OS id=11108

Thu Jul 03 16:36:21 2025

DBW0 started with pid=10, OS id=12232

Thu Jul 03 16:36:21 2025

DBW1 started with pid=11, OS id=7368

Thu Jul 03 16:36:21 2025

LGWR started with pid=12, OS id=13520

Thu Jul 03 16:36:21 2025

CKPT started with pid=13, OS id=11952

Thu Jul 03 16:36:21 2025

SMON started with pid=14, OS id=9304

Thu Jul 03 16:36:21 2025

RECO started with pid=15, OS id=17136

Thu Jul 03 16:36:21 2025

MMON started with pid=16, OS id=1984

Thu Jul 03 16:36:21 2025

MMNL started with pid=17, OS id=2568

starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'

starting up 1 shared server(s) ...

ORACLE_BASE from environment = D:\app\Administrator

Thu Jul 03 16:36:22 2025

alter database mount exclusive

Successful mount of redo thread 1, with mount id 1287723014

Database mounted in Exclusive Mode

Lost write protection disabled

Completed: alter database mount exclusive

alter database open

Thread 1 opened at log sequence 296590

??Current log# 1 seq# 296590 mem# 0: D:\APP\ADMINISTRATOR\ORADATA\orcl\REDO01.LOG

Successful open of redo thread 1

MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set

SMON: enabling cache recovery

[15144] Successfully onlined Undo Tablespace 2.

Undo initialization finished serial:0 start:3680275922 end:3680276032 diff:110 (1 seconds)

Verifying file header compatibility for 11g tablespace encryption..

Verifying 11g file header compatibility for tablespace encryption completed

SMON: enabling tx recovery

Database Characterset is ZHS16GBK

Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_ora_15144.trc? (incident=7579):

ORA-00600: 內部錯誤代碼, 參數: [kokiasg1], [], [], [], [], [], [], [], [], [], [], []

Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\incident\incdir_7579\orcl_ora_15144_i7579.trc

Use ADRCI or Support Workbench to package the incident.

See Note 411.1 at My Oracle Support for error and packaging details.

Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_ora_15144.trc:

ORA-00600: 內部錯誤代碼, 參數: [kokiasg1], [], [], [], [], [], [], [], [], [], [], []

Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl\orcl\trace\orcl_ora_15144.trc:

ORA-00600: 內部錯誤代碼, 參數: [kokiasg1], [], [], [], [], [], [], [], [], [], [], []

Error 600 happened during db open, shutting down database

USER (ospid: 15144): terminating the instance due to error 600

Instance terminated by USER, pid = 15144

ORA-1092 signalled during: alter database open...

對數據庫啟動過程進行跟蹤確認報錯可能和IDGEN1$對象有關系

PARSING IN CURSOR #615624160 len=30 dep=1 uid=0 oct=3 lid=0 tim=752975051401

???hv=3013659460 ad='7ffbd8f025d0' sqlid='6d8vr86tu1ku4'

select TOTAL from SYS.ID_GENS$

END OF STMT

PARSE #615624160:c=15625,e=2775,p=2,cr=14,cu=0,mis=1,r=0,dep=1,og=4,plh=1676180847,tim=752975051401

EXEC #615624160:c=0,e=6,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,plh=1676180847,tim=752975051452

WAIT #615624160: nam='db file sequential read' ela= 126 file#=1 block#=3440 blocks=1 obj#=514 tim=752975051594

WAIT #615624160: nam='db file sequential read' ela= 48 file#=1 block#=3441 blocks=1 obj#=514 tim=752975051671

FETCH #615624160:c=0,e=224,p=2,cr=3,cu=0,mis=0,r=1,dep=1,og=4,plh=1676180847,tim=752975051687

STAT #615624160 id=1 cnt=1 pid=0 pos=1 obj=514 op='TABLE ACCESS FULL ID_GENS$ (cr=3 pr=2 pw=0 time=223 us)'

CLOSE #615624160:c=0,e=15,dep=1,type=0,tim=752975051716

BINDS #12720440:

?Bind#0

??oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00

??oacflg=00 fl2=0001 frm=00 csi=00 siz=80 off=0

??kxsbbbfp=24b1b128? bln=22? avl=01? flg=05

??value=0

?Bind#1

??oacdty=01 mxl=32(07) mxlc=00 mal=00 scl=00 pre=00

??oacflg=10 fl2=0001 frm=01 csi=852 siz=0 off=24

??kxsbbbfp=24b1b140? bln=32? avl=07? flg=01

??value="IDGEN1$"

?Bind#2

??oacdty=02 mxl=22(22) mxlc=00 mal=00 scl=00 pre=00

??oacflg=00 fl2=0001 frm=00 csi=00 siz=0 off=56

??kxsbbbfp=24b1b160? bln=22? avl=02? flg=01

??value=1

EXEC #12720440:c=0,e=107,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,plh=2853959010,tim=752975051842

FETCH #12720440:c=0,e=5,p=0,cr=3,cu=0,mis=0,r=0,dep=1,og=4,plh=2853959010,tim=752975051856

CLOSE #12720440:c=0,e=0,dep=1,type=3,tim=752975051870

Incident 161 created, dump file: C:\APP\XFF\diag\rdbms\orcl\orcl\incident\incdir_161\orcl_ora_1880_i161.trc

ORA-00600: 內部錯誤代碼, 參數: [kokiasg1], [], [], [], [], [], [], [], [], [], [], []

ORA-00600: 內部錯誤代碼, 參數: [kokiasg1], [], [], [], [], [], [], [], [], [], [], []

ORA-00600: 內部錯誤代碼, 參數: [kokiasg1], [], [], [], [], [], [], [], [], [], [], []

從mos中確認當數據庫缺少IDGEN1$序列的時候,啟動會報ORA-600 kokiasg1錯誤.
?

ORA-600-kokiasg1


使用工具恢復obj$表到新庫中

E:\dump>imp test/oracle file=SYS_OBJ$.dmp full=y

Import: Release 11.2.0.4.0 - Production on 星期六 7月 5 09:34:42 2025

Copyright (c) 1982, 2011, Oracle and/or its affiliates.? All rights reserved.

連接到: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

經由常規路徑由 EXPORT:V08.01.07 創建的導出文件

警告: 這些對象由 SYS 導出, 而不是當前用戶

已經完成 ZHS16GBK 字符集和 AL16UTF16 NCHAR 字符集中的導入

導出服務器使用 UTF8 NCHAR 字符集 (可能的 ncharset 轉換)

. 正在將 SYS 的對象導入到 TEST

. 正在將 SYS 的對象導入到 TEST

. . 正在導入表????????????????????????? "OBJ$"導入了????? 103764 行

成功終止導入, 沒有出現警告。

查詢test.obj$表確認沒有IDGEN1$對象名稱記錄

SQL> select * from test.obj$ where name='IDGEN1$';

未選定行

SQL>

查詢正常obj$字典中關于IDGEN1$對象信息

SQL> select owner#, obj#,type# from obj$ where name='IDGEN1$';

????OWNER#?????? OBJ#????? TYPE#

---------- ---------- ----------

?????????0?????? 1229????????? 6

在故障庫恢復出來的test.obj$中查詢obj#為1229附近對象

SQL> select owner#, obj#,type#,name from test.obj$ where obj# in(1228,1229,1230);

????OWNER#?????? OBJ#????? TYPE# NAME

---------- ---------- ---------- ------------------------------

?????????0?????? 1228????????? 2 DST$TRIGGER_TABLE

?????????0?????? 1230???????? 13 BFILE

SQL> select owner#, obj#,type#,name from obj$ where obj# in(1228,1229,1230);

????OWNER#?????? OBJ#????? TYPE# NAME

---------- ---------- ---------- ------------------------------

?????????0?????? 1228????????? 2 DST$TRIGGER_TABLE

?????????0?????? 1229????????? 6 IDGEN1$

?????????0?????? 1230???????? 13 BFILE

目前看初步判斷故障庫確實由于IDGEN1$序列丟失導致無法啟動,處理過程相對比較簡單,在數據庫open的過程中,打開新會話創建IDGEN1$序列序列
?

11


?

22


然后重啟數據庫,即可正常啟動成功,讓看嘗試登錄數據庫報ora-600 12803錯誤
?

ORA-600-12803


再次檢查alert日志大量ORA-600錯誤

Fri Jul 04 15:57:13 2025

Errors in file C:\APP\XFF\diag\rdbms\orcl\orcl\trace\orcl_ora_27788.trc? (incident=12239):

ORA-00600: 內部錯誤代碼, 參數: [12803], [], [], [], [], [], [], [], [], [], [], []

Use ADRCI or Support Workbench to package the incident.

See Note 411.1 at My Oracle Support for error and packaging details.

Fri Jul 04 15:58:04 2025

Errors in file C:\APP\XFF\diag\rdbms\orcl\orcl\trace\orcl_mmon_1976.trc? (incident=12184):

ORA-00600: 內部錯誤代碼, 參數: [15264], [], [], [], [], [], [], [], [], [], [], []

Use ADRCI or Support Workbench to package the incident.

See Note 411.1 at My Oracle Support for error and packaging details.

基于這樣ORA-600錯誤,初步懷疑字典層面還有問題,因為最初的錯誤是序列異常,所以這次我重點對系統隊列進行分析,通過dul把seq$表恢復到test用戶中

E:\dump>imp test/oracle file=SYS_seq$.dmp full=y

Import: Release 11.2.0.4.0 - Production on 星期六 7月 5 10:10:17 2025

Copyright (c) 1982, 2011, Oracle and/or its affiliates.? All rights reserved.

連接到: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

經由常規路徑由 EXPORT:V08.01.07 創建的導出文件

警告: 這些對象由 SYS 導出, 而不是當前用戶

已經完成 ZHS16GBK 字符集和 AL16UTF16 NCHAR 字符集中的導入

導出服務器使用 UTF8 NCHAR 字符集 (可能的 ncharset 轉換)

. 正在將 SYS 的對象導入到 TEST

. 正在將 SYS 的對象導入到 TEST

. . 正在導入表????????????????????????? "SEQ$"導入了???????? 359 行

成功終止導入, 沒有出現警告。

查詢發現之前的序列(obj=1229)的竟然還在seq$中(obj$中沒有了記錄)

SQL> select * from test.seq$ where obj#=1229;

??????OBJ# INCREMENT$?? MINVALUE?? MAXVALUE???? CYCLE#???? ORDER$????? CACHE

---------- ---------- ---------- ---------- ---------- ---------- ----------

?HIGHWATER AUDIT$????????????????????????????????????? FLAGS

---------- -------------------------------------- ----------

??????1229???????? 50????????? 1 1.0000E+28????????? 0????????? 0?????? 1000

??60267151 --------------------------------??????????????? 0

這種現象證明seq 不是通過drop sequence命令刪除,而可能直接delete obj$表進行刪除,通過試驗重現正常刪除seq之后,obj$和seq$都會同步被刪除

SQL> create sequence xxxx;

序列已創建。

SQL> select obj#,type# from obj$ where name='XXXX';

??????OBJ#????? TYPE#

---------- ----------

?????87383????????? 6

SQL> SELECT * FROM SEQ$ WHERE OBJ#=87383;

??????OBJ# INCREMENT$?? MINVALUE?? MAXVALUE???? CYCLE#???? ORDER$????? CACHE

---------- ---------- ---------- ---------- ---------- ---------- ----------

?HIGHWATER AUDIT$????????????????????????????????????? FLAGS

---------- -------------------------------------- ----------

?????87383????????? 1????????? 1 1.0000E+28????????? 0????????? 0???????? 20

?????????1 --------------------------------??????????????? 0

SQL> DROP SEQUENCE XXXX;

序列已刪除。

SQL> SELECT * FROM SEQ$ WHERE OBJ#=87383;

未選定行

SQL> select obj#,type# from obj$ where name='XXXX';

未選定行

想到這里,那進一步分析,是否還有其他的系統序列被刪除,分析思路是:在一個正常的庫里面找出來SYS的seq的obj#,然后和test用戶里面的obj$,seq$表里面對比
找出來test.obj$中sys用戶的seq對象名字

SQL> select name,obj#,type# from test.obj$ where obj# in(

??2? select obj# from sys.obj$ where owner#=0 and type#=6)

??3? and type#=6;

未選定行

通過查詢確認故障庫中sys下面系統自帶的核心seq的對象名稱全部被刪除(obj$中明確被刪除),分析seq$中情況確認

QQ20250705-102429

SQL> select name,ctime from test.obj$ where type#=6 and owner#=0;

未選定行


通過上述相關核實,故障庫中的obj$中系統字典seq基本上被刪除(正常情況應該有130多個).對于這種情況,后續的類此比較簡單,通過seq$表內容,構造出來系統 seq的創建語句,對其進行創建,然后數據庫恢復正常,完成本次恢復工作.

本文來自互聯網用戶投稿,該文觀點僅代表作者本人,不代表本站立場。本站僅提供信息存儲空間服務,不擁有所有權,不承擔相關法律責任。
如若轉載,請注明出處:http://www.pswp.cn/bicheng/88134.shtml
繁體地址,請注明出處:http://hk.pswp.cn/bicheng/88134.shtml
英文地址,請注明出處:http://en.pswp.cn/bicheng/88134.shtml

如若內容造成侵權/違法違規/事實不符,請聯系多彩編程網進行投訴反饋email:809451989@qq.com,一經查實,立即刪除!

相關文章

[RPA] 影刀RPA基本知識

1.應用的構成一個應用:由多條指令疊加組成一條指令代表了一個操作動作許多條指令按照一定的邏輯關系編排起來,就構成了一個應用(這里的應用可理解為軟件機器人RPA)一個應用 多個自動化指令的集合 2. 指令的一般構成在XXX對象上,對XXX元素執行…

pytest中測試特定接口

在pytest中只測試特定接口有以下幾種常用方法: 1. 通過測試函數名精確匹配 直接指定測試文件和函數名: pytest test_api.py::test_upload_image_with_library這將只運行test_api.py文件中名為test_upload_image_with_library的測試函數。 2. 使用關鍵字匹…

HMI圖形渲染優化:OpenGL ES與Vulkan的性能對比實戰

HMI 圖形渲染優化:OpenGL ES 與 Vulkan 的性能對比實戰**摘要想讓 HMI 界面的圖形渲染又快又流暢,卻在 OpenGL ES 和 Vulkan 之間糾結不已!用 OpenGL ES,擔心性能不夠強勁,無法滿足復雜場景需求;選 Vulkan&…

Python數據分析基礎01:描述性統計分析

下一篇: 《Python數據分析基礎04:預測性數據分析》 《Python數據分析基礎03:探索性數據分析》 《python數據分析基礎02:數據可視化分析》 《Python數據分析基礎01:描述性統計分析》 描述性統計分析是統計學中最基…

成員不更新項目進度,如何建立進度更新機制

項目成員不及時更新進度的主要原因包括責任不明確、缺乏更新規則、溝通機制不暢、進度意識薄弱、工具使用不當等。其中尤其需要關注的是建立清晰的進度更新規則。明確規定成員應何時、如何、向誰匯報進度情況,使得項目的每項任務都有責任人和明確的更新頻率及形式&a…

JVM 整體架構詳解:線程私有與線程共享內存區域劃分

Java 虛擬機(JVM)作為 Java 程序運行的基礎,其內存模型和線程結構設計直接影響著程序的執行效率和穩定性。本文將從 線程是否共享 的角度出發,對 JVM 的整體內存結構進行清晰分類與簡明解析。一、JVM 內存區域劃分概覽 根據是否被…

【Linux庖丁解牛】— 庫的理解與加載!

1. 目標文件編譯和鏈接這兩個步驟,在Windows下被我們的IDE封裝的很完美,我們?般都是?鍵構建?常?便, 但?旦遇到錯誤的時候呢,尤其是鏈接相關的錯誤,很多?就束??策了。在Linux下,我們之前也學 習過如…

QML事件處理:鼠標、拖拽與鍵盤事件

在QML應用開發中,用戶交互是構建動態界面的核心。本文將全面解析QML中的三大交互事件:鼠標事件、拖拽事件和鍵盤事件,通過實際代碼示例展示如何實現豐富的用戶交互體驗。一、鼠標事件處理1. MouseArea基礎MouseArea是QML中處理鼠標交互的核心…

MySQL 8.0 OCP 1Z0-908 題目解析(20)

題目77 Choose the best answer. Which step or set of steps can be used to rotate the error log? ○ A) Execute SET GLOBAL max_error_count . ○ B) Rename the error log file on disk, and then execute FLUSH ERROR LOGS. ○ C) Execute SET GLOBAL log_error ‘’…

八股學習(四)---MySQL

一、MySQL如何進行SQL調優?我的回答:面試官好!我想從SQL語句本身和數據庫結構兩方面來做MySQL的SQL調優。首先會優化SQL寫法,比如避免用SELECT *、減少子查詢嵌套,用JOIN代替,還有合理使用索引,…

華中科大首創DNN衍射量子芯片登《Science Advances》:3D打印實現160μm3高維邏輯門

01 前言華中科技大學王健/劉駿團隊在《Science Advances》發表突破性研究,利用飛秒激光三維打印技術,制造出全球首個聚合物基超緊湊高維量子光芯片。該芯片僅160微米見方(約頭發絲直徑的1.5倍),卻實現了光子空間模式的…

【排序】插入排序

如果你已經對排序略知一二,現在正在復習排序的一些重點知識 ------------------------------------------------------------------------------------------------------------------------- 點贊收藏🌈,每天更新總結文章(多以圖…

扣子Coze怎么模仿人類輸出(分段輸出)?

效果: 讓AI回復的更像人類 教程: 工作流: 假設大模型節點就是需要的回復,并且已經按句號(。)區別開每句話 后面連接一個 文本處理 節點,選擇“字符串分隔”,按“。”進行分割 分…

Android 應用開發 | 一種限制拷貝速率解決因 IO 過高導致系統卡頓的方法

文章目錄一、問題背景二、代碼實現一、問題背景 經常做 Android 應用的小伙伴應該會有經驗,就是如果應用在寫入文件的時候,即使寫文件的動作是在子線程,也會出現 UI 上的卡頓,這是因為文件的 IO 是由內核去完成的,此時…

力扣面試150(19/150)

7.7 12. 整數轉羅馬數字 七個不同的符號代表羅馬數字,其值如下: 符號值I1V5X10L50C100D500M1000 羅馬數字是通過添加從最高到最低的小數位值的轉換而形成的。將小數位值轉換為羅馬數字有以下規則: 如果該值不是以 4 或 9 開頭,…

數據結構與算法——從遞歸入手一維動態規劃【1】

前言: 簡單記錄對左程云系列算法課程--算法講解066【必備】的學習,這是第一篇。主要提供C代碼和一些簡單的個人理解,如需要細致講解請移步原視頻。 涉及內容: 斐波那契數列、動態規劃 參考視頻: 左程云--算法講解…

搭建個人博客系列--Nacos 注冊中心

基礎項目已完成,接下來就是SpringCloud的各種組件了。 那你又要問:既然有Nacos為什么之前還裝了Apollo? 那你別管,那不得什么都會點,不然怎么找工作。干就完了。 一、安裝Nacos 管他三七二十一,先在doc…

前端實習總結——案例與大綱

以下是一個結合真實場景的前端面試案例,包含面試流程、核心問題、候選人回答思路及面試官考察點,可直觀感受如何在面試中展現實習/項目經歷: 案例背景 候選人:應屆生,有6個月前端實習經歷,參與過“企業內部…

Web前端開發: :where(偽類函數選擇器)

:where(偽類函數選擇器)::where() 是 CSS Selectors Level 4 規范中引入的一個強大的偽類函數選擇器,它允許開發者以簡潔的方式編寫復雜的選擇器,同時具有獨特的優先級特性。核心概念::where() 偽類函數選擇器與 :is() 非常相似&a…

EfficientVMamba: Atrous Selective Scan for Light Weight Visual Mamba論文精讀(逐段解析)

EfficientVMamba: Atrous Selective Scan for Light Weight Visual Mamba論文精讀(逐段解析) 論文地址:https://arxiv.org/abs/2403.09977 CVPR 2024 Abstract. Prior efforts in light-weight model development mainly centered on CNN an…