SQLCMD(SQLServerでコマンドプロンプト/CUIからSQL実行)

SQLServerでSQLを実行する際、わかりやすい方法としては

SQL Server Management Studio(SSMS)にて新しいクエリを作成する事ですが、

連続作業の場合にはコマンドラインからの実行が便利です。

 

そのためのツールがSQLCMDです。

sqlcmd ユーティリティを使用すると、Transact-SQL ステートメントやシステム プロシージャ、スクリプト ファイルを使用可能なさまざまなモードで入力できます。

  • コマンド プロンプト。
  • クエリ エディターでの SQLCMD モード。
  • Windows スクリプト ファイル。
  • SQL Server エージェント ジョブのオペレーティング システム (Cmd.exe) ジョブ ステップ。

このユーティリティでは、ODBC を使用して、Transact-SQL バッチを実行します。

 

利用前提環境

Windows インストーラー 4.5 と Microsoft ODBC Driver for SQL Server 17 の両方が必要です。

 

■利用法

コマンドプロンプトを起動から”SQLCMD”です。

管理者モードで起動する必要もなく、特に設定しなくてもパスが通っています。

 

オプションには以下のようなものがあります。

 

クエリ実行オプションを指定しない場合は対話モードになります。

この場合、クエリ実行の際にはSQL文の次に「GO」を指定します。

use msdb

go

のイメージですね。

 

 

-q または -Q で、コマンドオプションとしてSQL文を指定できます。

2つの違いはSQL文実行後の振る舞いです。

連続実行したいような場合は-Qを指定(コマンド1行ごとにSQLCMDの接続を終了する)がよいでしょう。

 

複数のインスタンスで同じSQL文を実行するような(例:新しいユーザを全DB環境に登録する)場合は、

実行するSQL文をファイルとして用意しておき、-i オプションで読み込ませるのが良さそうです。

 

 

 

 

※本投稿は過去に掲載したものを整理して再掲したものです。

 

継続は力なり、の実証結果

このブログ、アカウントを作ったのは何年も前なんですが、

2019年の12月に内容を刷新して今の内容で書き始めました。

ちょうど大きな契約を終えた後で半年ほど休養していた時期に、

独立した友人(Web関連)の勧めをうけて始めたものです。

 

 

もともとのコンセプトはこういう感じだったみたいです。

確かに最初はそうだったかも知れません。

 

 

 

最初の三ヶ月の記事投稿数は18。2020年2月から常駐案件に入ったのですが、

1月は時間があったのでなるべくアウトプットしようと考えていました。

 

で、その期間(2019/12~2020/2)のアクセス情報。クリック数1。

なんだかナンバー1みたいで気持ちいいですね。

当初のコンセプトは「ブログでお金を稼ぐ」だったので、アフィリエイトリンクなんかも貼られてます。

踏まれた事はありません。まあナンバー1ですから仕方ない。

 

 

 

仕事を再開したのでブログは毎週末に書くようにしよう、と自分ルールを決めて取り組みました。

「その情報が欲しい人にとっては入り口がたくさんあった方がいいから、世の中に同じこと書いてるサイトがたくさんあったとしても気にせず書けばいい」

これはブログを書くキッカケになった友人の言葉なのですが、まあそういう考え方もあるかな?と、独自性とか集客みたいな事は考えない事にしました。
継続性を考えると書きやすいテーマの方がいいですし、どうせ書くなら何か存在する意味のあるものになると嬉しい。

そもそもこんな誰もみないブログで金稼ぐとか烏滸がましいにも程がある。何よりそういう「何でもカネカネ」みたいなサイトや人は自分が嫌いですし。

 

そういう訳で、仕事で分からなかった事や興味があった事、それらについて調べた技術的情報をメインに書くようになりました。
 

 

 

3月~5月の投稿数は14。もっとペース落ちてた気がしますが、意外とそうでもないですね。

アクセス情報を最初3ヶ月と比較してみると。。。

多少増えました。単純に記事数が増えるだけでアクセス数は増加しますね。

「入り口はたくさんあった方がいい」が自サイトに適用された形でしょうか。

 

 

 

6~8月の投稿数は18。結構真面目にコツコツ書いていたみたいですね。偉い(笑)。

この期間と、それまでの合算との比較。

明らかに増えた感じがありましたが、正直理由は分かりません。突然ポンと増え始めた印象です。

GoogleSearchConsoleも正直見方とかよくわかっていなくて、ただ眺めてるだけです…

 

 

9~10月の投稿数は7。毎週投稿に穴が空き始めてしまいました。

仕事が忙しさでちょっと疲れていたり、理由はないでもないですが、自分ルールが守れていないのは悔しいですね。

