欧美黄在线观看,国产视频播放,九九九精品,久久成人免费91影片,国产爆乳肥臀在线观看,国产极品人妖ts91热爆,亚洲成人精品视频,国产小电影在线观看

導(dǎo)讀：DBA的大部分工作都是圍繞著對(duì)數(shù)據(jù)庫的維護(hù)而展開的，常規(guī)的日常維護(hù)更是占了絕大多數(shù)。本節(jié)將圍繞日常維護(hù)中最常見的三個(gè)案例展開講解，與大家分享排查此類問題的思路。

作者：葉樺徐浩張夢(mèng)穎應(yīng)以峰

來源：大數(shù)據(jù)DT（ID：hzdashuju）

01 TX鎖處理

TX鎖，也稱事務(wù)鎖或行級(jí)鎖，是控制數(shù)據(jù)庫并發(fā)訪問的一項(xiàng)重要技術(shù)，也是數(shù)據(jù)完整性和一致性的重要保證。本文不會(huì)過多闡述鎖的類型和具體原理，而是重點(diǎn)講解在生產(chǎn)環(huán)境中遇到鎖的時(shí)候，如何快速查找源頭并進(jìn)行查殺。

有經(jīng)驗(yàn)的DBA在遇到TX鎖時(shí)，第一反應(yīng)就是查詢v$lock和v$session視圖，定位LMODE和REQUEST類型互斥的會(huì)話并進(jìn)行查殺。然而，隨著數(shù)據(jù)庫版本不斷地迭代更新，v$session視圖的內(nèi)容越來越豐富，可以直接使用blocking_session、blocking_instance、final_blocking_instance和final_blocking_session字段進(jìn)行定位。

對(duì)于鎖層次的排查可以重復(fù)查詢v$session來確定，但如果鎖層次有100層，那么通過人工遍歷100次的方式，顯然過于低效，不適用于生產(chǎn)環(huán)境。

下面就來介紹本節(jié)的主角：Oracle的SYS_CONNECT_BY_PATH函數(shù)。

自O(shè)racle 9i開始，DBA就可以使用SYS_CONNECT_BY_PATH函數(shù)將父節(jié)點(diǎn)到當(dāng)前行的內(nèi)容以“路徑”或?qū)哟蔚男问斤@示出來。該功能剛好符合我們遞歸查找鎖層次的需求，在這里，筆者模擬了鎖環(huán)境，可以使用如下語句查詢鎖信息：

SQL> select a.inst_id,
       a.process,
       a.sid,
       a.serial#,
       a.sql_id,
       a.event,
       a.status,
       a.program,
       a.machine,
       connect_by_isleaf as isleaf,
       sys_connect_by_path(a.SID || '@' || a.inst_id, ' <- ') tree,
       level as tree_level
  from gv$session a
 start with a.blocking_session is not null
connect by (a.sid || '@' || a.inst_id) = prior
           (a.blocking_session || '@' || a.blocking_instance);
<!--省略部分列-->
INST_ID PROCESS SID  SERIAL# EVENT                         STATUS  ISLEAF TREE            TREE_LEVEL
------- ------- ---- ------- ----------------------------- ------- ------ --------------- ---------
      1    7663   17    6749 enq: TX - row lock contention ACTIVE       0 <- 17@1                 1
      1    6198   25    9989 SQL*Net message from client   INACTIVE     1 <- 17@1 <- 25@1         2
      1    6310   28   23199 enq: TX - row lock contention ACTIVE       0 <- 28@1                 1
      1    6198   25    9989 SQL*Net message from client   INACTIVE     1 <- 28@1 <- 25@1         2

下面對(duì)代碼段中的部分參數(shù)進(jìn)行說明。

