2. 程式人生 > >記錄一次資料量巨大的表索引損壞處理

記錄一次資料量巨大的表索引損壞處理

阿新 • • 發佈：2019-01-09
簡介：索引損壞的表XSDTM129.RT是個歷史資料表，該表資料是在實時插入的，所以表內資料量巨大，多達6億多條，而由於索引損壞，無法先進行資料的刪除，而傳統的刪索引—重建索引的時間消耗非常大，所以考慮能否用重建RT表來代替原表，並把需要所需資料匯入新RT表，刪除舊錶的方式來提高索引損壞修復的效率。
注：由於此次操作的表資料是實時插入的，而此法在執行過程中需要將資料庫設為單使用者模式，所以在執行換表的那段時間內的資料會存在丟失的情況，所以採用此法時要慎重！！！
（該方案在生產伺服器已經實施，保留資料1500000條，語句執行3分鐘，後續等採集程式採數到正常資料存入資料庫大約幾分鐘~） 具體方案：把XSDTM129.RT表重新命名為XSDTM129.MT---新建XSDTM129.RT表(注意：同一架構下不能有同名索引及主鍵)---將需要的資料匯入到新的RT表。 為測試方案是否可行，先在測試伺服器上做如下實驗。 環境：測試伺服器上一命名例項，XSDTM129.RT表，資料量約為3億。 我寫了一個萌萌噠的小儲存過程用於測試更換表名對儲存過程往表查資料的影響，並手動向XSDTM129.RT表插入資料。

然後將XSDTM129.RT更名為XSDTM129.MT。 EXECsp_rename'XSDTM129.RT','MT' 建立RT表
再次手動執行往RT插資料的儲存過程，為保證正確性，手動插入了兩次。並選出結果。
由上圖可以看出，資料全部插入了新的RT表。 同理測試了檢視，選出的是新RT表裡的資料。 由此基本可以判斷更換表名對儲存過程和檢視的影響是沒有的! 接下來就是如何把需要的資料匯入到新表，由於RT表資料是每隔幾秒都會有插入，哪怕三天的資料量都達到一百多萬，所以考慮插入的時候，查詢的判斷條件用record_id（該表在record_id列上建有索引）。 
INSERT INTO xsdtm129.rt
       (ts_id ,
          class_num ,
          ord_class ,
          team_set ,
          class_start_server ,
          class_end_server ,
          record_timestamp ,
          runtime_s ,
          article_id ,
          current_class_output ,
          total_output ,
          total_output_c ,
          a_output ,
          b_output ,
          c_output ,
          d_output ,
          a_total ,
          b_total ,
          c_total ,
d_total ,current_length ,fixed_length ,rolla_v ,spindle_v ,twist_ratio ,class_num_plc ,Dev_GUID ,i_signal ,q_signal ,sec_A_length ,sec_B_length ,sec_C_length ,sec_D_length ,sec_A_change_amount ,sec_B_change_amount ,sec_C_change_amount ,sec_D_change_amount ,run_efc ,device_state ,Article_GUID ,a_total_calc ,b_total_calc ,c_total_calc ,d_total_calc , row_interval ,statecode ,machineNo)
   SELECT ts_id ,
          class_num ,
          ord_class ,
          team_set ,
          class_start_server ,
          class_end_server ,
          record_timestamp ,
          runtime_s ,
          article_id ,
          current_class_output ,
          total_output ,
          total_output_c ,
          a_output ,
          b_output ,
          c_output ,
          d_output ,
          a_total ,
          b_total ,
          c_total ,
d_total ,current_length ,fixed_length ,rolla_v ,spindle_v ,twist_ratio ,class_num_plc ,Dev_GUID ,i_signal ,q_signal ,sec_A_length ,sec_B_length ,sec_C_length ,sec_D_length ,sec_A_change_amount ,sec_B_change_amount ,sec_C_change_amount ,sec_D_change_amount ,run_efc ,device_state ,Article_GUID ,a_total_calc ,b_total_calc ,c_total_calc ,d_total_calc , row_interval ,statecode ,machineNo
  FROM XSDTM129.mt WHERE record_id>614217880
Attention！！ 為保證過程實施的穩定性，最好用以下指令碼殺掉程序、把資料庫切換為單使用者模式，可以先把採集程式關了，等全部執行完後再次開啟。如果整體執行報錯的話，可以手動的一段一段的執行。 詳情請見指令碼！！ 
--殺掉程序
USE master
GO
DECLARE @kill varchar(max) = '';
SELECT @kill = @kill + 'KILL ' + CONVERT(varchar(10), spid) + '; '
FROM master..sysprocesses
WHERE spid > 50 AND dbid = DB_ID('A') --A為資料庫名
PRINT @kill
EXEC(@kill);
 