なんでもそうですが、最終的な審判は自分ですからね。宮崎駿氏の言葉を思い出します。

 

 

 

アクセス情報の方はというと、突然増え始めた数字はその勢いを強めてきました。

クリック数は2019/12~2020/8月までの合計を、2ヶ月で数倍上回りました。

平均CTRは同レベルですが、表示回数が6倍くらいになっているのが結果に現れたようです。

で、表示回数がなぜ増えたかというと平均掲載順位の上昇がその要因みたいです。

 

 

 

 

全期間を通してみるとこんな感じです。7月辺りからジワリときて、9月辺りでドーンと増え始めました。

グラフの谷は恐らく土日です。ブログの日別アクセスカウンタを見ていて思うのが、いつも平日に増えて土日はストンと落ちるなあと。

これには恐らくなのですが多分間違っていないと思う仮説があって。

「みんな仕事の中でググって調べている」

という事なんだと思うのですよね。私がそういう風に調べた事を書いているのですから。

 

 

 

約1年続けてみて、特に何を意識するでもなく、淡々と書ける事を書いてきたブログですが、情報を求める人に多少なり届いているのであれば嬉しいですね。

もうお金を儲けようという考えはサラサラなくて、ただ情報共有出来ればいいと思っています。

(そもそも本業でそれなりに貰っているので5年やそこら仕事が無くても困りませんし)

 

 

無知な高校生を騙す楽器屋、みたいな金儲けが横行しているなと(昨夜も)感じましたが、お金が稼げるから仕事だ、とは思えないんですよね。

誰かが求める事を、出来る人が提供する。自分では出来ないからやれる人にお願いしたい。

要望への応答に対する対価で無ければ仕事とは呼べないんじゃないかと。

大昔から、人の欲というのはそういう綺麗事の枠には収まっていない訳ですけど…

SQLServerのサービスアカウントにドメインユーザが指定出来ない

環境構築中にハマりました。

業務運用の為のドメインユーザが設定されていて、

SQLServerのサービスアカウントも同じユーザが指定されている、

そういう現行環境設定を元にSQLServerをインストールしていたのですが。

 

SQLServerのインストール時に、SQLServerサービスのアカウントを聞かれます。

デフォルト設定の場合なら特に問題ないのですが、ドメインユーザを指定する場合。

色々試した結論から、下記の条件を満たす必要があるようでした。

 

インストールする際のログインユーザは、ドメイン管理者または設定するドメインユーザである事

 

指定するドメインユーザが、インストール先となるサーバの管理者権限を持っている事

 

 

サーバにソフトウェアを導入する場合、特に何も条件がついてなければ

ローカルAdministratorのアカウントでログインするかと思います。

この状況で、SQLServerサービスのアカウントにドメインユーザを指定すると

「指定されたユーザが無効です」と延々怒られます。

 

直接文字入力ではなくGUIからの選択が必要なのか、パスワードが間違ってるのか、

あれこれ悩んでみたのですが、全然ダメでした。

 

軽くググってみると、ローカルAdminではドメインユーザ情報を参照する動作に問題がある、

みたいな記事を見かけたので、ドメイン管理者でログインしてみたのですが、結果は変わらず。

 

 

そこでもう一度現行環境に何かヒントがないかと調べていて気付いたのが②でした。

コンパネからユーザーアカウント。

アカウントの管理一覧の中にドメインユーザが定義されていて、管理者権限が付与されていました。

対象がドメインユーザなので、ローカルユーザの一覧には表示されません。

一応移行前にローカルユーザは調べていたのですが、こちらのUIはあまり触った事がなく。。。

 

ユーザーアカウントのUIから、サービスアカウントに指定したいドメインユーザに管理者権限を付与。

その後、ドメイン管理者でログインしてインストール、サービスアカウントを指定、

と進めていくと、無事希望のユーザを指定してのインストールが出来ました。

 

 

ユーザーアカウントの設定については特にややこしい手順はなかったのですが、

具体的な手順は手元になく、ドメイン環境でないと試しにくいので、

再度確認してから追記しようと思います。

 

JP1/AJS移行の概要 ユーザー情報移行の注意点

JP1/AJSのユーザー情報は、JP1/Baseの認証機能で管理されています。

JP1/Baseに登録されたJP1ユーザー情報の移行についてはいくつか注意点があります。

 

■基本的な手順

以前のエントリでも書いた内容になりますが、改めて。

ユーザー情報の基本的な手順下記の通りです。

1. 移行元でユーザマッピング定義を取得
 jbsgetumap > ユーザマッピング定義ファイル

2. ユーザマッピング定義ファイルを移行先へコピー
 