INST_ID：會(huì)話所在的節(jié)點(diǎn)號(hào)。
PROCESS：客戶端進(jìn)程號(hào)，與v$process中的spid不是同一個(gè)。
SID、SERIAL#、SQL_ID、STATUS、PROGRAM、MACHINE：會(huì)話信息。
ISLEAF：是否為源頭，0代表否，1代表是。
TREE：樹形結(jié)構(gòu)，鎖的層次，例如，<- 152@2 <- 153@2 <- 161@1，從左到右依次表示為節(jié)點(diǎn)2的會(huì)話152被節(jié)點(diǎn)2的會(huì)話153堵塞，而節(jié)點(diǎn)2的會(huì)話153又被節(jié)點(diǎn)1的會(huì)話161堵塞。所以節(jié)點(diǎn)1的會(huì)話161是鎖的源頭。
TREE_LEVEL：樹形層次。

鎖源頭的查殺方法有兩種，說明如下。

1）通過ISLEAF進(jìn)行篩選，直接查殺鎖源頭，語句如下：

SQL> select 'alter system kill session ''' || sid || '' || ',' || serial# || ',@' ||
       inst_id || ''' immediate;' db_kill_session
  from (select a.inst_id,
               a.process,
               a.sid,
               a.serial#,
               a.sql_id,
               a.event,
               a.status,
               a.program,
               a.machine,
               connect_by_isleaf as isleaf,
               sys_connect_by_path(a.SID || '@' || a.inst_id, ' <- ') tree,
               level as tree_level
          from gv$session a
         start with a.blocking_session is not null
        connect by (a.sid || '@' || a.inst_id) = prior
                   (a.blocking_session || '@' || a.blocking_instance))
 where isleaf = 1
 order by tree_level asc;
KILL_SESSION
---------------------------------------------------
alter system kill session '161,5579,@1' immediate;
alter system kill session '161,5579,@1' immediate;

SQL> select inst_id, 'kill -9 ' || spid os_kill_session
  from (select p.inst_id,
               p.spid,
               a.sid,
               a.serial#,
               a.sql_id,
               a.event,
               a.status,
               a.program,
               a.machine,
               connect_by_isleaf as isleaf,
               sys_connect_by_path(a.SID || '@' || a.inst_id, ' <- ') tree,
               level as tree_level
          from gv$session a, gv$process p
         where a.inst_id = p.inst_id
           and a.paddr = p.addr
         start with a.blocking_session is not null
        connect by (a.sid || '@' || a.inst_id) = prior
                   (a.blocking_session || '@' || a.blocking_instance))
 where isleaf = 1
 order by tree_level asc; 
   INST_ID OS_KILL_SESSION
---------- --------------------------------
         1 kill -9 30049

2）借助v$session中的final_blocking_instance和final_blocking_session定位鎖源頭，語句如下：

SQL> select 'alter system kill session ''' || ss.sid || '' || ',' || ss.serial# || ',@' ||
       ss.inst_id || ''' immediate;' db_kill_session
  from gv$session s, gv$session ss
 where s.final_blocking_session is not null
   and s.final_blocking_instance = ss.inst_id
   and s.final_blocking_session = ss.sid
   and s.sid <> ss.sid
DB_KILL_SESSION
--------------------------------------------------
alter system kill session '161,5579,@1' immediate;
alter system kill session '161,5579,@1' immediate;

SQL> select p.inst_id, 'kill -9 ' || p.spid os_kill_session
  from gv$session s, gv$session ss, gv$process p
 where s.final_blocking_session is not null
   and s.final_blocking_instance = ss.inst_id
   and s.final_blocking_session = ss.sid
   and ss.paddr = p.addr
   and ss.inst_id = p.inst_id
   and s.sid <> ss.sid
   INST_ID OS_KILL_SESSION
---------- --------------------------------
         1 kill -9 30049

執(zhí)行拼接生成的語句，即可殺掉鎖的源頭。

想必大家都遇到過在數(shù)據(jù)庫層面發(fā)起“alter system kill session”（數(shù)據(jù)庫層殺掉會(huì)話，不加immediate關(guān)鍵字）時(shí)，經(jīng)常會(huì)出現(xiàn)資源無法及時(shí)釋放、會(huì)話一直處于killed狀態(tài)的情況。

如果這個(gè)會(huì)話是鎖的源頭，那么除了等待PMON（進(jìn)程監(jiān)視器）來清理之外，再?zèng)]有更好的辦法了，而在操作系統(tǒng)層面殺掉進(jìn)程的方式，基本上是百試百靈。

使用系統(tǒng)命令“kill -9”殺死進(jìn)程，系統(tǒng)向該process進(jìn)程發(fā)出sigkill，sigkill信號(hào)直接發(fā)送給init進(jìn)程，終止process進(jìn)程。這種方式直接終止了Oracle 會(huì)話中對(duì)應(yīng)的操作進(jìn)程，資源也可以直接釋放。

下面就來重點(diǎn)講解“alter system kill session”的過程，以及在“alter system kill session”殺掉會(huì)話之后，為何會(huì)查不到處于killed狀態(tài)的會(huì)話所對(duì)應(yīng)的系統(tǒng)進(jìn)程spid。

“alter system kill session”（不加immediate關(guān)鍵字）殺掉會(huì)話可分為兩種場(chǎng)景進(jìn)行討論：會(huì)話狀態(tài)分別是active和inactive。

使用此命令殺掉處于active狀態(tài)的會(huì)話時(shí)，過程可以簡(jiǎn)單概括如下：

會(huì)話在收到kill信號(hào)后進(jìn)行回滾，此過程不可被中斷，直至過程完成，該會(huì)話會(huì)接收到“ORA-00028: your session has been killed”信息，PMON清理會(huì)話，釋放資源。如果1分鐘過后，上述動(dòng)作還未完成，則該會(huì)話將被標(biāo)記為killed狀態(tài)，若會(huì)話擁有的資源未釋放，則等待PMON進(jìn)程清理會(huì)話。

使用此命令殺掉處于inactive狀態(tài)的會(huì)話時(shí)，過程可以簡(jiǎn)單概括如下：

會(huì)話在收到kill信號(hào)后被標(biāo)記為killed狀態(tài)，會(huì)話擁有的資源未釋放，等待PMON進(jìn)程清理會(huì)話。如果會(huì)話再次發(fā)出查詢信號(hào)，會(huì)話就會(huì)接收到“ORA-00028: your session has been killed”信息，PMON清理會(huì)話，釋放資源。

接下來模擬不加immediate參數(shù)，殺掉會(huì)話后狀態(tài)被標(biāo)記為killed，操作系統(tǒng)查不到進(jìn)程的實(shí)驗(yàn)場(chǎng)景，過程如下：

SQL> select username,sid,serial#,paddr,server,status from v$session where username = 'SCOTT';

USERNAME     SID    SERIAL# PADDR            SERVER    STATUS
---------- ----- ---------- ---------------- --------- --------
SCOTT         17       6733 00000000A34C7040 DEDICATED INACTIVE
SCOTT        158       9177 00000000A34D4998 DEDICATED INACTIVE

SQL> select b.sid,b.serial#,c.spid,b.status from v$session b,v$process c where 
    b.paddr = c.addr and b.sid in (17,158);
 SID    SERIAL# SPID      STATUS
---- ---------- --------- --------
  17       6733 23883     INACTIVE
 158       9177 24120     INACTIVE

手動(dòng)殺掉這兩個(gè)會(huì)話的命令如下：

SQL> alter system kill session '17,6733';
SQL> alter system kill session '158,9177';

再次查詢這兩個(gè)會(huì)話的狀態(tài)，命令及結(jié)果如下：

SQL> select username,sid,serial#,paddr,server,status from v$session where username = 'SCOTT';
USERNAME    SID    SERIAL# PADDR            SERVER    STATUS
---------- ---- ---------- ---------------- --------- --------
SCOTT        17       6733 00000000A3551F18 PSEUDO    KILLED
SCOTT       158       9177 00000000A3551F18 PSEUDO    KILLED

從代碼中我們可以發(fā)現(xiàn)，當(dāng)兩個(gè)會(huì)話的狀態(tài)為killed時(shí)，會(huì)話的paddr指向同一地址00000000A3551F18（虛擬地址），此地址在操作系統(tǒng)層面并無對(duì)應(yīng)的spid，這就是當(dāng)會(huì)話的狀態(tài)變?yōu)閗illed之后，使用以下語句查不到spid的原因，查詢示例代碼如下所示：

SQL> select b.sid,b.serial#,c.spid,b.status from v$session b,v$process c where 
    b.paddr = c.addr and b.sid in (17,158);
no rows selected

此時(shí)，我們就可以使用前文的查詢語句，查殺并清理會(huì)話，命令及結(jié)果如下：

SQL> select 'alter system kill session ''' || c.sid || '' || ',' || c.serial# || '''
    immediate;' kill_session from v$session c where status='KILLED';
