java jdbc 連到 M$ access “ucanaccess”

年紀一大把了,還在搞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避開docker早期–link參數,該如何連到mariadb資料庫

以前安裝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容器也能自動認得資料庫容器了。

先前的文章新版(Docker)(WordPress)如何使用docker安裝wordpress

如何得知自架wordpress的正確版本

要得知wordpress正確版本,可從資料庫(mariadb)著手,輸入以下SQL語法:

SELECT * FROM `wp_options` where option_name = 'db_version';

得到option_value之後,再比對官方網站公告資訊 https://codex.wordpress.org/WordPress_Versions,就可以得到正確版本啦。

自架wordpress網站如何重設管理帳號密碼

wordpress 4、5、6這三個大版本,密碼皆使用hash方式加密,若我們忘記管理者帳號密碼,且無法從資料庫看到明碼密碼;此時如果你有資料庫(mariadb)管理者權限那就好辦了,可以先以資料庫的管理者帳號登入,該帳號為整個wordpress資料庫最高權限,而非wordpress管理者帳號;登入後,找出wordpress管理者帳號名稱,然後進行hash密碼加密。

網路上有提供該加密的網站,請google WordPress Password Hash Generator,就可以輕易產出密碼,甚至有些網站還產出SQL語法,修改一下語法內之管理者名稱即可使用,非常方便。

 --

 --

Gitea(吉茶)認證綁定微軟網域主控站

根據官方文件 , 吉茶可以綁定各式各樣的登入認證, 也包含微軟網域主控認證, 但並沒有解釋太多, 因我有需求要綁定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)))
  • 對應帳號屬性與email屬性

  • 若匯入的帳號不喜翻, 可以到資料庫刪除, 再執行作業重新匯入
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 11G 出現的ORA-01555 問題

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

爬了文, 解法有三, 我從最簡單的解法開始, 第一種,第二種都失敗, 直到第三種方式才成功.
我建議從第三種方式開始解,該方法不需修改系統設定, 影響較小.

  • 方法一
    修改 undo_retention秒數, 把時間拉大,
    **我是用備份的方式測試, 發現改了之後還是一樣出錯
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 ,
    這要小心點, 有很多眉角, 似乎牽涉到小心舊undo tablesapce 是否已呈現”OFFLINE”, 且新的undo tablespace 呈現”ONLINE’
# 新增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\)\"

參考資料

https://www.modb.pro/db/47021

RockyLinux 9 簡易安裝 mariadb

好久沒安裝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不正常關機, 造成vm開機失敗的修復小心得

一直以來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.sqlmysqldump --user=root -h 127.0.0.1 --password  --databases 資料庫名稱 > xxx.sql

然後再重新跑一個全新 server 把相關資料倒回去, 才能真正高枕無憂

1 2 3