3. パスワード定義ファイルを作成
ユーザーマッピングで利用するOSユーザーとパスワードを以下の形式で設定

 OSユーザー名1:パスワード

4. 移行先で[パスワード管理]にOSユーザーを一括登録
 jbsmkpass -f パスワード定義ファイル

5. 移行先でユーザーマッピングを設定
 jbsmkumap -f ユーザマッピング定義ファイル

6. セキュリティ関連定義を移行元から取得し、移行先へ上書き
・インストール先\JP1Base\conf\user_acl\JP1_Passwd
・インストール先\JP1Base\conf\user_acl\JP1_UserLevel

7. 移行先で設定を反映する
 ・JP1/Baseのサービス再起動

 ・または jbs_spmd_reload コマンドを実行

 

 

■注意べきポイント

①ユーザマッピング定義ファイルについて
・移行元と移行先で異なるOSユーザーを割り当てる場合は編集が必要
・「サーバホスト名」が*でない場合は移行先のホスト名に変更する必要

 

②jpsmkpassコマンドについて
・事前にOSにユーザが登録されている必要あり

・パスワードがセキュリティポリシーのパスワード要件を満たしている事

・ドメインユーザを指定する場合は、ドメイン情報にアクセス出来る状態である事

 

③セキュリティ関連定義について
JP1_Passwdのパスワード保管形式について、いつ導入された機能か詳細確認中ですが(バージョン12?)、JP1ユーザーのパスワードを保存する際のハッシュレベルが指定出来るようになりました。

3.4.6 パスワード保管形式の設定

 

http://itdoc.hitachi.co.jp/manuals/3021/30213D6500/BASE0085.HTM

 
 

マニュアル記載を見た感じだと、v12インストール時はレベル2、v11-50以前だと1になるようです。

そのため、v12の環境に古い定義ファイルを移行してくると、環境定義と定義ファイルのデータ形式が不整合となり、JP1ユーザーでのログインに失敗します。(認証サーバが閉塞する)

 

ハッシュレベルを以前同様の値(=1)に合わせる事で、移行元環境の定義ファイルでもログイン出来るようになります。

 

1.プライマリー認証サーバに,次の内容の定義ファイルを作成する。

[JP1_DEFAULT\JP1BASE\]
“HASH_LEVEL”=dword:00000001

2.jbssetcnfコマンドを実行する。

 

 

しばらくはJP1移行関連の日記になると思います。

 

SQLServer SSISパッケージとジョブの移行

SSISパッケージの移行方法メモです。

オペレーションは環境によって異なると思うので、とある1パターンと思って頂ければと。

 

■環境/条件

・SSISをバッチ代わりに使用

・実際に処理対象となるDBは別サーバ上に存在

・SSISパッケージはSQLserverに保存

・SSISパッケージの起動は、SQLServerジョブまたはDOSバッチファイル

・移行先サーバはNW未接続の為、外部媒体でデータを移行する必要あり

・SQLServerのバージョンは、移行元が2008、移行先も2008

 

 

■エクスポート

SSISパッケージ

1.SSMSで移行対象サーバに接続します。接続先は[Integration Service]。

権限を持つユーザでのWindows認証接続になります。権限がないとパッケージが見えなかったり。

 

2.左ペインのツリーを展開して格納先を開きます。当方環境では[格納済パッケージ]>[MSDB]。

 

3.パッケージを右クリックして[パッケージのエクスポート]を選択。

 

4.パッケージの場所は[ファイルシステム]を選択。

ファイル出力パスを指定する。暗号化は、すぐ移行するなら気にしなくてもいいと思います。

わかるなら、パッケージ作成時のルールに従うべきでしょう。

 

 

SSIS起動ジョブ

1.SSMSで[データベースエンジン]に接続します。ユーザは①と同じか、saで。

 

2.SQLServerエージェントが起動していない場合は起動。

 

3.左ペインのツリーから[SQLServerエージェント]>[ジョブ]を選択。

 

4.F7キー押下。右ペインにジョブのリストが表示されます。

ツリーからジョブを右クリックでも構わないのですが、ここだと複数選択が可能です。

対象ジョブを選択して、右クリックメニューからエクスポートします。

出力形式を選べますが、移行を目的とするならスクリプトファイル一択かと思います。

 

 

 

■インポート

SSISパッケージ

1.SSMSで移行対象サーバに接続します。接続先は[Integration Service]。

権限を持つユーザでのWindows認証接続になります。権限がないとパッケージが見えなかったり。

 

2.左ペインのツリーを展開して格納先を開きます。当方環境では[格納済パッケージ]>[MSDB]。

 

3.パッケージを右クリックして[パッケージのエクスポート]を選択。

 

4.パッケージの場所は[ファイルシステム]を選択。