KILL_SESSION
-----------------------------------------------
alter system kill session '17,6733' immediate;
alter system kill session '158,9177' immediate;

因此，在查殺會(huì)話時(shí)，可以考慮直接使用“alter system kill session 'sid,serial#' immediate”命令快速清理會(huì)話。需要注意的是，在查殺會(huì)話之前一定要再三確認(rèn)信息，千萬不要誤殺了系統(tǒng)核心進(jìn)程。

02 高峰期謹(jǐn)慎編譯業(yè)務(wù)對(duì)象

想必大家都遇到過這樣的情況，在業(yè)務(wù)高峰期如果編譯存儲(chǔ)過程、函數(shù)或視圖，就會(huì)導(dǎo)致大量使用該對(duì)象的會(huì)話堵塞，自身也將處于掛起狀態(tài)，后臺(tái)等待事件為“l(fā)ibrary cache pin”。

在日常運(yùn)維中，“l(fā)ibrary cache”相關(guān)等待較為常見，主要分為“l(fā)ibrary cache lock”或“l(fā)ibrary cache pin”，前者維護(hù)“l(fā)ibrary object handle”上的并發(fā)訪問，后者維護(hù)“l(fā)ibrary object handle”下對(duì)應(yīng)heap的并發(fā)訪問，lock管理并發(fā)，pin管理一致性。