GO
SET DEADLOCK_PRIORITY HIGH

USE A   --A為資料庫名
GO
--更換表名
ALTER DATABASE A SET  SINGLE_USER;
GO
--更換表名
EXEC sp_rename 'XSDTM129.RT', 'MT';
GO
 
--新建XSDTM.RT表代替原表
CREATE TABLE [XSDTM129].[RT]
    (
      [record_id] [BIGINT] IDENTITY(1, 1) NOT NULL ,
      [ts_id] [INT] NULL ,
      [class_num] [TINYINT] NULL ,
      [ord_class] [NCHAR](1) NULL ,
      [team_set] [NCHAR](1) NULL ,
      [class_start_server] [DATETIME] NULL ,
      [class_end_server] [DATETIME] NULL ,
      [record_timestamp] [DATETIME] NOT NULL ,
      [runtime_s] [INT] NULL ,
      [article_id] [INT] NULL ,
      [current_class_output] [INT] NULL ,
      [total_output] [INT] NULL ,
      [total_output_c] [BIGINT] NULL ,
      [a_output] [INT] NULL ,
      [b_output] [INT] NULL ,
      [c_output] [INT] NULL ,
      [d_output] [INT] NULL ,
      [a_total] [INT] NULL ,
      [b_total] [INT] NULL ,
      [c_total] [INT] NULL ,
      [d_total] [INT] NULL ,
      [current_length] [INT] NULL ,
      [fixed_length] [INT] NULL ,
      [rolla_v] [DECIMAL](9, 2) NULL ,
      [spindle_v] [INT] NULL ,
      [twist_ratio] [INT] NULL ,
      [class_num_plc] [INT] NULL ,
      [Dev_GUID] [UNIQUEIDENTIFIER] NOT NULL ,
      [i_signal] [INT] NULL ,
      [q_signal] [INT] NULL ,
      [sec_A_length] [INT] NULL ,
      [sec_B_length] [INT] NULL ,
      [sec_C_length] [INT] NULL ,
      [sec_D_length] [INT] NULL ,
      [sec_A_change_amount] [INT] NULL ,
      [sec_B_change_amount] [INT] NULL ,
      [sec_C_change_amount] [INT] NULL ,
      [sec_D_change_amount] [INT] NULL ,
      [run_efc] [DECIMAL](5, 2) NULL ,
      [device_state] [INT] NULL ,
      [Article_GUID] [UNIQUEIDENTIFIER] NULL ,
      [a_total_calc] [INT] NULL ,
      [b_total_calc] [INT] NULL ,
      [c_total_calc] [INT] NULL ,
      [d_total_calc] [INT] NULL ,
      [row_interval] [INT] NULL ,
      [statecode] [TINYINT] NULL ,
      [machineNo] [INT] NULL ,
      [article_name] [NVARCHAR](32) NULL ,
      CONSTRAINT [PK_RT_RecordID] PRIMARY KEY NONCLUSTERED ( [record_id] ASC )
        WITH ( PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF,
               IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON,
               ALLOW_PAGE_LOCKS = ON ) ON [PRIMARY]
    )
ON  [PRIMARY];
 
GO
 
ALTER TABLE [XSDTM129].[RT] ADD  CONSTRAINT [DF_RT_record_timestamp]  DEFAULT (GETDATE()) FOR [record_timestamp];
GO
 
ALTER TABLE [XSDTM129].[RT] ADD  CONSTRAINT [DF_RT_runtime_s]  DEFAULT ((0)) FOR [runtime_s];
GO
 
 
--為表建索引，在以下空白處可加上新增索引的程式碼






SET IDENTITY_INSERT XSDTM129.RT ON;   
GO 
 
BEGIN TRAN;
 