ファイル出力パスを指定する。暗号化は、すぐ移行するなら気にしなくてもいいと思います。

わかるなら、パッケージ作成時のルールに従うべきでしょう。

 

 

SSIS起動ジョブ

1.SSMSで[データベースエンジン]に接続します。ユーザは①と同じか、saで。

 

2.出力したスクリプトファイルを実行します。

ファイルを開く、新しいクエリに中身を貼り付ける、など幾つか手段はあると思います。

 

注意点としては、ジョブに定義されたオブジェクトを事前に作成しておく事

・ユーザ

・オペレータ

パッケージは事前にインポートしていたので分かりませんが、パッケージが無い場合もエラーになる気がします。

 

 

 

記憶を頼りに書いたので抜け漏れがあるかも知れませんが、適宜補完願います…

 

ファイバチャネル接続ストレージの恐怖

ファイバチャネルボードの交換対応で作業確認漏れがあり、作業延期になりました。

キーワードになったのが「WWNの変化」です。

 

触れる機会が少なかったので失念してしまっていたので、

おさらいの意味で情報を整理してみたいと思います。

 

 

■WWNとは

https://ja.wikipedia.org/wiki/World_Wide_Name

World Wide Name(WWN)または World Wide Identifier(WWID)とは、ファイバーチャネルまたは Serial Attached SCSI によるストレージエリアネットワークにおける一意の識別子である。

 

上記ページにも書いてあるんですが、イーサネットでいうMACアドレスと似たようなものです。

 

 

 

■それで?

さっとググった感じ、こちらの記事が分かり良かったです。

伊藤忠テクノソリューションズ様のサイトより

https://www.ctc-g.co.jp/report/column/storage_se/vol08.htm

ストレージ概論~接続方式の多様化

こちらの記事の「4. FC-SAN (WWNとFCID)」にもWikipediaと同様の事が書かれています。
また、WWPN、WWNNという言葉も使われるようです。
WWPNは実際会話にも出てきて、そこはかとなく「WWNでは・・・?」と思ってました(不勉強でした)。
 
 
上記記事の前後にもう少し目を通してみると、
2. FC-SAN (Fiber Channel – Storage Area Network)
FCスイッチで構成されたネットワーク環境だけを指してFabricという語もよく用いられます。

IPネットワークと同様に、データのルーティングを行うスイッチがサーバとストレージの間に介在しますが、これはFC-SANの場合にはFC-Switchと呼ばれます。

主な物理要素には、HBA(Host Bus Adaptor)、FCケーブル、FC-Switchがあります

 

 

3. FC-SAN(コンポーネント)

HBA – サーバにはFCケーブルのためのポートが準備されていないので、FCポートを有するHBAをサーバのスロットに挿入する必要があります。

 

 

5. FC-SAN (ゾーニング)

ゾーニングの設定のないFabricでは、そのFabricにつながれた全てのサーバとストレージ、およびストレージ内のボリュームが相互に丸見えの状態になってしまいます。

H/Wゾーニングとは、サーバとストレージが接続されているFCポートとFCポートの組み合わせで構成

サーバ側の情報(WWNN)とは全く無関係にゾーニングをしているので、サーバが入れ替わるかサーバ側のHBAが変更(=WWNNが変更)になった場合でもSAN環境としては影響がない

S/Wゾーニングとは、WWNの組み合わせで接続を制御

物理的な位置に依存しないという自由度がある反面、WWNが変わってしまう(HBAの交換など)とゾーニングの変更を行わない限りサーバとストレージの接続は確立できない

 

 

■つまり?

今回我々が陥ったのは

「HBA交換でゾーニング情報が変わった事による通信設定不良」

だったようです。

今回の環境ではFC-Switchはストレージ筐体内蔵のはずなので、

ストレージシステムの管理コンソールから設定する事になると推測されます。

同ストレージには別のサーバも繋がっているので、おいそれと変更も出来ませんが…

 

 

■今後の対応は・・・

手順を確認するか、ベンダSEに作業を依頼するか…

ちなみにこれ年末にリプレースする予定のハードなのです…

お金今掛けるのかよ・・・・・・・・・・

 

内作でやれと指示が出る気がしてなりません。

来週はベンダサポートとやり取りしまくる一週間になりそう。。

 

JP1/AJS移行の概要 (ホスト名とIPアドレスの変更)

現在JP1のジョブネット環境移行の準備中です。

 

移行の条件として「移行元のホスト名・IPアドレスを引き継ぐ」事が挙げられているのですが、

当然構築時点で引き継いでしまうと稼働中の移行元と値が重複してしまいます。

 

といった理由から、仮のホスト名・IPアドレスで構築及びテストを実施し、