當(dāng)我們編譯存儲(chǔ)過程、函數(shù)或視圖的時(shí)候，Oracle就會(huì)在這些對(duì)象的handle上獲得一個(gè)“l(fā)ibrary cache lock”，然后在這些對(duì)象的heap上獲得pin，這樣就能保證在編譯的時(shí)候其他進(jìn)程不會(huì)來更改這些對(duì)象。

有了以上的理論基礎(chǔ)，當(dāng)高峰期編譯對(duì)象出現(xiàn)會(huì)話堵塞的問題時(shí)，我們應(yīng)該如何處理呢？這里就會(huì)用到基表DBA_KGLLOCK，其包含如下兩個(gè)字段。

kgllkuse字段：“Address of the user session that holds the lock or pin”，主要用于記錄持有l(wèi)ock或pin的用戶地址。
kgllkhdl字段：“Address of the handle for the KGL object”，主要用于記錄handle的對(duì)象地址。

故障發(fā)生時(shí)，首先查看后臺(tái)等待事件，命令及輸出具體如下：

SQL> select inst_id,sid, event, p1,p1text,p1raw,p2,p2text,p2raw from gv$session 
    where wait_class<>'Idle';

INST_ID  SID EVENT              P1 P1TEXT                   P1RAW         
------- ---- ------------------ -------------------------   ---------------- 
      1   33 library cache pin  2081944584 handle address   000000007C17F408

根據(jù)等待事件“l(fā)ibrary cache pin”獲取“p1 handle address 000000007C17F408”。

