カテゴリー: 技術系

SQL Server 2005から SQL Server 2019へのリンクサーバーの接続ができた

前回、SQL Server 2019からSQL Server 2005へのリンクサーバーでの接続ができたので、今度はその逆を試した。Windows Server 2003の上のSQL Server 2005から、Windows Server 2022の上のSQL Server 2019に対して、リンクサーバーの設定をしたところ、接続でき、データの参照もできた。

リンクサーバーの設定のとき、接続は「SQL Server」を選択して、接続した。

2022年4月20日

apt updateで、Gitlabの更新で「署名が無効」のエラーが出た

Ubuntu Server上のGitLabをアップデートしようとして、apt updateしたところ「署名が無効です」のエラーが出た。

エラー:6 https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu bionic InRelease 
  以下の署名が無効です: EXPKEYSIG 3F01618A51312F3F GitLab B.V. (package repository signing key) <packages@gitlab.com>

2022年03月02日で、署名の有効期限がきれていたようだ。curlで新しいものを落として、aptキーに加えた（コマンドは下記）。キーを更新したので、あとは通常通りの更新でGitLabの更新ができた。

curl -s "https://packages.gitlab.com/gpg.key" | sudo apt-key add -

実際にやったときのログ。

エラー:6 https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu bionic InRelease 
  以下の署名が無効です: EXPKEYSIG 3F01618A51312F3F GitLab B.V. (package repository signing key) <packages@gitlab.com> 
187 kB を 3秒 で取得しました (69.6 kB/s) 
パッケージリストを読み込んでいます... 完了 
依存関係ツリーを作成しています 
状態情報を読み取っています... 完了 
パッケージはすべて最新です。 
W: 署名照合中にエラーが発生しました。リポジトリは更新されず、過去のインデックス ファイルが使われます。GPG エラー: https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu bionic InRelease: 以下の署名が無効です: EXPKEYSIG 3F01618A51312F3F GitLab B.V. (package repository signing key) <packages@gitlab.com> 
W: https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/dists/bionic/InRelease の取得に失敗しました  以下の署名が無効です: EXPKEYSIG 3F01618A51312F3F GitLab B.V. (package repository signing key) <packages@gitlab.com> 
W: いくつかのインデックスファイルのダウンロードに失敗しました。これらは無視され るか、古いものが代わりに使われます。 
zen@SEVR:~$ 
zen@SEVR:~$ apt-key list 3F01618A51312F3F 
pub   rsa4096 2020-03-02 [SC] [期限切れ: 2022-03-02] 
      F640 3F65 44A3 8863 DAA0  B6E0 3F01 618A 5131 2F3F 
uid           [期限切れ] GitLab B.V. (package repository signing key) <packages@gitlab.com> 
zen@SEVR:~$ 
zen@SEVR:~$ curl -s "https://packages.gitlab.com/gpg.key" | sudo apt-key add - 
OK 
zen@SEVR:~$ 
zen@SEVR:~$ 
zen@SEVR:~$ sudo apt update 
ヒット:1 http://jp.archive.ubuntu.com/ubuntu bionic InRelease 
ｶ荳ｼ倖2 http://jp.archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB] 
ヒット:3 http://archive.ubuntulinux.jp/ubuntu bionic InRelease 
ヒット:4 http://archive.ubuntulinux.jp/ubuntu-ja-non-free bionic InRelease 
取得:5 http://jp.archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB] 
ヒット:7 http://security.ubuntu.com/ubuntu bionic-security InRelease 
取得:6 https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu bionic InRelease [23.3 kB] 
取得:8 https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu bionic/main amd64 Packages [68.5 kB] 
255 kB を 3秒 で取得しました (85.1 kB/s) 
パッケージリストを読み込んでいます... 完了 
依存関係ツリーを作成しています 
状態情報を読み取っています... 完了 
アップグレードできるパッケージが 1 個あります。表示するには 'apt list --upgradable' を実行してください。 
zen@SEVR:~$ 
zen@SEVR:~$ apt list --upgradable 
一覧表示... 完了 
gitlab-ce/bionic 14.9.2-ce.0 amd64 [14.8.2-ce.0 からアップグレード可] 
N: 追加バージョンが 436 件あります。表示するには '-a' スイッチを付けてください。 
zen@SEVR:~$ 
zen@SEVR:~$ 
zen@SEVR:~$ sudo apt upgrade

2022年4月17日

Windowsはメモリが不足するとファイルのコピーに失敗する

Windowsはメモリが不足するとファイルのコピーに失敗する。そしてロールバックして、途中までのものも消える。