本番切替時に値を変更する方法を調査しています。

 

 

■見るべき資料

JP1 Version 10 JP1/Automatic Job Management System 3 運用ガイド

 

http://itdoc.hitachi.co.jp/manuals/3021/3021310710/INDEX.HTM
「8.9.1 JP1/AJS3が動作しているホストの名称を変更する」
「8.9.2 JP1/AJS3が動作しているホストのIPアドレスを変更する」

 

 

 

■事前準備
・ホスト名変更前にリモートジョブネットの実行登録を解除
・イベントジョブを実行しているエージェントホストのJP1/AJS3をすべて停止
・既存の設定を控える(ajsembdbstatus)

 

 

■手順
前処理

1.AJS-Viewからログオフ
2.ジョブネットの定義をバックアップ(ajsprint)
3.実行エージェントの定義をバックアップ(ajsagtprint)
4.JP1/AJS3関連サービスを停止
5.QUEUE/サブミットジョブ実行環境の定義をバックアップ(jpqexport)

※QUEUE/サブミットジョブを使用している場合のみ
6.JP1/Base関連サービスを停止

ホスト名とIPアドレスの変更
マネージャーホストのIPアドレスとホスト名を変更する。

ジョブ実行環境回復
QUEUE/サブミットジョブ実行環境を再作成(jpqimport)
※QUEUE/サブミットジョブを使用している場合のみ

 

組み込みDBの再構築
1.組み込みDB環境のデータを削除(ajsembdbunset)
2.組み込みDBの構築(ajsembdbbuild)
3.組み込みDBのセットアップ(ajsembdbsetup)
4.組み込みDBを停止

環境起動

1.JP1/Base関連サービスを起動
2.JP1/AJS3サービスを起動
3.エージェントホストをコールドスタート(jpoagoec)
4.マネージャーホストをコールドスタートする。

定義回復
1.ジョブネット定義を回復(ajsdefine)
2.実行エージェント定義を回復(ajsagtadd)
 

 

 

JP1/Baseについての記述が出てきますが、最小限触れる程度に留めています。

Baseに関しては用途が多岐に渡る為個別に記事を作成しようと思います。

 

 

各タイミングで実行するコマンドの引数等は環境ごとに様々だと思いますので、

コマンドリファレンスを参照下さい。

JP1/Automatic Job Management System 3 コマンドリファレンス

http://itdoc.hitachi.co.jp/manuals/3021/30213D2810/INDEX.HTM

 

 

インフラSEの思う『要件定義』

※以下の内容はあくまで個人の考えです。世間一般で正しいかどうかは知りません。

 

■要件定義書に必要な要素

・要件の一覧

まず何よりもこれ。顧客(ユーザの意味も含め)から挙がった要望がメイン。

どういった要件があったのか、見返せる必要があります。

(言った言わないを避ける為)

ベンダ側から提案するシステム化にまつわる課題も有りえます。

課題は切り出して一覧化する事も多いです。

 

・各要件の実現方式案と費用感

挙がった要件のシステム化を実現する為の手法。

複数ある場合も多々ある為、方式の比較検討を実施します。

費用については、「高額」「安価に抑えられる」の様なふんわりした言葉は×。

標準提供価格や過去事例等をベースに万円単位(対象システムの規模により変動)程度の概算。

金額は比較検討時の大きな要素です。

 

・システムやネットワーク等インフラ構成のイメージ

要件定義時点では「構成図」まで落とし込むのは無理です(後に続く基本設計でやる事です)。

だからといってシステム処理の流れやサーバ間通信の方法などを言葉で表現しても分かりにくいので、

言った言わないを含め認識の齟齬を避ける為にも大まかなイメージ図が必要です。

 

・タスクの公開と分担

どんなタスクがあって、顧客に何を求めるか、それが遅れるとどのように影響するか。

この辺りを共有しておく事はとても大事だと思います。

要件定義ならではのものではなく、プロジェクト一般に求められる要素ですね。

 

・一般的な非機能要件についての検討資料

この部分はネットを探せばいくらでも転がってると思います。

信頼性、可用性、性能、バックアップ、運用、あたりでしょうか。

代替業務手段はあるか、システム利用時間帯は何時か、同時処理数の想定は幾らか、バックアップが必要なデータは何か、定期的に必要な運用操作が無いか、etc…

 

新規システムの場合、運用については未知数の部分が多く悩みそうですね。

基本設計や詳細設計、システムテストでの実績から具体性を持たせて設計していくのもアリでしょう。

 

 

■要件定義のススメ方

①ヒアリング

顧客要件を洗い出し、システム化方式案を検討して、どのようにシステム化するかを定義する。