關(guān)聯(lián)視圖“dba_kgllock dk,v$session”獲取鎖信息，命令及輸出如下：

SQL> select s.sid,s.sql_id,s.event,dk.* from dba_kgllock dk,v$session s where 
    s.saddr = dk.KGLLKUSE and KGLLKHDL='000000007C17F408';

SID SQL_ID       EVENT         KGLLKUSE            KGLLKHDL         KGLLKMOD KGLLKREQ KGLL
--- ------------ ------------- ------------------- ---------------- -------- -------- ----
33  087rrdjwc2act library cache pin 00000000A92FC040 000000007C17F408        3         0  Lock
33  087rrdjwc2act library cache pin 00000000A92FC040 000000007C17F408        0         3  Pin

從以上返回結(jié)果中可以看出，我們并沒有找到pin的持有者，KGLLKREQ表示當(dāng)前會(huì)話需要申請(qǐng)的鎖模式，KGLLKMOD表示當(dāng)前系統(tǒng)中持有的鎖模式，由于該系統(tǒng)為RAC，各節(jié)點(diǎn)之間的內(nèi)存結(jié)構(gòu)不同，handle地址不能公用，因此我們需要定位出owner和object_name在其他節(jié)點(diǎn)持有pin的會(huì)話。命令及輸出如下：

SQL> select ADDR,INDX,INST_ID,KGLHDADR,KGLNAOWN,KGLNAOBJ from x$kglob where 
    KGLHDADR='000000007C17F408';

ADDR             INDX INST_ID KGLHDADR         KGLNAOWN   KGLNAOBJ
---------------- ---- ------- ---------------- ---------- ---------
00007FE9B0B45850 4979       1 000000007C17F408 SYS        DUMMY

其中，x$kglob為“l(fā)ibrary cache object”對(duì)象的視圖。

RAC節(jié)點(diǎn)2根據(jù)object_name查找對(duì)應(yīng)的handle地址信息，命令及輸出如下：

SQL> select ADDR,INDX,INST_ID,KGLHDADR,KGLNAOWN,KGLNAOBJ from x$kglob where 
    KGLNAOBJ='DUMMY'

ADDR             INDX INST_ID KGLHDADR         KGLNAOWN  KGLNAOBJ
---------------- ---- ------- ---------------- --------- ---------
00007F987B1D8ED0 4150       2 00000000AA193870 SYS       DUMMY

查看鎖的持有情況，命令及輸出如下：

SQL> select s.sid,s.sql_id,s.event,dk.* from dba_kgllock dk,v$session s where 
    s.saddr = dk.KGLLKUSE and KGLLKHDL='00000000AA193870';

SID SQL_ID        EVENT             KGLLKUSE         KGLLKHDL         KGLLKMOD KGLLKREQ KGLL
--- ------------  ----------------- ---------------- ---------------- -------- -------- ----
424 d4wnj5j8y1mq7 PL/SQL lock timer 00000000A9787DA0 00000000AA193870        1        0 Lock
424 d4wnj5j8y1mq7 PL/SQL lock timer 00000000A9787DA0 00000000AA193870        2        0 Pin

最終定位節(jié)點(diǎn)2上的會(huì)話424持有的模式為2（即共享模式）的鎖，堵塞了KGLLKREQ 3排它鎖的申請(qǐng)，為了能夠順利編譯，我們只需要?dú)⒌艄?jié)點(diǎn)2上的會(huì)話424即可。

03 數(shù)據(jù)誤刪恢復(fù)

在筆者多年的工作經(jīng)歷中，時(shí)常會(huì)遇到數(shù)據(jù)被隨意篡改或刪除的情況，那么在沒有備份的情況下又該如何恢復(fù)數(shù)據(jù)呢。

