古いOracle Databaseの稼働できる環境を調べてみたのだが、Oracle Cloudでは、Oracle DB 11g R2（Oracle Database 11.2.0.4）のサポート終了していた。
https://blogs.oracle.com/oracle4engineer/post/database-11gr2-support-end
2021年3月31日に終了なので、結構前の終了だ。まぁ、古いし、そうなるか。
カテゴリー: 技術系memo
-
Azure上でPythonを利用する場合のサポートバージョンのメモ
Pythonとしての各バージョンとサポート期限は下記。概ね5年間のサポート。ただし、リリースされてからでないと、各種フレームワークなどが追随してこない。リリースされてから、開発等を始めるとすると、利用できる期間は4年間程度。開発会社によっては、常に最新のものを追いかけず、1つ前のバージョンをつかったりする可能性もあるので、もっと短くなる可能性もある。
Pythonのリリースとサポート期限の一覧
https://devguide.python.org/versions/Azure App Serviceの場合、Python 3.11のバージョンは指定できるが、Python 3.11.xのようなパッチバージョンまでは指定できない。サポートポリシーによると、Azure側でアップデートが行われる。言語のサポートが終了してもすぐに使えなくなるわけではなく、Azureのポリシーとしては「特定の言語のコミュニティ サポートが終了しても、アプリケーションは変更することなく引き続き実行できます。」とのこと。
App Service 言語ランタイムのサポート ポリシー
https://learn.microsoft.com/ja-jp/azure/app-service/language-support-policyAzure Functionsの場合は、ランタイムバージョン毎に、利用できる言語のバージョンが決まっている。そのため、利用したい言語のバージョンに合わせて、ランタイムバージョンを選択する必要がある。そして、言語側のサポートが終了すると、Azure Functionでも、サポートが終わる。
Azure Functions でサポートされている言語
https://learn.microsoft.com/ja-jp/azure/azure-functions/supported-languagesAzure FunctionでのPythonのサポート状況と、サポート終了のお知らせ。
https://azure.microsoft.com/ja-jp/updates/azure-functions-support-for-python-36-is-ending-on-30-september-2022/ -
ウェブ版のTeamsが「Teams を読み込んでいます」で止まる
ウェブ版のTeamsで、ミーティングのURLをクリックして、ウェブ版を起動させると、高確率で「Teams を読み込んでいます」の表示（もしくは消えて白い画面）で止まってしまう。
下記のマイクロソフトのトラブルシュートも試して、Cookieを受け入れるようにしたが、状況は変わらない。
https://learn.microsoft.com/ja-jp/microsoftteams/troubleshoot/teams-sign-in/sign-in-loop
Cookieのところでないとすると、打つ手はないので、「Teams を読み込んでいます」で止まった場合には、
ブラウザでリロードして、Teamsのウェブアプリが正常に読み込まれるまで、リロードするしかなさそうだ。
あとは、マイクロソフトがエラーが減るように対応してくれるまで待つしかない。対応してくれればだが。
-
FreeBSD 13.1から13.2へのバージョンアップ
FreeBSD 13.1のサポートが終わるので、FreeBSD 13.2にバージョンアップした。コマンドは、下記で行った。
freebsd-update fetch freebsd-update install freebsd-update upgrade -r 13.2-RELEASE freebsd-update install shutdown -r now freebsd-update install pkg-static upgrade -f前のFreeBSD 12.2から13.1へ上げたときと、コマンドは一緒。今回は、すんなりとバージョンアップされた。
-
GitLab CE で小まめにアップデートし忘れて、apt updateでエラーになった。
すでに何度目かのミス。GitLab CEはアップデートのタイミングが早いので、小まめにアップデートを行っておかないと、アップグレードパスから外れて、apt updateでアップデートできなくなる。下記は、おきまりのエラー表示。
dpkg: アーカイブ /var/cache/apt/archives/gitlab-ce_16.1.2-ce.0_amd64.deb の処理 中にエラーが発生しました (--unpack): new gitlab-ce package pre-installation script subprocess returned error exit status 1 処理中にエラーが発生しました: /var/cache/apt/archives/gitlab-ce_16.1.2-ce.0_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1)今回は、GitLab-ce-15.6.0から、最新のGitLab-ce-16.1.2なので、下記のアップグレードパスを踏んでアップグレードした。
GitLab-ce-15.6.0
↓
GitLab-ce-15.11.11 ・・・15系の最終バージョン
↓
GitLab-ce-16.1.2コマンドは、次の順番で実行。これで、無事に16系の最新（作業時最新の16.1.2）にアップデートできた。
sudo apt update sudo apt upgrade gitlab-ce=15.11.11-ce.0 sudo apt upgrade gitlab-ce=16.1.2-ce.0 sudo gitlab-ctl restartGitLab CEのアップグレードパスについては、下記を参照。
https://docs.gitlab.com/ee/update/index.html#upgrading-to-a-new-major-version
-
ファームウェアバージョンにより、Smart Array P440ar Contoller で一時的にArrayが認識不能になる可能性がある。
iLO4では、ログにSmart Array P440ar Contoller のエラーが出ているが、その後のステータスは正常になっている。
HPEのサポートによると、Smart Array P440ar Contoller のファームウェアのバージョンにより、一時的に認識不能になることがあるとのこと。だが、ファームウェアのバージョンを変えたほうがよいか、という質問には十分ファームウェアバージョンは高いとのこと。
iLO4上でのヘルスチェックが正常になっているのであれば、問題ないとのこと。
どちらにしても、HPEサポートへの問い合わせは必須。
-
Veeam Backupの合成フルバックアップが便利
Veeam Backup & Replication11（以降）の合成フルバックアップの機能が便利だ。毎週、フルバックアップの作成をしなくても、バックアップされているデータから、フルバックアップに相当するファイルが作成される。フルバックアップにかかる負荷が軽減されるので、結構、便利な機能だ。
合成フルバックアップの説明については、下記のURLに載っている。
https://helpcenter.veeam.com/jp/docs/backup/vsphere/synthetic_full_backup.html?ver=110
合成フルバックアップには、次のような利点があります。
合成フルバックアップは、既にディスクに保存されているバックアップファイルから作成されるため、ネットワークリソースを使用しません。
合成フルバックアップはバックアップリポジトリに直接合成されるため、本番環境に対する負荷が軽減されます。
合成フルバックアップの設定は下記。
１．Veeam Backupのバックアップ設定のウィザードを開く
２．ウィザードを「Storage」に進める
３．「Advanced」のボタンをクリックする
４．「Create synthetic full backups periodically」オプションにチェックを入れて、OKをクリックする
５．他の設定を設定すれば終わり
できれば、フルバックアップは月で採りたいのだが、現状では曜日しか選べないので週次での取得になってしまう。
-
WSL2のUbuntuのイメージ保存場所
WSL2で、実際のデータがどこにあるのか気になって調べたので、メモ。
デフォルト設定では、ユーザアカウントの「AppData¥Local¥Packages¥」の下に、フォルダ分けされて保存されていく。WSL2の場合は、「ext4.vhdx」で保存されるのだが、WSL1でLinuxを展開して、WSL2に変換した場合は、下記のように「rootfs」フォルダの下にファイルが展開される。WSL（WSL1）の場合も同じフォルダだ。
C:\Users\%USER%\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\rootfs※ %USER% の部分は、自分のユーザ名に置き換えてアクセスする。
最初からWSL2の場合は、vhdxファイルで下記のフォルダに展開されているはず。
C:\Users\%USER%\AppData\Local\Packages\CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc\LocalState\参考： https://learn.microsoft.com/en-us/windows/wsl/disk-space
-
PowerShell ISEでps1のファイルを開くと文字化けする
Windows10のPowerShell ISEで、ps1ファイル（PowerShellのスクリプトファイル）を開くと、文字化けする。日本語のコメント部分が文字化けするので使いにくい。対処方法を調べてみたのだが。
PowerShell ISEの読み込み時のデフォルトの文字コードは、ShiftJISである。この読み込み時のデフォルトの文字コードを変更することはできない。OSの文字コードではなくて、PowerShell ISEのデフォルト設定であるため。
ps1ファイルに、BOM付でUTF-8指定されている場合には、開いても文字化けせず、UTF-8としてファイルを開いてくれる。
Windows10は、現在はメモ帳などで作成したファイルにBOMを付けていない。デフォルトはUTF-8で、BOMなしはUTF-8解釈されるし、それで保存される。
PowerShellのスクリプトファイルを作成するときは、保存するときに拡張子を .ps1 で保存するだけではなく、オプションとして、BOMで文字コードをUTF-8指定で保存する必要がある。もし、.ps1ファイルをPowerShell ISEで開くときに文字化けする場合は、一度、メモ帳などで開き、BOM付で保存しなおす必要がある。
なんと厄介な。Powershell ISE は標準でインストールされているので実行時したりするときに便利だったのだけど。
-
SQL Serverで日付をyyyy/mm/ddで表示しようとしたら関数が認識されずエラーになった
SQL Serverのバージョン違いによるTransact-SQLの差は、忘れたころに踏み抜く。SQL Server 2005で、yyyy/mm/dd形式で日付を出力しようとしたところ、下記のエラーが表示されて、実行できず。
'format' は 組み込み関数名 として認識されません。formatは、SQL Server 2016以降はつかえるようだ。対象は、SQL Server 2005なので、format関数は追加されておらず、convert関数を使って、yyyy/mm/ddの形式にする。例としては下記。
SQL Server 2005で、日付（datetime型、smalldatetime型など）を、yyyy/mm/dd の形式で表示する。
select convert(nvarchar,GetDate(),111) AS 'yyyy/mm/ddフォーマット'SQL Server 2019で、日付（datetime型、smalldatetime型など）を、yyyy/mm/dd の形式で表示する。
select format(GetDate(),'yyyy/MM/dd') AS 'yyyy/mm/ddフォーマット'SQL Server 2019は、convert関数でも動作する。