という作業の中身から考えれば当然ですが、ヒアリングからスタートです。

一般的な非機能要件であればヒアリングシートを事前に用意できるので、記入依頼するのもアリ。

ただ、顧客は現業遂行しながらなので、メールだけポンと送ってもなかなか相手してくれなかったりします。

初期タスクの分担については、早い段階で一度打合せ開催するのが良いでしょう。

 

②実現案検討

これがベンダの腕の見せ所。知識が問われる部分です。

また、要件間の整合性や制限事項にも注意が必要な為、経験が活きる部分でもあります。

例えば、ある要件の最善策が、別要件の制約事項に抵触する場合があったりします。

そのため、各案を急いで確定する必要はないと思いますが、顧客のイメージをブラッシュアップしていく為に、ある程度の塊・間隔で説明会など内容共有の場を設けるのがよいでしょう。

 

検討中に顧客から情報を引き出す必要性(端的に言えば質問)が生じる事も多々あります。

都度質問にするか、質疑内容をまとめておいて質問会を設けるか、やり方は様々です。

どちらもメリット・デメリットがありますし、顧客の好みもあるでしょう。

進め方については顧客と相談して合意するのが定番かと思います。

 

 

③レビューと承認

全体が出揃って整合性などを確認した上で、内容を顧客へ説明し承認頂きます。

全部をまとめて一度に、というのは時間的にも難しいと思いますので、小さな単位での承認を何度も繰り返す事になると思います。

実現方式の案毎、各要件のカテゴリ毎、ドキュメントの章立て毎など、いろんな単位が考えられます。

 

④要件定義内容の整理

取り決めがキチンと資料としてまとめられている事が最低要件です。

ドキュメントレビューの形で承認を得たのであれば、体裁は完成しているでしょう。

また、要件の一覧に最終結論を反映しておく必要もあると思います。

(検討結果で要件から外れる事も結構な割合で起こりますし、やる筈と思ってたという認識の齟齬も同じくらいの割合で起こります)

 

それに加えて、基本設計時に必要な情報にアクセスしやすいよう、インデックスを作成しておくのもオススメです。

要件の発生はいつもカテゴリ単位に纏まってる訳でもありませんが、設計はカテゴリ単位に行うのが一般的だと思いますので、識別情報があると便利です。

「あの話結論どうなったっけ」みたいな内容を探し回らなくて済むよう、状況もまとめておくとよいでしょう。

 

 

 

 

 

今週は会議や調査ばかりで技術的な業務があまり発生しませんでしたので、思いつくままに書いてみました。

正直大した経験はないので、甘い部分や間違いもあるかも知れません…

JP1/AJS3 環境移行のポイント

JP1/AJS3の環境を移行するに当たってのポイントについて調査している内容をまとめます。

 

■見るべき資料

JP1/Automatic Job Management System 3 運用ガイド
http://itdoc.hitachi.co.jp/manuals/3021/3021310720/INDEX.HTM

 2. バックアップとリカバリー

 4. ジョブネットの退避・回復

JP1 Version 10 JP1/Base 運用ガイド
 3.5 バックアップとリカバリー
 8. ユーザー管理の設定http://itdoc.hitachi.co.jp/manuals/3021/3021300120/INDEX.HTM

 

■概要

基本的には「移行元でバックアップ→移行先でリカバリ」の流れになる模様。

その為、移行先では「OS構築→JP1/Baseインストール→JP1/AJS3インストール」を事前に済ませておく。

統合インストーラにはBaseとAJSが同梱される場合があるが、インストール順序を守る必要があるので、Baseのみインストールしてから、AJSをインストールする。

セットアップ内容については環境毎、設計内容で様々なので割愛。

 

 

■実施する作業

移行の為に実施する作業は以下の通り(※調査中の為これが全てかは分からない)

  • ユーザーマッピング定義
  • 認証サーバのJP1ユーザー定義
  • エージェント定義
  • ジョブユニット定義
  • 共通定義情報
共通定義情報は、移行元先で環境が異なる部分に留意する必要がある。
 
 

■各種定義の移行

①JP1/Baseユーザーマッピング関係の定義の移行
なお、OSユーザーのパスワードは個別に設定が必要です。
1. 移行元で定義を取得

jbsgetumap > jbsUmap.txt(任意名称でよい)

 

2. jbsUmap.txtを移行先へコピー
移行元と移行先で異なるOSユーザーを割り当てる場合は編集が必要
「サーバホスト名」にマネージャホスト名を定義している場合は移行先のホスト名に変更する、または「*」指定に変更する

3. 移行先でパスワード定義ファイルを作成
ユーザーマッピングで利用するOSユーザーとパスワードを以下の形式で設定

(ファイル名は任意。ここではjbsPass.txt)