遅いネットワークで、別のサーバからのデータのコピーで、単一の大きなファイルだったので、時間がかかって、結果的にメモリが足りなくなって、失敗した。メモリも増えているので、レアケースになっているのかもしれないけれど。やはりメモリの空きは重要だ。

2022年4月10日
SQL Server 2019からSQL Server 2005へのリンクサーバーの接続ができた

Windows Server 2022にインストールしたSQL Server 2019から、Windows Server 2003のSQL Server 2005に対して、リンクサーバーの設定を行ったところ、接続できた。

SQL Server 2019から、リンクサーバー経由で、SQL Server 2005のテーブルの参照（Select）も更新（Update）もできた。SQL Server 2005はサポート終了しているので、マイクロソフトのサポート外だが。それにしても、SQL Server 2019からSQL Server 2005に接続とは、下位互換性が高い。本当に。

SQL Server 2019からSQL Server 2005へのリンクサーバーの設定は、SQL Server Management Studioから「サーバーオブジェクト」の「リンクサーバー」を選択して、右クリックから「新しいリンクサーバー」で作成した。作成時、プロバイダーは「SQL Server Native Client 11.0」を選択した。これだけで繋げるのだから、楽である。

2022年4月10日

SQL ServerがインストールされたサーバをP2Vしたら起動時にイベントログにエラーが記録される

イベントログに記録されていたログは下記。

イベントID　455
ソース　ESENT
msmdsrv (1400) ログ ファイル C:\Windows\system32\LogFiles\Sum\Api.log を開いているときに、エラー -1032 (0xfffffbf8) が発生しました。

イベントID　489
ソース　ESENT
msmdsrv (1400) 読み取るためにファイル "C:\Windows\system32\LogFiles\Sum\Api.log" を開こうとしましたが、システム エラー 5 (0x00000005): "アクセスが拒否されました。 " が発生したため開けませんでした。ファイルを開く処理は、エラー -1032 (0xfffffbf8) のため失敗します。

イベントID　490
ソース　ESENT
msmdsrv (1400) 読み取りまたは書き込みのためにファイル "C:\Windows\system32\LogFiles\Sum\Api.chk" を開こうとしましたが、システム エラー 5 (0x00000005): "アクセスが拒否されました。 " が発生したため開けませんでした。ファイルを開く処理は、エラー -1032 (0xfffffbf8) のため失敗します。

このエラーは、「C:\Windows\system32\LogFiles\Sum」のRead/Writeのアクセス権がないため、SQL Serverの起動時にログのフォルダを参照できずにエラーが記録されている。

対応方法は下記。

1. SQL Serverを実行しているユーザをサービスから調べる。

2. 「C:\Windows\system32\LogFiles\Sum」のプロパティを開き、セキュリティからユーザを追加し、Read/Writeの権限を付ける。権限を付けるユーザが見つからない場合は、セキュリティを緩めた

3. Windowsを再起動して、同じログがでるかを確認する。

これで完了。

2022年4月9日

SQL Serverでプロシージャーの実行がエラーになる

SQL Serverのプロシージャーの実行権限は、プロシージャーごとに、ロールまたはユーザに対して権限を付与する必要がある。権限を付与しておかないと、プロシージャーの実行ができない。（すっかり忘れていた）

SQL Server Management Studioを使っている場合は、該当のプロシージャーを選択して、プロパティを開いて、権限の部分で、ユーザやロールを指定して、権限を付与する。

https://docs.microsoft.com/ja-jp/sql/relational-databases/stored-procedures/grant-permissions-on-a-stored-procedure?view=sql-server-ver15

2022年4月9日
SQL ServerでViewの作成時に照合順序の競合エラーが出た
SQL ServerでViewの作成時に照合順序の競合エラーが出た。Japanese_CS_ASとJapanese_CI_ASで照合順があわないとのこと。Select文を単体で実行するとエラーにはなっていない。
```
equal to 操作の"Japanese_CS_AS"と"Japanese_CI_AS"間での照合順序の競合を解決できません。
```
調べていくと、DB上のテーブルの照合順は、「Japanese_CI_AS」で統一されていた。Select文を見直していくと、Where句で照合順を指定しており、これがテーブルと異なっていたため、競合エラーが発生していた。VIEWのときは、テーブル側と照合順が合致している必要があり、これを見落としていたのが原因だった。WHERE句で指定していた照合順をDB上のテーブルで指定されているものに変更した。
```
WHERE  項目名 = '値' COLLATE Japanese_CS_AS
```
注意としては、照合順を厳密に指定しておく必要がある場合には、指定が変わってしまう。その場合は、検索で一致させるものを変更するなどの対応が必要。
2022年4月9日
.NET Core 3.1をAzure上でサポート期間後も使い続けられるのか？

