Hi there 👋

TL;DR Zabbixは6.0よりhistoryテーブルに主キーを使うようになりました。server,frontendのパフォーマンス向上とテーブルサイズ削減が見込めるようです。 https://www.zabbix.com/whats_new_6_0#performance_improvements 公式のDockerコンテナを運用している場合、DBコンテナは別なので/usr/share/zabbix-sql-scripts/mysql/history_pk_prepare.sqlがなく、以下から取得したところ、うまくいきました。 https://git.zabbix.com/projects/ZT/repos/rsm-scripts/browse/database/mysql/history_pk_prepare.sql 経緯 Zabbixのダッシュボードのシステム情報に、「データベースのヒストリテーブルが主キーを使用: いいえ」と表示されていることに気づきました。 調べたところ、Zabbix 6.0よりhistoryテーブルの主キーの使用に対応しているとのことでした。 https://www.zabbix.com/whats_new_6_0#performance_improvements 新規に6.0以降をインストールすれば自動で主キーが設定されるが、以前のバージョンのアップグレードの場合は手動で対応する必要があるようです。 https://www.zabbix.com/documentation/6.0/en/manual/appendix/install/db_primary_keys 弊社の環境は公式のDockerコンテナで運用してて、DBはMariaDBの公式Dockerコンテナを使用しています。「MySQL 8.0+ with mysqlsh」の手順に従って進めたところ、途中で指定されている「/usr/share/zabbix-sql-scripts/mysql/history_pk_prepare.sql」が見つかりません。 この手順は1つのサーバーにweb,server,DBをインストールする想定と思われます。公式のDockerコンテナのweb,serverをマウントしてファイル名で検索しても見つからず。 単体のZabbixサーバを構築してファイルを取り出すのも面倒だったのでいろいろ検索し、公式のリポジトリと思われる以下よりダウンロードして流し込んだところ、うまくいきました。 https://git.zabbix.com/projects/ZT/repos/rsm-scripts/browse/database/mysql/history_pk_prepare.sql

TL;DR 2023年5月2日15:00現在、Office 365の最新のExcelで半角カナのファイル名をつけ、OneDrive同期対象のフォルダで開くと毎回保護ビューになる不具合があるようです。 やはりファイル名に半角カナは避けたほうが良いのかもしれません… 経緯 利用者より、自分の場合だけExcelファイルを開くと毎回保護ビューになるとのこと。試してみると、ファイルサーバ上で開く際には初回に保護ビューとなり、「編集を有効にする」をクリックすると以降は保護ビューにはならない。が、どうもインターネットからダウンロードしたファイルではないっぽいのが気になる。なぜ保護ビューに? このファイルを、OneDriveで同期しているデスクトップで開くと、初回だけでなく、毎回保護ビューになる。「編集を有効にする」をクリックしても。 7-zipがMark-of-the-Webに対応したニュースは知っていたので、これが原因だろうとあたりをつけ、再現を試みるもどうにもダメ。Mark-of-the-Webの場合はエクスプローラーでファイルのプロパティに「Security」の項目が追加されチェックボックスが表示されるはずが、表示されない… https://www.bleepingcomputer.com/news/microsoft/7-zip-now-supports-windows-mark-of-the-web-security-feature/ Excelにて保護ビューのチェックボックスのうち、「インターネットから取得したファイルに対して、保護ビューを有効にする」のチェックをしたときのみ発生するので、Mark-of-the-Webと絡んでいそうなものなのだが、上記の通りファイルのプロパティには該当の項目が表示されない。 まさかとは思ったが、念のためと思い、ファイル名に含まれている半角カナを削除したところ問題が解消…マジか… 検証したところ、半角カナがファイル名に含まれると発生する、発生するのはExcelのみ、かつ2023/5/2 15:00時点で最新の 2304(build 16327.20214)で発生することまで突き止められた。(たまたま社内にあった、古いバージョンのExcelでは発生しなかった) 同様の症状がWebでは見つからなかったので、現時点で未解決の問題と判断。利用者には半角カナを全角カナに変えることでの暫定対応を指示。Win+FでFeedback Hubにて報告した。 1日つぶれてしまった…

TL;DR SQLは明らかにあっているのに動作が遅い、与えるパラメータによって変わるといった状況ではEXPLAINで実行計画を確認しましょう 意図しない駆動順になっていることがあります 経緯 仕事での話のため詳細なSQLの内容はかけないが、MariaDB(10.6.12)でざっくりと以下のようなSQLで特定の伝票番号を指定した場合に応答が遅くてタイムアウトする事象が発生ました。 SELECT ... FROM ( ( A INNER JOIN B ON B.PRODUCT_CD = A.PRODUCT_CD ) LEFT OUTER JOIN C ON C.CUSTOMER_CD = A.CUSTOMER_CD C.PRODUCT_CD = A.PRODUCT_CD AND C.SIZE = A.SIZE ) LEFT OUTER JOIN C AS D ON D.CUSTOMER_CD = A.CUSTOMER_CD D.PRODUCT_CD = A.PRODUCT_CD AND D.SIZE = 0 WHERE A.SLIP_NO = 123456789 本当はもっと多数のテーブルをJOINしていましたが、最小限の要素だけ引っ張ってきてます。 それぞれの結合条件は主キーを使用しています。 で、WHERE句に指定した伝票番号が特定の番号の場合に、応答が返ってこずにタイムアウトになる事象が発生しました。ほかの伝票番号を指定するとすぐ返ってくるので、SQLに文法エラーはないです。 最後のC AS Dの外部結合を外すとすぐ帰ってくるのですが、そもそもこのテーブルの結合条件にマッチするデータがないので、この伝票番号の場合にデータが多くなる、というわけでもないです。 今までこの手の問題に当たったことがなかったので使わずに済んでいた、これまで避けていたEXPLAIN文を使って実行計画を見てみました。 すると、駆動表が以下の順番になっていました。 A(PK) C(PK) D(PK) B(Null) カッコ内はキーです。A,C,Dは主キーで結合できていますが、BはNULLとなってしまっていました。 ここからは推測になりますが、テーブルB,C,DのいずれもテーブルAから結合できるので、統計データの不足なども絡んだ結果、上記のような結合順になったのではないかと考えています。...