OSユーザー名1:パスワード

  :

4. 移行先で[パスワード管理]にOSユーザーを一括登録

jbsmkpass -f jbsPass.txt

[パスワード管理]に事前に設定した情報がある場合、jbsmkpassコマンドで上書きされる

5. 移行先でユーザーマッピングを設定

jbsmkumap -f jbsUmap.txt

 

 

②JP1/Base認証サーバのJP1ユーザー関係の定義の移行
1. 移行元で定義を取得
・インストール先\JP1Base\conf\user_acl\JP1_Passwd
・インストール先\JP1Base\conf\user_acl\JP1_UserLevel

2. 取得した定義ファイルを移行先の同ファイルと置換
 

3. 移行先で設定を反映する
サービス起動時に変更が反映される。稼働中に変更を反映したい場合は以下のコマンドを実行。

jbs_spmd_reload

③エージェント定義の移行
1. 移行元でサブミットジョブ実行環境の定義を取得

jpqexport -dt isam -co jpqexp.txt(任意名称でよい)

 

2. 移行元でエージェント管理制御の実行エージェントの定義を取得

ajsagtprint -l > ajsagt.txt(任意名称でよい)

3. 取得したファイルを移行先へコピー
※移行元と移行先で実行ホストが異なる場合は変更が必要

4.  移行先のサブミットジョブ実行環境DBを作成

(「$system」の定義のみの場合は移行不要)
 4-1. JP1/AJS3のサービスを停止する

 4-2. インストール先\JP1AJS2\database\queue\以下のファイルを削除

 4-3. コマンドでDBを作成

jpqimport -dt isam -ci jpqexp.txt

 4-4. JP1/AJS3のサービスを再起動する

5. 移行先でエージェント定義を設定

(「@SYSTEM」の定義のみの場合は移行不要)

set JP1_USERNAME=jp1admin

ajsagtadd -i -f ajsagt.txt

④ジョブユニット定義の移行
1. 移行元で定義を取得