LTSの .NET Core 3.1が2022年12月3日に延長サポートが終了する。オンプレミスの環境ならば、自己責任で使い続けられるのだが、Azure上だとどうなるのかが気になり調べていた。それでやっと見つけたのが、下記の記事だ。

https://azure.microsoft.com/ja-jp/updates/extended-support-for-microsoft-net-core-31-will-end-on-3-december-2022/

https://azure.microsoft.com/ja-jp/updates/netcore31/

2022年12月3日を過ぎても、Functions でホストされているアプリケーションは引き続き実行され、アプリケーションは影響を受けないとのこと。いきなり使えなくなるということはなさそうだ。サポート切れ後に、新しく.Net Core 3.1でデプロイできるのかどうかは不明だが、この書き方だと当面は大丈夫そうではある。

しかし、Azure側の推奨としては、「潜在的なサービスの中断やセキュリティの脆弱性を回避するには、2022 年 12 月 3 日までに、Functions アプリケーションをランタイムバージョン 4.x (.NET 6 を使用する)に更新」することが求められている。何かセキュリティ的な問題が発生した場合には、短い期間で.NET Core 3.1のアプリケーションの実行が打ち切られるということもあり得るということ。さっさとLTSの.NET6に移行しろということだ。

Azure App Serviceのインスタンスでも、App Service でホストされているアプリケーションは引き続き実行され、既存のワークロードには影響しないとのこと。ただし、同じように.NET6への移行が推奨されている。

2022年3月27日

GASからMySQLに接続して、コミットする

通常は、自動コミットされるので、Update文やInsert文を実行したタイミングで、コミットされる。DBへの複数の書き込み処理を、同じタイミングで行うのは、自動コミットをオフにして、手動でコミットする必要がある。

自動コミットを無効にするには、DBコネクションの「.setAutoCommit(false)」を使用する。

手動でコミットするには、DBコネクションの「.commit()」を使用する。

試してみたところ、オートコミットをオフにした場合、「.commit()」を実行しなくても、エラーにはならない。GASのエディタ上でもアラートを上げてくれないので、注意が必要。

サンプルコード

function myFunction() {
  dbConnection();
}

// --------------------------------
// SSL 接続なしで接続する
// --------------------------------
function dbConnection(){
  Logger.log('start dbConnection function.');

  // 接続先設定
  var connectionIp = 'xxx.xxx.xxx.xxx'; // 接続のMysqlのIPアドレス（ホスト名も可）
  var userName = 'user'; // 接続で使うユーザ名
  var passwd = 'password'; // 接続で使うパスワード
  var databaseName = 'database'; // データベース名

  var addr = 'jdbc:mysql://' + connectionIp + '/' + databaseName;
  Logger.log('start mysql con');
  Logger.log(addr);

  var connectionInfo = {
    user: userName,
    password: passwd
  }

  // DBにコネクションをはる
  var connection = Jdbc.getConnection(addr, connectionInfo);
  Logger.log(connection.getCatalog());

  // オートコミットを無効にして、手動でコミットするようにする。
  connection.setAutoCommit(false);

  // sqlステートメントをデータベースに送信するためのオブジェクトを作る
  var statement = connection.createStatement();

  // Insert文を発行
  var resultInsert = statement.executeUpdate('Insert Into List (id,listname) values ("5","kanagawa")');

  // 実行結果が0なら失敗、1以上なら成功
  Logger.log(resultInsert);

  // 手動でコミットする。通常はオートコミットされるので必要なし。
  connection.commit();

  // ステートメントを閉じる
  statement.close();

  // コネクションを閉じる
  connection.close();
}

2022年2月19日

GASのDB接続で、オートコミットになっているかを調べる
コネクションの「.getAutoCommit()」を実行することで、DBへの書き込みがオートコミットになっているかどうかを調べることができる。

「.getAutoCommit()」の結果が、Trueならオートコミット、Falseなら手動コミット。手動コミットの場合には、「.commit()」を明示的に実行しないとＤＢにコミットされない。

サンプルコード
```
  // DBにコネクションをはる
  var connection = Jdbc.getConnection(addr, connectionInfo);

  // オートコミットを無効にして、手動でコミットするようにする。
  connection.setAutoCommit(false);

  // Trueならオートコミット、Falseなら手動コミット。ログに書き出す。
  Logger.log('オートコミットの設定：　' + connection.getAutoCommit());
```
2022年2月19日