對(duì)于drop操作（刪除整個(gè)表，包括結(jié)構(gòu)和數(shù)據(jù)），如果沒有使用purge參數(shù)，那么我們可以使用回收站進(jìn)行恢復(fù)，而對(duì)于truncate操作（只刪除數(shù)據(jù)，不刪除表的結(jié)構(gòu)），則需要使用非常規(guī)的恢復(fù)方法，這些不在本書的討論范圍之內(nèi)，本節(jié)將以delete為例演示數(shù)據(jù)被誤刪后的恢復(fù)。

1. 利用undo閃回查詢

根據(jù)undo信息，利用前鏡像，可以把表置于一個(gè)刪除前的時(shí)間點(diǎn)或SCN（System Change Number），從而找回?cái)?shù)據(jù)。具體命令如下：

SQL> select * from emp as of timestamp to_timestamp('2019-11-05 08:00:00', 'YYYY-
    MM-DD HH:MI:SS');

但是此方法會(huì)受限于undo_retention的配置，默認(rèn)情況下，undo_retention的值為900秒，即在刪除數(shù)據(jù)900秒之后，undo中的數(shù)據(jù)會(huì)過期。

但如果業(yè)務(wù)比較繁忙，在undo表空間不足的情況下，即使鏡像沒有過期，數(shù)據(jù)也還是會(huì)被覆蓋。若此時(shí)查詢就會(huì)收到“ORA-08180: no snapshot found based on specified time”的報(bào)錯(cuò)信息。

2. logminer挖掘

數(shù)據(jù)庫所有DML（數(shù)據(jù)操縱語言）的操作都會(huì)記錄在redo日志中，只要?dú)w檔文件還存在，那么所有DML的記錄都可以找回，使用方法如下。

1）確定DML時(shí)間點(diǎn)日志信息，命令如下：

SQL> select t.THREAD#, t.SEQUENCE#, t.NAME
    from v$archived_log t
    where t.FIRST_TIME >=to_date('2019-11-05 10:24:30', 'yyyy-mm-dd hh24:mi:ss')
    and t.NEXT_TIME <=to_date('2019-11-05 14:00:30', 'yyyy-mm-dd hh24:mi:ss');
    THREAD#  SEQUENCE# NAME
---------- ---------- --------------------------------------------------
         1          2 /app_target/easdb_dg/arch/1_2_1023532682.dbf
         1          1 /app_target/easdb_dg/arch/1_1_1023532682.dbf
         1          3 /app_target/easdb_dg/arch/1_3_1023532682.dbf

2）安裝logminer安裝包，默認(rèn)系統(tǒng)自帶該安裝包，安裝命令如下：

SQL> @$ORACLE_HOME/rdbms/admin/dbmslm.sql
Package created.
Grant succeeded.
Synonym created.

3）添加挖掘日志，添加命令如下：