ajsprint -F スケジューラーサービス名  “/*” > ajsunit.txt(任意名称でよい)

例:AJSROOT1以下の全ユニット定義を「E:\tmp\ajsunit.txt」に出力
ajsprint -F AJSROOT1 “/*”  >E:\tmp\ajsunit.txt

2. 移行元でルートジョブグループのカレンダー情報を取得

ajsprint -F スケジューラーサービス名 -d / > rootcal.txt(任意名称でよい)

3. 移行元でルートジョブグループ定義の情報を記録
ルートジョブグループ(デフォルトではAJSROOT1)の以下定義を記録する
・コメント、所有者、JP1資源グループ、基準時刻、基準日、月区分

4. 取得したファイルを編集
移行元と移行先で値が変化する項目について、取得したファイルを編集する。

各項目の定義ファイル上の表現については下記を参照

ジョブネット定義情報の記述方法

http://itdoc.hitachi.co.jp/manuals/3020/30203S1132/AJSP0128.HTM

5. 移行先にジョブネット定義を反映

ajsdefine -F スケジューラーサービス名 ajsunit.txt

6. 移行先にルートジョブグループのカレンダー情報を定義
(取得したカレンダー情報の中身が空の場合は実施不要)

ajscalendar -F スケジューラーサービス名 -c -df rootcal.txt /

7. 記録したルートジョブグループの定義を再設定

8. 必要に応じてジョブネットを実行登録
※ajsefineコマンドで定義した時点では「未登録」状態の為

 

無料で出来る!SQL文のテスト環境~SQL Server編~

なんであれIT系の言語の学習に実行環境は必須ですが、SQLの学習を始めたばかり、という方にとって

「実行環境の作り方/使い方」は分からない事だらけではないでしょうか。

 

という事で、お金をかけずにSQL文(クエリ)を実行して結果を得る、

その為の環境構築から実際にSQLを実行出来る所まで、

について書いてみたいと思います。

 

対象環境はWindows10です。

無償エディションである「SQL Server Express」を使用します。

※Developerも製品無料のエディションですが、ユーザーライセンスが必要です。

 

1.ダウンロード

こちらのサイト、画面中段辺りからダウンロードします。

https://www.microsoft.com/ja-jp/sql-server/sql-server-downloads

 

2.ダブルクリックでインストール開始

最初は「基本」で良いと思います。

ライセンスに同意、インストールパスを指定して、インストールボタンをクリック。

コンポーネントのダウンロード(260MB程度)とインストールが実行されます。

 

インストール完了画面で「今すぐ接続」をクリックすると、SQL Serverのコマンドラインクライアント(SQLCMD)が起動します。

 

このままこんな感じでSQLを実行する事も可能です。

 

本記事が前提とする読者の方は多分SQL Serverの構造を理解する前の段階だと思いますので、

見た目でわかりやすいGUIツールをインストールしましょう。

 

3.SQL Server Management Studio(SSMS)のインストール

インストール完了画面の「SSMSのインストール」をクリックするとブラウザが開きます。

「SSMSのダウンロード」のリンクをクリック・・・してはいけません。英語版setupがダウンロードされます。

画面中段の「使用できる言語」の箇所で、「日本語」をクリックすると、日本語版setupがDLされます。

 

4.SSMSインストーラを起動

「Install」ボタンをクリックします。エラーが無い限り、特に操作は不要のまま完了します。

 

5.スタートメニューからSSMSを起動します。

 

6.ログインする

SSMS起動時にはデフォルトで「サーバーへの接続」ダイアログが表示されます。

取り敢えず今回は、認証の部分はそのままで。

サーバー名が空欄の場合は、コンボボックスを開いて「参照」。

データベースエンジンのツリーを展開し、「コンピュータ名\SQLEXPRESS」を選択してOKボタンをクリック。

 

ログイン後の画面はこんな感じになります。

データベース、サーバー(インスタンス)、等の基本的な知識はこちらのサイトが参考になると思います。

https://www.nobtak.com/archive/category/SQL%20Server

 

 

7.データベースを作る

SQL文はデータベースに対して実行するものです。データベースとは、データを入れる器のようなもの。

まずは、テストしたいSQLを実行する為の器を用意します。

ツリーの「データベース」を右クリックして、「新しいデータベース」を選択。

 

こんなウインドウが表示されます。

データベース名を入れると、データベースファイルの論理名にも同じ名前が入ります。

 

TESTデータベースが作成されます。

 

 

8.テーブルを作る

SQLはデータベースに対して実行するものだと言いましたが、

通常使用するデータ操作言語(select,insertなどのDML)は、

具体的にはテーブルに対して実行するものです。

TESTデータベースにはテーブルがありませんので、テーブルを作ります。

 

TESTデータベースのツリーにある「テーブル」の右クリックメニューからテーブルを選択

 

テーブル構造を定義します。

取り敢えずサンプルとしてこんな感じで。

テーブル名 parts ・・・部品情報の表

partsID char(8) NULL非許容(主キー) ・・・部品を示すID

partsName varchar(64) NULL許容  ・・・部品の名前

partsPrice integer NULL非許容  ・・・部品の単価

データ型を選択する際、コンボボックスでは「char(10)」など、

予め列のサイズが決まっているかのような表現になっています。

画面下部の「長さ」で変更出来ますので、列サイズは気にせずデータ型だけ見て選べばOKです。

 

主キーの設定は、対象列を右クリックして「主キーの設定」を選択。

列の先頭に鍵アイコンが付きます。

 

ウインドウを閉じる時は、タブのように表示された部分の×をクリックします。わかりにくい。

 

確認ダイアログが表示されます。ここで「はい」をクリックすると、

ようやくテーブル名を付けさせてくれます。

 

partsテーブルが出来ました。

 

 

9.SQLを試す

ようやくSQLを試せる環境が整いました。

SQL入力ウインドウを表示するには、左ツリーのデータベース名を右クリックして「新しいクエリ」を選択します。

 

まずは先程作ったテーブルに、INSERT文でデータを入れてみましょう。

あとはselectやupdate、deleteなどをお好みに応じて!

 

入力したSQLを実行するには、F5キーかツールバーの「▷実行」をクリックします。

上記例のように複数のSQLを記述した場合、通常は全て上から順に実行されますが、

一部選択状態で実行した場合は、選択したSQLだけが実行されます。

 

 

それでは皆様、よいSQLライフを!!

 

 

 

自分がSQLを学んだ時の事を思い返すと、以前のブログ記事でも書いたのですが

・就業先から分厚いマニュアルを渡され「一週間で覚えてね」

・どうやって勉強すればいいかネットで知り合った先輩PGに泣きつき

・その方からデータベースのインストーラをゴニョゴニョしていただき

さあやるぞ!とインストールしたのですが、そこから何をすればいいのか分からない!

となって、そもそもSQLってデータベースって何やねんと本を買い漁って何とか間に合わせた感じでした。

あの時はリミットがすぐだった事もあり、受験勉強さながらに机に向かってました。

 

そんな初心者でも、2年も経つ頃にはチューニングとか出来るようになり、

15分位掛かってた500行のSQLを実行時間1分前後まで縮めた事もありました。

 

やる気さえあれば、大抵の事は出来るようになると思います。

やりたいけどとっかかりがつかめない、そんな方の一助になればと願ってやみません。