カテゴリー: 技術系

  • 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」を選択した。これだけで繋げるのだから、楽である。

  • 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を再起動して、同じログがでるかを確認する。

    これで完了。

  • 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

  • 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

    注意としては、照合順を厳密に指定しておく必要がある場合には、指定が変わってしまう。その場合は、検索で一致させるものを変更するなどの対応が必要。

  • .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への移行が推奨されている。

  • 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();
    }
  • GASのDB接続で、オートコミットになっているかを調べる

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

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

    サンプルコード

      // DBにコネクションをはる
      var connection = Jdbc.getConnection(addr, connectionInfo);
    
      // オートコミットを無効にして、手動でコミットするようにする。
      connection.setAutoCommit(false);
    
      // Trueならオートコミット、Falseなら手動コミット。ログに書き出す。
      Logger.log('オートコミットの設定: ' + connection.getAutoCommit());
  • ASP.NETでChrome対応したらJSでテキストボックスに値が入らなくなったときの対応

    IE用に作られたASP.NETのアプリを、Chrome対応(Chromium Edge対応)しているときに、JavaScriptでASP.NETのパーツのテキストボックス(type=text)に値をいれたところ、値が入らないということがおきた。「getElementById(“ID”).value」に、JavaScriptから値をいれたが、IE11では問題ないのに、Chromeだと値が入らなかった。

    document.getElementById("ID").value = "値";
    // ↑これだと、IE11は値が入るが、Chromeだと入らない。

    PostBackは発生させていない処理なのだが。いろいろと調べていき、Chromeの場合は「.defaultValue」を使って初期状態の値を書き換えれば、画面の表示が変わることを確認できた。

    document.getElementById("ID").defaultValue = "値";
    // ↑Chromeの場合は、defaultValueを書き換える。

    IE11も残しておく必要があったので、ブラウザの種類をみて、IF文でIEとそれ以外で分岐させるようにした。

    サンプル。

        // ブラウザを取得する
        var userAgent = window.navigator.userAgent.toLowerCase();
        if (userAgent.indexOf('msie') != -1) {
            // IEのときの処理を書く
            document.getElementById("ID").value = "aaaa";
        } else {
            // IE以外の処理。ChromeやChromium Edgeの想定
            // document.getElementById.value だと、画面上の表示が変わらないことがわかった。
            // そのため、document.getElementById.defaultValue に変更したところ、うまくいった。
            document.getElementById("ID").defaultValue = "aaaa";
        }
  • FreeBSDでpkgをアップデートしたらMariaDBが起動しなくなった

    FreeBSDで、”pkg upgrade”して、パッケージを最新の状態にしたところ、MariaDBが起動しなくなった。エラーログをみていると、DBのテーブルを修復したあとにDBがシャットダウンされている。DBのファイル破損が原因かと思い、いろいろと調べて対応したが、実はファイルの問題ではなかった。

    原因は、MariaDBのバージョンが「MariaDB 10.5」に上がったことによる「my.cnf」ファイルの変更だった。

    /usr/local/etc/mysql/conf.d/my.cnf

    このconf.dのディレクトリに、my.cnfがあることで、これを読みにいって、その設定で失敗して、サービスが落ちていた。同じところに、client.cnfもserver.cnfもあるが、これを読まずにmy.cnfを先に読みにいって、落ちていた。my.cnfは、1つ上の階層の「/usr/local/etc/mysql/」にもあり、conf.dの下を読み込むように書かれている。

    いろいろと行ったのだが、対応の正解は、conf.dの下のmy.cnfを消す(リネームでOK)。server.cnfとclient.cnfの設定を確認して、MariaDB(mysqld_safe)を起動させる。

    ちなみに、errファイルに記録されていたログは下記。あとは、ログ自体が出力されていない。ログがそもそも出力されていなければ、my.cnfを疑うべきだった。

    2022-02-05 15:36:39 0 [Note] /usr/local/libexec/mariadbd (initiated by: unknown): Normal shutdown
    2022-02-05 15:36:39 0 [Note] Event Scheduler: Purging the queue. 0 events
    2022-02-05 15:36:39 0 [Note] InnoDB: FTS optimize thread exiting.
    2022-02-05 15:36:40 0 [Note] InnoDB: Starting shutdown...
    2022-02-05 15:36:40 0 [Note] InnoDB: Dumping buffer pool(s) to /var/db/mysql/ib_buffer_pool
    2022-02-05 15:36:40 0 [Note] InnoDB: Restricted to 2016 pages due to innodb_buf_pool_dump_pct=25
    2022-02-05 15:36:40 0 [Note] InnoDB: Buffer pool(s) dump completed at 220205 15:36:40
    2022-02-05 15:36:40 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
    2022-02-05 15:36:40 0 [Note] InnoDB: Shutdown completed; log sequence number 1363646560; transaction id 111190553
    2022-02-05 15:36:40 0 [Note] /usr/local/libexec/mariadbd: Shutdown complete
  • VMware vCenter Converter Standalone 6.2 でWindows Server 2003 の変換がエラーになる。

    VMware vCenter Converter Standalone 6.2 でWindows Server 2003 を仮想マシンに変換しようとしたところ、Agentのデプロイで「Error code: 1,603」でエラーになった。

    サポート範囲を調べてみると、Windows Server 2003は、Windows Server 2003 R2 SP2がサポート対象で、R2が付かないバージョンはサポート対象外だった。

    サポート外だが、無理やりP2Vできなかと、Converter Agentだけのインストールをためしてみたが、サービスをオンにするところで、失敗してロールバックした。

    調べてみると、VMware vCenter Converter Standalone 5.0 であれば、無印のWindows Server 2003にインストール可能。試してみたところ、5.0であればインストールはできた(過去にインストーラーを取得しておいてよかった)。しかし、VMware vCenter Converter Standalone 6.2からの接続は、接続経路の暗号化方式の不一致により、エラーになった。

    今度は、vCenter Converter Standalone 5.0 から、ESXi6.7に対して、P2V先を指定してみたが、これも通信時の暗号方式の問題で接続できずエラーになった。

    Veeam Backupのエージェントを、Windows Server 2003(無印)にいれて、イメージバックアップして、そのイメージを仮想マシンとして復元する方法も試した。Veeam BackupもVersion 9.5でも.net frameworkのバージョンが古すぎて、Windows Server 2003(無印)にエージェントのインストールができず。イメージバックアップを取得して、仮想マシンとしてリストアする方法についても失敗した。

    そのため、vCenter Converter Standalone 5.0を使って、Windows Server 2003(無印)を一度、VMware Workstation形式の仮想ファイルに変換した。次に、このVMware Workstation形式のファイルを、vCenter Converter Standalone 6.2で指定し、V2V(Virtual to Virtual)で、ESXi6.7に対して保存した。これで、なんとかP2Vは成功した。ネットワークの設定などは、変わっているため、仮想マシンの設定を編集して、新しくネットワークインターフェースの割り当てを行った。これで無事にWindows Server 2003(無印)のP2Vは完了した。

    仮想化すれば延命はできるが、物理サーバとして存在していると、そもそもP2Vでの仮想化の対象外になってしまう。延命するのであれば、早めに仮想化しておく必要がある。というのが、今回の教訓になった。