INSERT  INTO XSDTM129.RT
        ( record_id ,
          ts_id ,
          class_num ,
          ord_class ,
          team_set ,
          class_start_server ,
          class_end_server ,
          record_timestamp ,
          runtime_s ,
          article_id ,
          current_class_output ,
          total_output ,
          total_output_c ,
          a_output ,
          b_output ,
          c_output ,
          d_output ,
          a_total ,
          b_total ,
          c_total ,
          d_total ,
          current_length ,
          fixed_length ,
          rolla_v ,
          spindle_v ,
          twist_ratio ,
          class_num_plc ,
          Dev_GUID ,
          i_signal ,
          q_signal ,
          sec_A_length ,
          sec_B_length ,
          sec_C_length ,
          sec_D_length ,
          sec_A_change_amount ,
          sec_B_change_amount ,
          sec_C_change_amount ,
          sec_D_change_amount ,
          run_efc ,
          device_state ,
          Article_GUID ,
          a_total_calc ,
          b_total_calc ,
          c_total_calc ,
          d_total_calc ,
          row_interval ,
          statecode ,
          machineNo ,
          article_name
        )
        SELECT  record_id ,
                ts_id ,
                class_num ,
                ord_class ,
                team_set ,
                class_start_server ,
                class_end_server ,
                record_timestamp ,
                runtime_s ,
                article_id ,
                current_class_output ,
                total_output ,
                total_output_c ,
                a_output ,
                b_output ,
                c_output ,
                d_output ,
                a_total ,
                b_total ,
                c_total ,
                d_total ,
                current_length ,
                fixed_length ,
                rolla_v ,
                spindle_v ,
                twist_ratio ,
                class_num_plc ,
                Dev_GUID ,
                i_signal ,
                q_signal ,
                sec_A_length ,
                sec_B_length ,
                sec_C_length ,
                sec_D_length ,
                sec_A_change_amount ,
                sec_B_change_amount ,
                sec_C_change_amount ,
                sec_D_change_amount ,
                run_efc ,
                device_state ,
                Article_GUID ,
                a_total_calc ,
                b_total_calc ,
                c_total_calc ,
                d_total_calc ,
                row_interval ,
                statecode ,
                machineNo ,
                article_name
        FROM    XSDTM129.mt(NOLOCK)
   WHERE   record_id > 1799926237 --order by record_id;--我想著用先查出一個record_id值，然後查詢條件用這個會快些，因為該值是索引列。
 
COMMIT TRAN;
 
SET IDENTITY_INSERT XSDTM129.RT OFF; 
GO

ALTER database A SET MULTI_USER --切換回多使用者模式
GO





相關推薦

記錄一次資料量巨大的表索引損壞處理

簡介：索引損壞的表XSDTM129.RT是個歷史資料表，該表資料是在實時插入的，所以表內資料量巨大，多達6億多條，而由於索引損壞，無法先進行資料的刪除，而傳統的刪索引—重建索引的時間消耗非常大，所以考慮能否用重建RT表來代替原表，並把需要所需資料匯入新RT表，刪除舊錶的方式

記錄一次數據庫某表未創建索引造成的問題

如果 問題 大量 alt 多表 ima count 重建 sql 現象描述： 昨天鷹網監控告知廊坊某臺物理機CPU使用率接近100%，查看得知每顆邏輯CPU的使用率都接近了100%，但該數據庫機器是測試機器，按理說不會造成此問題。截圖如下： 處理步驟： 1. 查看消耗大

記錄一次經歷的數據庫從單庫到分庫分表的過程

人力 per 靠譜 img center 沒有 tdd 推出 數據 前言 目前所在的的項目組，由於項目正在處於一個業務爆發期，每天數據的增長量已經給我們數據庫乃至系統造成了很多不確定的因數，前期依靠優化業務和SQL等方式暫時還能夠支撐住。但是最近發現某些表數據達到50

ORACLE sql調優之記錄一次trim函數引發的大表全表掃描