SQL> execute dbms_logmnr.add_logfile(logfilename=>'/app_target/easdb_dg/arch/
    1_2_1023532682.dbf',options=>dbms_logmnr.new);
<!--繼續(xù)添加-->
SQL> execute dbms_logmnr.add_logfile(logfilename=>'/app_target/easdb_dg/arch/
    1_1_1023532682.dbf',options=>dbms_logmnr.addfile);
SQL> execute dbms_logmnr.add_logfile(logfilename=>'/app_target/easdb_dg/arch/
    1_3_1023532682.dbf',options=>dbms_logmnr.addfile);

注意：第一個(gè)添加日志選項(xiàng)是new，后續(xù)添加選項(xiàng)是addfile。

4）開啟logminer，命令如下：

SQL> execute dbms_logmnr.start_logmnr(Options => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);

5）查詢v$logmnr_contents視圖獲取挖掘信息，命令如下：

SQL> select sql_redo from v$logmnr_contents where SEG_OWNER='SCOTT';
<!--sql_redo用于記錄當(dāng)時(shí)DML的操作記錄-->
SQL> select sql_undo from v$logmnr_contents where SEG_OWNER='SCOTT';
<!--若是誤操作回退，則可以使用sql_undo，執(zhí)行還原操作-->

最終，我們可以根據(jù)sql_undo進(jìn)行DML誤操作恢復(fù)。

關(guān)于作者：葉樺，Oracle OCM，MySQL認(rèn)證專家，超10年乙方數(shù)據(jù)庫維護(hù)經(jīng)驗(yàn)，美創(chuàng)科技運(yùn)維服務(wù)團(tuán)隊(duì)負(fù)責(zé)人。具備豐富的行業(yè)經(jīng)驗(yàn)與技術(shù)積累，所服務(wù)的對(duì)象包括大型運(yùn)營(yíng)商、金融機(jī)構(gòu)、政府機(jī)關(guān)以及制造業(yè)等多個(gè)行業(yè)客戶，對(duì)于數(shù)據(jù)庫技術(shù)具有深刻的理解。精通Oracle和MySQL數(shù)據(jù)庫內(nèi)核原理、架構(gòu)規(guī)劃和調(diào)優(yōu)診斷，擅長(zhǎng)Shell和Python自動(dòng)化運(yùn)維開發(fā)。

徐浩，美創(chuàng)科技運(yùn)維部經(jīng)理，Oracle、MySQL、云數(shù)據(jù)庫高級(jí)認(rèn)證專家。擁有8年以上的數(shù)據(jù)庫領(lǐng)域從業(yè)經(jīng)驗(yàn)，TB級(jí)高并發(fā)數(shù)據(jù)庫與中大型項(xiàng)目的管理經(jīng)驗(yàn)。對(duì)于分布式高可用架構(gòu)和性能調(diào)優(yōu)有著豐富的實(shí)戰(zhàn)經(jīng)驗(yàn)，擅長(zhǎng)故障診斷及數(shù)據(jù)災(zāi)難挽救，服務(wù)的行業(yè)包括運(yùn)營(yíng)商、制造業(yè)、金融、醫(yī)療、政府等。目前，主要負(fù)責(zé)Oracle、MySQL、阿里云等技術(shù)的研究和運(yùn)維管理，以及數(shù)據(jù)庫智能運(yùn)維平臺(tái)的設(shè)計(jì)開發(fā)等工作。

本文摘編自《DBA攻堅(jiān)指南：左手Oracle，右手MySQL》，經(jīng)出版方授權(quán)發(fā)布。

延伸閱讀《DBA攻堅(jiān)指南》

點(diǎn)擊上圖了解及購買

轉(zhuǎn)載請(qǐng)聯(lián)系微信：DoctorData

推薦語：本書是資深Oracle、MySQL技術(shù)專家嘔心瀝血之作，積作者多年的經(jīng)驗(yàn)結(jié)晶和實(shí)踐經(jīng)驗(yàn)，也是目前市場(chǎng)上為數(shù)不多Oracle和MySQL相結(jié)合的數(shù)據(jù)庫技術(shù)書籍。

劃重點(diǎn)??

干貨直達(dá)??

史上最全！用Pandas讀取CSV，看這篇就夠了
既然中臺(tái)建設(shè)這么重要，為什么還有那么多人反對(duì)？
在中國，找個(gè)身高1米7年入20萬的老公，到底有多難？
女生學(xué)不好數(shù)理化，真的嗎？

更多精彩??

在公眾號(hào)對(duì)話框輸入以下關(guān)鍵詞

查看更多優(yōu)質(zhì)內(nèi)容！

PPT | 讀書 | 書單 | 硬核 | 干貨 | 講明白 | 神操作

AI | 人工智能 | 機(jī)器學(xué)習(xí) | 深度學(xué)習(xí) | NLP

5G | 中臺(tái) | 用戶畫像 | 1024 | 數(shù)學(xué) | 算法 | 數(shù)字孿生

據(jù)統(tǒng)計(jì)，99%的大咖都關(guān)注了這個(gè)公眾號(hào)

3個(gè)最常見案例詳解DBA日常維護(hù)