access資料庫mdb檔案,資料刪掉,需要進行壓縮處理
公司考勤系統使用access資料檔案(mdb),幾十年來資料已經達到約400MB,經過SQL進行刪除不要的資料後,實體檔案居然還是一樣大都沒變,後來發現可以使用microsoft access 2016打開該檔案,進行壓縮處裡,就可以解決了。
公司考勤系統使用access資料檔案(mdb),幾十年來資料已經達到約400MB,經過SQL進行刪除不要的資料後,實體檔案居然還是一樣大都沒變,後來發現可以使用microsoft access 2016打開該檔案,進行壓縮處裡,就可以解決了。
年紀一大把了,還在搞Acess,慘
你可以存取的(u can access),到此下載
解開後,除了本體ucanaccess-xxx.jar外,在lib目錄下的jar檔也需要。
其中存取access的關鍵jackcess-xxx.jar (目前最新版4.0.6),可另外下載取代ucanaccess內建的3.0.1版本
JDBC Connection String
jdbc:ucanaccess://c:/xxx.mdb;memory=false
以前安裝wordpress容器的時候,可以利用–link參數,綁定以有的資料庫容器(mariadb),讓資料庫容器主機名稱變身成「mysql」,就可以不用安裝一大堆資料庫容器惹。(wordpress容器只認mysql這個主機(host)名稱,所以我們不得已而這樣做)
我先前的文章舊版(Docker)(WordPress)如何使用docker安裝wordpress (帳密皆為guest),也是建議醬做;可是好景不常,docker終於受不了了,新版廢棄–link參數,podman也跟進。
當然會這樣做一定是為了區分子網路,方便管理使用,我也「被」樂見其成,因此我安裝wordpress也必須避開–link參數。
該如何做呢? 以podman為例子,首先我們要想一個很威的網路橋接名稱mynet(可自訂):
podman create network mynet
然後將以前就有的資料庫容器,加到這個網路橋接器上:
podman network connect mynet mariadb-container
接下來賦予資料庫容器別名,讓資料庫變身成wordpress心目中的mysql:
podman network connect --alias mysql mynet mariadb-container
這樣一來安裝wordpress就可以不用加上 –link 這個參數,且wordpress容器也能自動認得資料庫容器了。
要得知wordpress正確版本,可從資料庫(mariadb)著手,輸入以下SQL語法:
SELECT * FROM `wp_options` where option_name = 'db_version';
得到option_value之後,再比對官方網站公告資訊 https://codex.wordpress.org/WordPress_Versions,就可以得到正確版本啦。
wordpress 4、5、6這三個大版本,密碼皆使用hash方式加密,若我們忘記管理者帳號密碼,且無法從資料庫看到明碼密碼;此時如果你有資料庫(mariadb)管理者權限那就好辦了,可以先以資料庫的管理者帳號登入,該帳號為整個wordpress資料庫最高權限,而非wordpress管理者帳號;登入後,找出wordpress管理者帳號名稱,然後進行hash密碼加密。
網路上有提供該加密的網站,請google WordPress Password Hash Generator,就可以輕易產出密碼,甚至有些網站還產出SQL語法,修改一下語法內之管理者名稱即可使用,非常方便。
--
--
根據官方文件 , 吉茶可以綁定各式各樣的登入認證, 也包含微軟網域主控認證, 但並沒有解釋太多, 因我有需求要綁定Micro$oft 網域主控站 , 因此記錄一下注意事項.
# (memberOf=xxx) xxx 為群組名稱 CN=GitGroup,OU=groups,DC=test,DC=com
# 意思就是帳號需隸屬於GitGroup這個群組, 若不需要可以拿掉.
# (mail=*) 代表帳號email屬性必須有值才能用, 若不需要也可以拿掉
(&(objectCategory=Person)(memberOf=CN=GitGroup,OU=groups,DC=test,DC=com)(sAMAccountName=%s)(mail=*)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))
MariaDB [gitea]> delete from email_address where id<>1;
Query OK, 2 rows affected (0.00 sec)
MariaDB [gitea]> delete from user where id<>1;
Query OK, 2 rows affected (0.00 sec)
oracle我很不熟, 但在公司使用exp指令備份oracle 11g資料時, 遇到以下錯誤訊息
EXP-00056: ORACLE error 1555 encountered
ORA-01555: snapshot too old: rollback segment number with name "" too small
ORA-22924: snapshot too old
爬了文, 解法有三, 我從最簡單的解法開始, 第一種,第二種都失敗, 直到第三種方式才成功.
我建議從第三種方式開始解,該方法不需修改系統設定, 影響較小.
SQL> show parameter undo;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
undo_management string AUTO
undo_retention integer 21600
undo_tablespace string UNDOTBS1
SQL> ALTER SYSTEM SET UNDO_RETENTION = 43200;
SQL>
System altered.
SQL>
# 新增undo tablespace
create undo tablespace UNDOTBS2 datafile '/.../oradata/undotbs02.dbf' size 30000M autoextend on next 100m maxsize unlimited;
#生效
alter system set undo_tablespace = UNDOTBS2 scope=both;
#查看狀態
select tablespace_name, status, count(*) from dba_rollback_segs group by tablespace_name, status;
select status,segment_name from dba_rollback_segs where status not in ('OFFLINE') and tablespace_name='UNDOTBS1';
select tablespace_name, status, count(*) from dba_rollback_segs group by tablespace_name, status;
#確認舊的已是offline , 就可以刪掉舊的
Drop tablespace UNDOTBS1 including contents and datafiles;
#再次查看是否已變成新的undo tablespace
show parameter undo
select tablespace_name tablespace, status, sum(bytes)/1024/1024 sum_in_mb, count(*) counts
from dba_undo_extents
group by tablespace_name, status order by 1,2;
# 先建立一個資料表, 用來儲存有問題的資料ID(ROWID)
SQL> CREATE TABLE CORRUPTED_ROWS (CORRUPTED_ROWID ROWID, ERROR_NUMBER NUMBER);
Table created.
接下來將有錯誤資料表table schema , 欄位類型為clob , blob 欄位列出來, 問題一定在這幾個欄位之中
# 以下紅色部分請改為有問題資料表與欄位名稱, 若沒有出現錯誤, 就換下一個欄位(fieldname)試試看
SET TIMING ON
DECLARE
ERROR_1578 EXCEPTION;
ERROR_1555 EXCEPTION;
ERROR_22922 EXCEPTION;
PRAGMA EXCEPTION_INIT(ERROR_1578, -1578);
PRAGMA EXCEPTION_INIT(ERROR_1555, -1555);
PRAGMA EXCEPTION_INIT(ERROR_22922, -22922);
N NUMBER;
BEGIN
FOR ROW IN (SELECT ROWID, fieldname FROM user.table)
LOOP
BEGIN
N:=DBMS_LOB.INSTR(ROW.fieldname, HEXTORAW('889911'));
EXCEPTION
WHEN ERROR_1578 THEN
INSERT INTO CORRUPTED_ROWS VALUES (ROW.ROWID, 1578);
COMMIT;
WHEN ERROR_1555 THEN
INSERT INTO CORRUPTED_ROWS VALUES (ROW.ROWID, 1555);
COMMIT;
WHEN ERROR_22922 THEN
INSERT INTO CORRUPTED_ROWS VALUES (ROW.ROWID, 22922);
COMMIT;
END;
END LOOP;
END;
/
接下來查詢是否真有問題資料
SELECT * FROM CORRUPTED_ROWS;
#執行以下這行指令應該要出錯
SELECT fieldname FROM user.table WHERE ROWID IN (SELECT CORRUPTED_ROWID FROM CORRUPTED_ROWS);
清空有問題的資料欄位
#若欄位型態是clob就用empty_clob(), 若為blob,就改成empty_blob(), 有幾個欄位出問題就清空幾個
update xxx.table set fieldname = empty_clob()where ROWID IN (SELECT CORRUPTED_ROWID FROM CORRUPTED_ROWS);
若不敢清空, 可以跳過有問題的資料備份
exp system@yourinstance BUFFER=81920 file=/tmp/backup.dmp tables=user.table QUERY=\"WHERE rowid NOT IN \(SELECT CORRUPTED_ROWID FROM CORRUPTED_ROWS\)\"
參考資料
好久沒安裝mysql了, 我之前都是docker 無腦安裝, 並不需要了解太多, 但是因為我先前安裝的 piwigo docker版本升級不利, 想說手動安裝piwigo看看, 當然第一步就是安裝mariadb囉.
這次RL9預設的mariadb是10.5, 安裝相當簡單
dnf install mariadb-server
接下來就是改密碼,預設console直接可以使用root登入
mysql -p -uroot
跟之前不一樣,我還停留mysql舊時代改密碼方式 update user set password=password(‘you password’) where user=’root’
居然失敗了, 爬了文, 反正就是跟上主流,改用oracle類似的變更方式了
alter user root@localhost identified by 'your password';
flush privileges;
很多相關設定可參考原廠文件
一直以來QNap 純粹用來當作儲存設備, 花俏功能我都直接關掉, 只開放iSCSI , NFS 與CIFS , 而且限定內部ip才能連線(Qlocker遠離我).
但是最近公司停電,開機後, 我發現有一個插槽壞了, 換硬碟也顯示無硬碟狀態, 有夠麻煩的, 手忙腳亂了一番, 不小心造成QNap不正常關機(不要笑我啊).
悲劇來了, windows 的主要網域主控站, 與Sharepoint Server直接GG 慘, 而Linux也有狀況例如這個網站也GG, 好險Linux自帶工具, 告訴我可以執行xfs修復, 至少可以開機成功, windows就不多說了, 直接拿備份重建, 但是一波好幾折, 辛酸阿.
先說 linux 的docker server中 mariadb server container也再起不能了, 哭,
於是我另開一個可啟動的 mariadb container , 把有問題的volume中的額外table放到乾淨的mysql目錄中, 想像這樣或許可以救起來其他資料庫, 一開始啟動成功, show database, show tables也看到, 真是高興, 但是要select tables時候, 出現錯誤訊息
mysql error unknown table engine
又哭… 找了好久終於找到可以在my.cnf中加上以下參數, 但是我的container沒有mapping到/etc中的my.cnf , 於是又搞了一次, 才可以進行修復.
innodb_force_recovery = 1 or innodb_force_recovery = 4
終於完成了, 我的網站修復完成.
— added 2021/5/10 —-
後來發現以上innodb_force_recovery參數只能暫時使用, 需要趕緊使用mysqldump把資料備份下來,
mysqldump --user=root -h 127.0.0.1 --password --lock-tables --databases 資料庫名稱 > xxx.sql 或 mysqldump --user=root -h 127.0.0.1 --password --databases 資料庫名稱 > xxx.sql
然後再重新跑一個全新 server 把相關資料倒回去, 才能真正高枕無憂