oracle trim 全表掃描 sql 調優 2017年8月14日，一地市oracle相關的調度程序ETL抽取速度奇慢，sql語句每次執行平均時間要9秒左右，如果所示：該調度過程涉及的sql語句如下：select count(*) from (SELECT rtrim(

記錄一次mysql有索引但是沒有用到的經歷

前提：公司測試人員需要連線資料庫取資料，但是併發量高的時候會報等待獲取連線超時，所以經理讓我幫忙處理下，首先想到增大超時等待時間，改為60秒，300百左右併發是沒有問題的，但是提高到500以上時又報辣個錯誤，就在考慮應該優化下查詢sql，增加索引使查詢時間縮短來減少等待時間。 兩個sql很簡

記錄一次hive大表脫敏和改造成parquet儲存動態分割槽的操作

#!/bin/bash tablename=frontlog startDate=2018-01-01 #endDate=`date -d "0 day ago" +%Y-%m-%d` DATE=`date +%Y-%m-%d` endDate=2018-08-30 #給新表增加分割槽 w

記錄一次使用form表單完成圖片上傳功能（相容ie9）

1.前臺頁面 <div class="dform_con" style="position: relative;" id="uploadform"> <iframe id="file_upload_return" style="d

使用JDBC一次插入多個表、多條記錄

程式碼如下： public static void insertBatch() { int count[]; int count1[]; Boolean isinsert = false; Connection con = null; PreparedS

SqlServer快速獲得表總記錄數(大資料量)

--第1種 執行全表掃描才能獲得行數 SELECT count(*) FROM BUS_tb_UserGradePrice --第2種 執行掃描全表id不為空的,獲得行數 select count(userid) from BUS_tb_UserGradePrice wh

記錄一次索引優化經歷

表結構如下： 主要用到FIS_BACKUP、FID和FSTATUS幾個欄位做查詢。 索引如下： 整張表，前半部分資料FIS_BACKUP都是1，後半部分資料FIS_BACKUP都是0，共2000w多條資料 查詢語句如下： SELEC

在JDBC一次插入多個表、多條記錄

{   con = getCon();   con.setAutoCommit(false);                                   // 需要用到事務，不能讓他自動提交，需要手動提交   pst = con.prepareStatement(INSERT_SQL);      

記錄一次經歷的資料庫從單庫到分庫分表的過程

前言   目前所在的的專案組，由於專案正在處於一個業務爆發期，每天資料的增長量已經給我們資料庫乃至系統造成了很多不確定的因數，前期依靠優化業務和SQL等方式暫時還能夠支撐住。但是最近發現某些表資料達到500W+以後查詢統計效能嚴重下降，高峰時段出現了很多SQL阻塞的情況例如:

記錄一次MySQL兩千萬資料的大表優化解決過程，提供三種解決方案

問題概述 使用阿里雲rds for MySQL資料庫（就是MySQL5.6版本

記錄一次“記錄超長”

har 語句 類型 執行 如果 可能 事情 縮小 百度 Jdbc報錯“記錄超長”，百度一下推測可能是因為SQL過長導致；但是後來經過老杜指點，發現原來是因為字段（varchar 8000）超長導致； 解決問題的套路： 1. 首先在Sql的客戶端上執行代碼；如果不錯，說明還是

[邏輯漏洞]記錄一次挖洞

9.png 列表 一次 查詢 urn 找到 ima sting .com 陽光明媚的早上，turn on the PC and 隨意地瀏覽著以往漏洞列表，希望在裏面找到一些遺忘的痕跡。 果然，我發現一個被忽略的漏洞，一個暴露在外網的的一個接口，可以查詢該企業網站是否註冊了的

簡單記錄一次REDO文件損壞報錯 ORA-00333重做日誌讀取塊出錯

clas 後者 利用 實例恢復 poi cancel true cover html 一.故障描寫敘述 首先是實例恢復須要用到的REDO文件損壞 二、解決方法 1.對於非當前REDO或者當前REDO可是無活動事務使用下面CLEAR命令： 用CLEAR命令重建該日誌

記錄一次配置http跳轉https的過程

http https 網站跳轉 公司最近搞了一個數據運營平臺，這個平臺會以web界面的形式把各個數據展示出來，這個項目是我們一個經理的重點關照項目。把平臺模塊部署完畢並且啟動之後，又把這個平臺服務器的外網IP綁定到alkaid.lechange.com這個域名上，在瀏覽器裏輸入https://al

記錄一次concurrent mode failure問題排查過程以及解決思路

tails only cnblogs 策略 executor red execute incr run 背景：後臺定時任務腳本每天淩晨5點30會執行一個批量掃庫做業務的邏輯。 gc錯誤日誌： 2017-07-05T05:30:54.408+0800: 518534

記錄一次MySQL進程崩潰，無法重啟故障排查

not pool function 解決 variables fail data class 緩沖 最近程序在跑著沒幾天，突然訪問不了，查看應用進程都還在。只有數據庫的進程down掉了。於是找到日誌文件看到如下錯誤 2017-07-24 01:58:53 19934 [N

記錄一次處理https監聽不正確的過程

負載均衡 https 502 nginx 金山雲 今天開發反饋在測試金山雲設備的時候遇到了這樣的一個現象：wget https://funchlscdn.lechange.cn/LCLR/2K02135PAK01979/0/0/20170726085033/dev_201707260850