TL;DR ChromebookのChrostini環境でVSCodeが安定して使えます。~~ただし、ASUS CM5500ではTerminalが正常に動作しません。~~2023.3.27 ASUS CM5500でも正常に動作しています 経緯 以前の記事で、ChromebookでChrostini上のVSCodeを直接使うとIME(Chrostini(Debian)にインストールしたfcitx)が不安定なため、VSCode Server経由での利用が良いと記事にしていました。ですが、やっぱり毎回起動するのは面倒です。Windowsにリモート接続してVSCode使って回避していました。 最近、以下の記事を見つけ、再度トライしました。 ChromeOS IME on Crostini 上記URLに従ってcrostini-ime-supportを有効にし、Linux環境を再作成してVSCodeをインストールしたところ、普通にChromeOSのIMEが使えました!!! fcitxのインストール等の面倒な手順が必要なくなりました!! ~~ですが、なぜかASUS CM5500だと、VSCode内のTerminalで文字を入力すると2重で入力されてしまいます。「a」と入力すると、「aa」と出るのです。出たあとは1文字ずつ消せるのですが。VSCodeのTerminalのEcho設定あたりを見て色々やってみましたが、だめでした。 ~~ 不思議なことに、もう1つChromebookとして持っているASUS CM3000では問題ありませんでした。CM5500はx64系、CM3000はARM64系なのでインストールされるパッケージが違うので、そのあたりが原因かもしれません。まぁ、TerminalはChromeOS標準のものを使えば良いので、以前よりは使えると思っています。 2023.3.27 ASUS CM5500 でも正常に動作しています。OS更新で対応されたのかもしれません。

TL;DR Excelの容量肥大化では、以下の順に切り分けましょう 見た目で明らかにオブジェクトが詰め込まれていないか Ctrl+Endで、想定以上に広い範囲が指定されていないか [ホーム]-[選択]-[オブジェクトの選択と表示]で、想定以上のオブジェクトが表示されないか ちょっとしたプログラムをぱっと作るのにChatGPTは便利 経緯 あるExcelファイルが開くと動作が遅いのでなんとかならないかと問い合わせがありました。とりあえずファイル送ってもらい、調べました。 １ファイルで容量が3MBを超えており、かなり大きいです。数式が重いか、データが重いかで原因を考えていましたが、少なくとも後者は原因になりそうです。 シート数は2つ。行は1000近くまで行っているので小さくはないがそれほどでもない感じ。中にあるのは工程表で、罫線の表に線オブジェクトが多数という感じでむちゃくちゃ多いというほどでもない感じ。 この手の肥大化でよくあるのは、利用者が気づかないうちにデータが入力されているセルの範囲が広がってしまっているケース。この場合はスクロールバーがパット見の工程表の範囲よりも広く設定されいるかどうかでわかりますが、どうもそうではなさそうでしｇた。 一方のシートが見た目上データが多く、こちらのシートが原因かなと思い、少しずつ行を削除して切り分けていこうと考えました。が、とにかく動作が重い。別の画面にフォーカスを移して戻ってくるだけでマウスがくるくる回ります… 上下にスクロールするのもしんどい感じ。 なんとか頑張って、複数ある工程表のうち、最初のものだけ残して他を削除しましたが、容量は大きいまま。で、この表を削除してもまだ容量は大きいままでした。オブジェクトの範囲選択で怪しそうな場所を選択しても、それらしいオブジェクトは無し。 そこで改めて[ホーム]-[選択]-[オブジェクトの選択と表示]を見ようとしたところ、表示までに5-10分かかり、大量のテキストボックスが表示されました、これだ… 通常であればここで1つを選択した状態でCtrl+Aですべての図形を選択できるようなのですが、重すぎていつまで立っても選択が終わりません… 色々試行錯誤したのですが、VBAでテキストボックスを削除してしまうのが手っ取り早そうだと考えました。こういったときに使ってみようと思ったのがChatGPT。Bingで使えるようになっているので、すべてのテキストボックスのオブジェクトを削除するVBAを聞いて返ってきた内容を微調整したのが以下 Sub DeleteTextBoxes() Dim ws As Worksheet Dim shp As Shape Dim n As Long Application.ScreenUpdating = False Application.Calculation = xlCalculationManual For Each ws In ThisWorkbook.Worksheets For Each shp In ws.Shapes Debug.Print "[" &ws.Name & "シートの処理を開始" & "]" If shp.Type = msoTextBox Then shp.Delete n = n + 1 Debug.Print n & "個目のテキストボックスを削除しました" Else Debug....