2019年8月16日金曜日

GroupSession という選択肢 (グループウェア)

社内で利用しているグループウェアが更改の時期となり、有償無償問わず探していたところ、無償で、かつOSSというグループウェアで導入しやすそうなものを見つけたのでメモしておきます。
※決して、この会社の回し者ではありません

【特徴(というか採用ポイント)】

・他のOSSと比べても、機能が多い
・OSSはフリー(無償)
・無償で利用できるにもかかわらず、ドキュメント等が充実
・カスタマイズも、アドオン形式の模様(未確実) →ということは本体のVerUPも適用可
・その他採用ポイントとして、
 ・無償版ダウンロード時の入力フォームへ諸々記載したが、返答のメールが丁寧だった
 ・社内にはサーバ、ミドル、アプリ改修ができる技術者がいる

【まとめ】

機能が多く、習得までには時間がかかりそうですが、細かな部分で画面からの設定による制御も可能となっていて、比較的スムーズに導入を開始できそうです。

興味がある方は以下リンクよりお試しください
https://groupsession.jp/

Visual Studio 2019 と nuget

ほぼ1行Tips

あるベンダからソース一式を受領してビルドしたところ、「参照コンポーネント 'xxxxxxxx' が見つかりませんでした。」のエラー

nugetで取れるはず。と再度試しても、「利用できません」と。

原因:オンラインの情報を参照する設定となっていなかった
処置:オプション→NuGetパッケージマネージャ→パッケージソース
   追加 → https://api.nuget.org/v3/index.json (名前は任意)

2019年5月29日水曜日

Accessの実装は整理整頓が大事(自己反省と雑記)

雑記です。

最近、ちょっとしたツールの作成にAccessを使いだしています。Accessといえば開発入門の時によく使っていましたが、仕事として業務システムを開発するには危なっかしいイメージがあり採用することはほとんどありませんでした。

今回、利用者1名でExcel管理に毛の生えたようなレベルのツールを作るためにAccess採用。作っていくうえでオブジェクトが増えすぎて煩雑になってきたので自戒の意味も込めてAccessを使う上での整理ポイントについて個人的な考え方をまとめておきます。

なお、ちゃんとしたシステムであれば、画面遷移図やら各種オブジェクトの一覧、設計書なども作るでしょうし、各種命名規約もきちんとしていると思いますので、今回のケースはそんなきっちりしないで「ざっと」作るときにでも注意しておいた方がいいですよ。というレベルの情報です。

【登場人物】
Access データベースファイル
フォーム、レポート、テーブル、VBAプログラム、マクロ

【これをやっておけば何とかなる】
命名はきちんとね。

【整理せずに進めて困る可能性がある事例(やらかしたこと含め)】
・テーブルの分類が不明
 マスタなのか、トランザクションなのか、ワークなのか
・フォームの用途が不明
 入力フォームなのか、処理フォームなのか、サブなのか
・レポートの呼び出し元が不明
 単体で呼び出せるが
・活きているオブジェクトなのか、試作なのか不明
・そもそもソース管理が

【これだけはやっておこう】

テーブル

接頭語くらいはつけましょう。必ず「作るときに実施」
後で変えてもAccessが良きに計らってリファクタしてくれるようですが、してくれない箇所もあります。(ソースへの記載は当然ながら変えてくれません)

フォーム

ある程度のカテゴライズは事前にしておきましょう。
考えられるカテゴリとしては
メニュー:画面遷移だけするもの
入力フォーム:データの登録、修正するもの
サブフォーム:入力フォームの中に組み込むもの
サブ画面:入力フォームのサブ機能をもつもの、処理指示など
個人的にはいわゆる「接頭語」と連番でまとまるのが良いと考えてます。

例) xxxxはわかりやすい日本語名
メニュー:FM連番xxxxxxx
入力:FI連番xxxxxx
サブフォーム:FI連番SUB連番xxxxxx
サブ画面:FS連番xxxxx

クエリ

作成する数も多いのでこれが一番散らかります。
【決めごと】
画面、レポートなどのオブジェクトに対応するものは同じ接頭語をつける。その後に詳細用途
例)
FI連番SxxxxxxForm
FI連番Sxxxxxxcboxxx ※セレクトボックス
FI連番SxxxxxxListxxx
FI連番Ixxxxxxx (Insertクエリとか)
FI連番SxxxxxxXXXXQuery

長くなっても、用途がわかった方が良い

共通はCOMxxxとかでいいんじゃないかな。
間違っても、日本語名だけではやらないこと。絶対にあとでわからなくなります。

クエリのネスト
クエリでクエリを参照することはあると思いますが、その時に命名をどうするかは悩ましい。私の場合には1処理でネストする場合のみSub1,Sub2とかで命名します。
既にあるフォームで作成しているクエリを参照したい場合、面倒であっても
作成済みクエリを直接参照するのではなく、新規クエリで作成済みクエリを参照するようにしています。

レポート

ID命名と、メインかサブかがわかればよいのではないでしょうか。
フォームから呼ぶのであればフォームと同じ連番をつけておけばOK

マクロ

個人的にはあまりなじみがありませんが、連番が合っていれば間違えないかと。

VBA

いわゆる個別処理か、共通処理かでモジュールは分けると思いますので
あとは一般的なコーディング規約でいいのではと思います。

まとめ

だらだらと列挙しましたが、結局のところ「命名」に尽きると思っています。
後で見た時、またはほかの人が見た時に相関性がわかるのが重要ですね。

余談

私の場合、ある程度作り込んだ後はデータとプログラムのファイルを分けてます。
プログラムのファイルからデータのファイルへリンクを張ることで実現。
プログラム改修などの際にはプログラムファイルだけを更新すればよいため利便性が高いです。

2019年5月22日水曜日

【注意喚起】佐川急便を騙った迷惑メールにご注意

佐川急便の不在通知を偽装した不正サイトへの誘導を受け取ったので、注意喚起のため記事にしておきます。

まとめ

あやしい情報を受け取ったら、「無視する」「ネットで調べる」「進む場合セキュリティに十分注意する」

#検索用キーワード 090-7447-6454 bt-ar.top 佐川急便 貨物追跡サービス apple.varifidogione.com

ことの経緯

普通に、社用の電話のSMSにメッセージが届きました。 ↓こんなの

bit.ly 自体は短縮アドレスなのでこの時点で怪しいことに気付くのは難しい。
携帯の番号をネットで検索しても、特に怪しい情報は見当たらない。

念のためスマホからのアクセスは警戒して、パソコンからアクセス(当然シークレットモードにして)。すると・・・


なんだ、佐川さんじゃないですか(この時点でドメインが怪しかったのに気づかずスルー)



ページを進めて確認してみると、アプリのインストール手順を教えてくれているんですね
提供元不明のアプリを許可せよ。と。まぁ最近はちょくちょくあるケースですね




さらに進む。貨物追跡サービスアプリか・・・。要らないなぁ



マニュアルはご丁寧。ん~。まぁ関係ないかな。必要あれば電話来るだろうし


っというわけで、スマホでも見てみるか。。。

ここまでで怪しかったこと

いくつかございます。間違え探しは後半にて


スマホでリンククリックしたら怒られました。(やっぱりそっち系だったか)

このケースの注意喚起は、ここで止まればまだ問題なく終えられる可能性があります。
この時点でアプリを強制終了。
警告画面の裏側には先ほど見ていた佐川急便のサイトらしきものが見えます。

その後色々調べてみた

この、apple.verifidogione.com というドメインも、謎のものでした。
この迷惑メールの正体を少しでも調べてみようと、PCサイトを再度確認




ドメイン登録を確認(bt-ar.top)


Domain Name: bt-ar.top
Registry Domain ID: D20190520G10001G_09522758-top
Registrar WHOIS Server: whois.bizcn.com
Registrar URL: http://www.bizcn.com
Updated Date: 2019-05-20T11:40:05Z
Creation Date: 2019-05-20T10:53:39Z
Registry Expiry Date: 2020-05-20T10:53:39Z
Registrar: BIZCN COM  INC
Registrar IANA ID: 471
Registrar Abuse Contact Email: abuse@bizcn.com
Registrar Abuse Contact Phone: +86.5922577888
Domain Status: clientTransferProhibited https://icann.org/epp#clientTransferProhibited
Domain Status: addPeriod https://icann.org/epp#addPeriod
Registry Registrant ID: 
Registrant Name: 
Registrant Organization: Sun Xiao Li


おもいっきし中国だし、5/20取得だしさらには



お知らせが2018-07とか、2018-08 だし

佐川急便さんのサイトを丸々コピーして構築したのでしょうね。

自分は半分引っ掛かりましたが、最近はこんなケースも出ているようです。
皆様お気をつけください。

追伸

佐川急便さんではすでに注意喚起をサイトへ掲示していました(クリックすると別ウインドウが開きます)
佐川急便を装った迷惑メールにご注意ください

2019年2月20日水曜日

MSSQLのDBが破損した模様

何かの理由で利用中パッケージソフトで新規登録ができなくなった模様。
※パッケージの問題ではない。と先にお伝えしておきます。

原因がDBだったので、問題を調べて、対処、処置まで完了したのでメモしておきます。

事の経緯

データを新規登録できなくなった。と連絡を受けました。
よく聞くと、登録ボタンを押すと「強制終了してしまう」との事
エラー内容を見る限りたぶんDB周りだろうな。と思い調査を開始しました。
ひとまず見つけたのはWindowsのアプリケーションログ。
「インデックスが壊れている可能性があります。DBCC CHECKDB を実行してください。」と出ていました

MSSQLのチェックツール


詳しい解説は以下サイトを参考としました。
https://www.ipentec.com/document/sql-server-db-repair-and-validation-with-dbcc-command
参考にしながら処置を実施

DBCC CHECKDB
GO

チェック結果を確認


メッセージ 8935、レベル 16、状態 1、行 1
テーブル エラー: オブジェクト ID 1413580074、インデックス ID 1、パーティション ID 72057594063093760、アロケーション ユニット ID 72057594068664320 (型 In-row data)。ページ (1:503) の前ページへのリンク (1:1503) は、親 (1:377)、スロット 31 がこのページに対して想定している前ページ (1:3646) と一致しません。
メッセージ 8978、レベル 16、状態 1、行 1
テーブル エラー: オブジェクト ID 1413580074、インデックス ID 1、パーティション ID 72057594063093760、アロケーション ユニット ID 72057594068664320 (型 In-row data)。ページ (1:503) に前ページ (1:1503) からの参照がありません。チェーン リンケージに問題がある可能性があります。
メッセージ 8935、レベル 16、状態 1、行 1
テーブル エラー: オブジェクト ID 1413580074、インデックス ID 1、パーティション ID 72057594063093760、アロケーション ユニット ID 72057594068664320 (型 In-row data)。ページ (1:1503) の前ページへのリンク (1:3646) は、親 (1:377)、スロット 84 がこのページに対して想定している前ページ (1:1251) と一致しません。
メッセージ 8936、レベル 16、状態 1、行 1
テーブル エラー: オブジェクト ID 1413580074、インデックス ID 1、パーティション ID 72057594063093760、アロケーション ユニット ID 72057594068664320 (型 In-row data)。B-Tree チェーン リンケージが一致しません。(1:1251)->next = (1:1503)、(1:1503)->Prev = (1:3646)。
メッセージ 8979、レベル 16、状態 1、行 1
テーブル エラー: オブジェクト ID 1413580074、インデックス ID 1、パーティション ID 72057594063093760、アロケーション ユニット ID 72057594068664320 (型 In-row data)。ページ (1:1752) に、親 (不明) ノードと前 (ページ (1:376)) ノードからの参照がありません。システム カタログのルート エントリが不適切である可能性があります。
メッセージ 8934、レベル 16、状態 1、行 1
テーブル エラー: オブジェクト ID 1413580074、インデックス ID 1、パーティション ID 72057594063093760、アロケーション ユニット ID 72057594068664320 (型 In-row data)。ページ (1:3645) (レベル 0) のキーの最高値が、次のページ (1:1753) の親 (0:1)、スロット 0 のキーの最低値より大きくなっています。
メッセージ 8977、レベル 16、状態 1、行 1
テーブル エラー: オブジェクト ID 1413580074、インデックス ID 1、パーティション ID 72057594063093760、アロケーション ユニット ID 72057594068664320 (型 In-row data)。ページ (1:1753) の親ノードが見つかりませんでした。
'table_xxxxxxxxx' の DBCC 結果。
オブジェクト "table_xxxxxxxxx" の 95 ページには 784 行あります。
CHECKDB により、テーブル 'table_xxxxxxxxx' (オブジェクト ID 1413580074) に 0 個のアロケーション エラーと 7 個の一貫性エラーが見つかりました。

エラー出ました。(table_xxxxxxxxの部分は実テーブル名を置き換えて表示しています)

参考サイトに従ってリペアを実施



ALTER DATABASE '対象のデータベース名' SET SINGLE_USER
GO
DBCC CHECKDB('対象のデータベース名','REPAIR_REBUILD')
GO
ALTER DATABASE "対象のデータベース名" SET MULTI_USER
GO
ALTER DATABASE "対象のデータベース名" SET RECOVERY FULL
GO


再テスト 


DBCC CHECKDB
GO


変わらず。と。

インデックスの違反なんだろうから、インデックスを再構築してしまえとも
思うんだけどもテーブル定義を見てみても、Primaryしかない
なんだかなぁ。なので、以下にチャレンジ

無理やりテーブルを再作成してみる

ざっくり言うと、別のテーブルへ移して、リネームして戻してしまえ。

1.エラーが出ているテーブル(A)をselect into で別テーブル(B)へ
2.テーブル(A)をリネーム
3.テーブル(B)をテーブル(A)へリネーム

これでパッケージソフト上でのエラーは出なくなりました。

修復できたようなので後片付け

おそらくですが、テーブル(A)のPrimaryが壊れたのだろうと推測。
→後の処置で確かに存在しえないデータが複数selectできたのでそれ。
クリアできたので、改めて以下処置を実施

ざっくり言うと、定義は生かして、今のを退避して、テーブル再構築、データ再投入

1.上記のテーブル(A)からDDLを取得
2.上記テーブル(A)をリネームし、Primaryを削除 
→これをしないとPrimaryの名称が被ったため
3.取得したDDLにてテーブルを作成
4.上記2)でリネームしておいたデータから、3)で作成したテーブルへデータを流す

作業を終えてから

DBCC CHECKDB
GO
でエラーが消えたことを確認しました

2019年2月14日木曜日

【非IT】楽天トラベル利用時の領収書 (2ヶ月以内とかじゃないよ)

これ、私も勘違いしてました。

利用後、2ヶ月過ぎたら領収書が出せなくなると思ってました。

楽天トラベルではWeb上で領収書を出力できるのですが、なぜか、過去の勘違い記憶が
残っていて、2ヶ月を過ぎたら出せなくなると思ってました。
(というか、過去の予約を検索すると「過去2ヶ月間において、国内宿泊予約はありません。」と出るので、ダメだと思ってた)

ただ、今回あれこれ調べていくうえで、2年以上前であっても出せることを確認。

結果

マイページへ移動して
「キャンセル済み・過去の予約」を選択
「過去2ヶ月間において、国内宿泊予約はありません。」と出てもくじけず、
表示期間: となっている個所を「201x年度」と変更して、「変更」ボタンを押す

これで、古い予約履歴も、「領収書印刷」ボタンも出てきます。

詳しい手順は紹介しませんが、ネットでは「2ヶ月過ぎると出せない」という記事もちらほらあったため、ご参考まで。

2019年2月6日水曜日

ssh.netで依存関係? (c# ,VS2013)

管理するサーバも増え、手作業より自動化だ!ということで、c#アプリでsshの実装をすることにしました。

過去記事にもありますが、ssh接続による作業の自動化手段として
1)TeraTerm + マクロによる実行
2)RLoginを利用した同時動作

は候補になるのですが、今後の拡張性や、各ソフトの永続性なども考慮した結果、手作りしてしまおう。と。

今回、VisualStudio2013環境で、ssh.netを利用しようとしてハマったことについて残しておきます。

まとめ (試した限り)

netSSHを利用した開発にはVisualStudio2013での開発じゃなくて、2015を使ったほうが簡単

やった手順

まずは何も考えずに進めてみる

新規でc#プロジェクトを作成、「nuget」にてssh.netのインストールを試みます。


SshNet.Security.Cryptographyの依存関係・・・

となったので、めげずに、パッケージマネージャコンソールから
PM>Install-Package SshNet.Security.Cryptography -Version 1.3.0

Install-Package : 'SshNet.Security.Cryptography' にはすでに 'System.IO' に対して定義された依存関係があります。

やっぱ同じか。。。ということでちゃんと依存関係の調査

ライブラリが足らない・・・



https://www.nuget.org/packages/SshNet.Security.Cryptography/1.3.0
NETStandardが必要なのね。ってか、このライブラリ使うの初めて。
てなことで情報収集。

フレームワークも足らない

https://dotnet.microsoft.com/download/visual-studio-sdks?utm_source=getdotnetsdk&utm_medium=referral


frameworkの4.6が必要。との事でインストール
プロジェクトへの適用が完了しました。

これでも足らないようで .net Core 1のSDKをインストール
これでも足らない・・・

VisualStudio2015で試してみよう

「2013の新規プロジェクト選択画面」

「2015の新規プロジェクト選択画面」


2015の新規プロジェクトには".net core"の選択肢がある・・・・
今回はこっちで行くことにしました

VisualStudio2015で進めてみた (結果)

PackageManagerコンソールでnetsshをインストール、問題なく進みました。
これでアプリが作れそうです

2018年12月4日火曜日

Oracle破損

※※ この情報は tipではございません ※※

とあるA社さんの仕事を委託していて、開発環境もA社さんにあるため必要に応じA社さんの環境へ接続、作業をしていたりするのですが、

??Oracle起動してないよ?
??というか、計画外シャットダウンの画面出てるよ(Windows2008server)

となり、事が深刻だったので作業備忘録メモ


前置き長くなりました。もー何で?な心境なので文体粗いです。
追伸:Oracle 10gです

【事象】


SQL DeveloperでOracleに接続しようとしたら「ORA-01033:Oracleの初期化またはシャットダウン中です」が出て接続できない

【処置概略】

・まー、今までもあったよね。startup mount;ALTER DATABASE OPEN; でつながるよね。
・おっと、mountされてるみたい。shutdown immediateしてからだね。
・え、エラー出たし。ORA- でぐぐって対処するか。
・色々コマンド出てきて打ち込むけども、なんか治らんなぁ
・余計ひどくなった。やっぱDBAでもないのにやるもんじゃないね。
・Database作り直しちゃおう。
・Configuration Assistantで再作成。っと。
・壊れたのはどうせ使えないので削除。
・ユーザー作って、権限付与して、開発用データのdmpも入れて。と。
・listener設定してなかった。作成したdbへ変更。っと。
・よしよし。データも見れるし、まぁいいか。開発環境だし。


【処置結果】

・何もtips残りませんでした。
 ひとつ大事なことは「思いたったからと言ってすぐやるな」
 OracleはさすがOracle。あちこちにリカバリログを持っていて(いるようで)、手順さえ間違わなければログから復旧できる。(はず)ログもちゃんとバックアップしておく必要あるけどね。
 適当にログ指定してリカバリしようなんて、傷を深くしただけでした。

【余談】

ファイル壊れてんじゃんか(笑) zipファイルすら破損してるよ。ディスク障害でもあったんじゃない?ま、開発環境(hyper-v)だし、壊れてもなんとかなるからいっか。

【使ったコマンドのメモ】

※sqlplus /nologでログイン
※sys as syadba

recover database until cancel;


【恥を忍んで途中からの全log】


SQL> recover database until cancel;


ORA-00279: 変更217138326(09/30/2018 12:00:48で生成)にはスレッド1が必要です
ORA-00289:検討すべきログ・ファイル:D:\ORACLE\PRODUCT\10.2.0\DB_1\RDBMS\ARC02244_0830209207.001
ORA-00280: 変更217138326(スレッド1)は順序番号2244に存在します。
ログの指定: {=suggested | filename | AUTO | CANCEL}
D:\ORADATA\ORCL\REDO03.LOG
ORA-00283: エラーによってリカバリ・セッションは取り消されました。
ORA-10562: Error occurred while applying redo to data block (file# 3, block#
21623)ORA-10564: tablespace SYSAUX
ORA-01110: データファイル3: 'D:\ORADATA\ORCL\SYSAUX01.DBF'
ORA-10560: block type '0'
ORA-00600: 内部エラー・コード、引数: [4552],[1],[0],[],[],[],[],[]
ORA-01112: メディア・リカバリが開始されていません
SQL> recover database until cancel;
ORA-00279: 変更217138326(09/30/2018 12:00:48で生成)にはスレッド1が必要です
ORA-00289:
検討すべきログ・ファイル:D:\ORACLE\PRODUCT\10.2.0\DB_1\RDBMS\ARC02244_0830209207.001
ORA-00280: 変更217138326(スレッド1)は順序番号2244に存在します。
ログの指定: {=suggested | filename | AUTO | CANCEL}
ORA-00308:
アーカイブ・ログD:\ORACLE\PRODUCT\10.2.0\DB_1\RDBMS\ARC02244_0830209207.001をオープンできません。
ORA-27041: ファイルをオープンできません。
OSD-04002: ファイルをオープンできません
O/S-Error: (OS 2) 指定されたファイルが見つかりません。
ORA-01547: 警告: RECOVERは成功しましたがOPEN
RESETLOGSが次のエラーを受け取りました。
ORA-01194: ファイル1は一貫した状態にするためにさらにリカバリが必要です。
ORA-01110: データファイル1: 'D:\ORADATA\ORCL\SYSTEM01.DBF'
SQL> recover database until cancel;
ORA-00279: 変更217138326(09/30/2018 12:00:48で生成)にはスレッド1が必要です
ORA-00289:検討すべきログ・ファイル:D:\ORACLE\PRODUCT\10.2.0\DB_1\RDBMS\ARC02244_0830209207.001
ORA-00280: 変更217138326(スレッド1)は順序番号2244に存在します。
ログの指定: {=suggested | filename | AUTO | CANCEL}
REDO2.LOG
ORA-00308: アーカイブ・ログREDO2.LOGをオープンできません。
ORA-27041: ファイルをオープンできません。
OSD-04002: ファイルをオープンできません
O/S-Error: (OS 2) 指定されたファイルが見つかりません。
ログの指定: {=suggested | filename | AUTO | CANCEL}
D:\ORADATA\ORCL\REDO02.LOG
ORA-00310:アーカイブ・ログは順序番号2243を含んでいますが、順序番号2244が必要です。
ORA-00334: アーカイブ・ログ: 'D:\ORADATA\ORCL\REDO02.LOG'
ORA-01547: 警告: RECOVERは成功しましたがOPEN
RESETLOGSが次のエラーを受け取りました。
ORA-01194: ファイル1は一貫した状態にするためにさらにリカバリが必要です。
ORA-01110: データファイル1: 'D:\ORADATA\ORCL\SYSTEM01.DBF'
SQL> recover database automatic
ORA-00905: キーワードがありません。
SQL> recover automatic database;
ORA-00283: エラーによってリカバリ・セッションは取り消されました。
ORA-10562: Error occurred while applying redo to data block (file# 3, block#
21623)
ORA-10564: tablespace SYSAUX
ORA-01110: データファイル3: 'D:\ORADATA\ORCL\SYSAUX01.DBF'
ORA-10560: block type '0'
ORA-00600: 内部エラー・コード、引数: [4552],[1],[0],[],[],[],[],[]
SQL> recover tablespace user;
ORA-00931: 識別子がありません。
SQL> recover tablespace users;
ORA-00283: エラーによってリカバリ・セッションは取り消されました。
ORA-00368: REDOログ・ブロックでチェックサム・エラーが発生しました
ORA-00353: ブロック85960(変更217167197、時間10/01/2018
01:20:14)付近のログが破損しています
ORA-00312: オンライン・ログ3 スレッド1: 'D:\ORADATA\ORCL\REDO03.LOG'
SQL> select * from V$RECOVER_FILE;
レコードが選択されませんでした。
SQL>
SQL> recover database until cancel;
ORA-00279: 変更217138326(09/30/2018 12:00:48で生成)にはスレッド1が必要です
ORA-00289:
検討すべきログ・ファイル:D:\ORACLE\PRODUCT\10.2.0\DB_1\RDBMS\ARC02244_0830209207.001
ORA-00280: 変更217138326(スレッド1)は順序番号2244に存在します。
ログの指定: {=suggested | filename | AUTO | CANCEL}
ORA-00308:
アーカイブ・ログD:\ORACLE\PRODUCT\10.2.0\DB_1\RDBMS\ARC02244_0830209207.001をオープンできません。
ORA-27041: ファイルをオープンできません。
OSD-04002: ファイルをオープンできません
O/S-Error: (OS 2) 指定されたファイルが見つかりません。
ORA-01547: 警告: RECOVERは成功しましたがOPEN
RESETLOGSが次のエラーを受け取りました。
ORA-01194: ファイル1は一貫した状態にするためにさらにリカバリが必要です。
ORA-01110: データファイル1: 'D:\ORADATA\ORCL\SYSTEM01.DBF'
SQL>
SQL> recover database until cancel;
ORA-00279: 変更217138326(09/30/2018 12:00:48で生成)にはスレッド1が必要です
ORA-00289:検討すべきログ・ファイル:D:\ORACLE\PRODUCT\10.2.0\DB_1\RDBMS\ARC02244_0830209207.001
ORA-00280: 変更217138326(スレッド1)は順序番号2244に存在します。
ログの指定: {=suggested | filename | AUTO | CANCEL}
D:\oradata\orcl\REDO1.log
ORA-00308: アーカイブ・ログD:\oradata\orcl\REDO1.logをオープンできません。
ORA-27041: ファイルをオープンできません。
OSD-04002: ファイルをオープンできません
O/S-Error: (OS 2) 指定されたファイルが見つかりません。
ログの指定: {=suggested | filename | AUTO | CANCEL}
D:\oradata\orcl\REDO01.log
ORA-00310:
アーカイブ・ログは順序番号2242を含んでいますが、順序番号2244が必要です。
ORA-00334: アーカイブ・ログ: 'D:\ORADATA\ORCL\REDO01.LOG'
ORA-01547: 警告: RECOVERは成功しましたがOPEN
RESETLOGSが次のエラーを受け取りました。
ORA-01194: ファイル1は一貫した状態にするためにさらにリカバリが必要です。
ORA-01110: データファイル1: 'D:\ORADATA\ORCL\SYSTEM01.DBF'
SQL> recover database until cancel;
ORA-00279: 変更217138326(09/30/2018 12:00:48で生成)にはスレッド1が必要です
ORA-00289:
検討すべきログ・ファイル:D:\ORACLE\PRODUCT\10.2.0\DB_1\RDBMS\ARC02244_0830209207
.001
ORA-00280: 変更217138326(スレッド1)は順序番号2244に存在します。
ログの指定: {=suggested | filename | AUTO | CANCEL}
D:\oradata\orcl\REDO02.log
ORA-00310:
アーカイブ・ログは順序番号2243を含んでいますが、順序番号2244が必要です。
ORA-00334: アーカイブ・ログ: 'D:\ORADATA\ORCL\REDO02.LOG'
ORA-01547: 警告: RECOVERは成功しましたがOPEN
RESETLOGSが次のエラーを受け取りました。
ORA-01194: ファイル1は一貫した状態にするためにさらにリカバリが必要です。
ORA-01110: データファイル1: 'D:\ORADATA\ORCL\SYSTEM01.DBF'
SQL> recover database until cancel;
ORA-00279: 変更217138326(09/30/2018 12:00:48で生成)にはスレッド1が必要です
ORA-00289:
検討すべきログ・ファイル:D:\ORACLE\PRODUCT\10.2.0\DB_1\RDBMS\ARC02244_0830209207
.001
ORA-00280: 変更217138326(スレッド1)は順序番号2244に存在します。
ログの指定: {=suggested | filename | AUTO | CANCEL}
D:\oradata\orcl\REDO03.log
ORA-00283: エラーによってリカバリ・セッションは取り消されました。
ORA-10562: Error occurred while applying redo to data block (file# 3, block#
21623)
ORA-10564: tablespace SYSAUX
ORA-01110: データファイル3: 'D:\ORADATA\ORCL\SYSAUX01.DBF'
ORA-10560: block type '0'
ORA-00600: 内部エラー・コード、引数: [4552],[1],[0],[],[],[],[],[]
ORA-01112: メディア・リカバリが開始されていません
SQL> recover database using backup controlfile until cancel;
ORA-00279: 変更217138326(09/30/2018 12:00:48で生成)にはスレッド1が必要です
ORA-00289:
検討すべきログ・ファイル:D:\ORACLE\PRODUCT\10.2.0\DB_1\RDBMS\ARC02244_0830209207
.001
ORA-00280: 変更217138326(スレッド1)は順序番号2244に存在します。
ログの指定: {=suggested | filename | AUTO | CANCEL}
D:\oradata\orcl\REDO01.log
ORA-00310:
アーカイブ・ログは順序番号2242を含んでいますが、順序番号2244が必要です。
ORA-00334: アーカイブ・ログ: 'D:\ORADATA\ORCL\REDO01.LOG'
ORA-01547: 警告: RECOVERは成功しましたがOPEN
RESETLOGSが次のエラーを受け取りました。
ORA-01194: ファイル1は一貫した状態にするためにさらにリカバリが必要です。
ORA-01110: データファイル1: 'D:\ORADATA\ORCL\SYSTEM01.DBF'
SQL> recover database using backup controlfile until cancel;
ORA-00279: 変更217138326(09/30/2018 12:00:48で生成)にはスレッド1が必要です
ORA-00289:
検討すべきログ・ファイル:D:\ORACLE\PRODUCT\10.2.0\DB_1\RDBMS\ARC02244_0830209207
.001
ORA-00280: 変更217138326(スレッド1)は順序番号2244に存在します。
ログの指定: {=suggested | filename | AUTO | CANCEL}
D:\oradata\orcl\REDO02.log
ORA-00310:
アーカイブ・ログは順序番号2243を含んでいますが、順序番号2244が必要です。
ORA-00334: アーカイブ・ログ: 'D:\ORADATA\ORCL\REDO02.LOG'
ORA-01547: 警告: RECOVERは成功しましたがOPEN
RESETLOGSが次のエラーを受け取りました。
ORA-01194: ファイル1は一貫した状態にするためにさらにリカバリが必要です。
ORA-01110: データファイル1: 'D:\ORADATA\ORCL\SYSTEM01.DBF'
SQL> D:\oradata\orcl\REDO02.log
SP2-0734: "D:\oradata..."で開始するコマンドが不明です - 残りの行は無視されました
。
SQL> recover database using backup controlfile until cancel;
ORA-00279: 変更217138326(09/30/2018 12:00:48で生成)にはスレッド1が必要です
ORA-00289:
検討すべきログ・ファイル:D:\ORACLE\PRODUCT\10.2.0\DB_1\RDBMS\ARC02244_0830209207
.001
ORA-00280: 変更217138326(スレッド1)は順序番号2244に存在します。
ログの指定: {=suggested | filename | AUTO | CANCEL}
D:\oradata\orcl\REDO03.log
ORA-00283: エラーによってリカバリ・セッションは取り消されました。
ORA-10562: Error occurred while applying redo to data block (file# 3, block#
21623)
ORA-10564: tablespace SYSAUX
ORA-01110: データファイル3: 'D:\ORADATA\ORCL\SYSAUX01.DBF'
ORA-10560: block type '0'
ORA-00600: 内部エラー・コード、引数: [4552],[1],[0],[],[],[],[],[]
ORA-01112: メディア・リカバリが開始されていません
SQL> SELECT * FROM V$RECOVER_FILE;
レコードが選択されませんでした。
SQL> COL FILE# FORMAT 999
SQL> COL FILE_NAME FORMAT A36
SQL> COL TABLE_SPACE_NAME FORMAT A10
SQL> COL STATUS FORMAT A7
SQL> COL ERROR FORMAT A16
SQL> SELECT RF.FILE#, DF.NAME FILE_NAME, TS.NAME TABLE_SPACE_NAME, DF.STATUS, RF
.ERROR, RF.CHANGE#, RF.TIME
  2    FROM V$RECOVER_FILE RF, V$DATAFILE DF, V$TABLESPACE TS
  3    WHERE DF.FILE# = RF.FILE#
  4      AND TS.TS# = DF.TS#
  5  /
レコードが選択されませんでした。
SQL>
SQL>

2018年11月16日金曜日

レコード単位の計算(ireports)

なんてことない処理のはずがはまったので備忘録

要は、明細のA,B,Cの項目を合算して、Dに出したいというだけ。
手段はこれ以外あると思いますが、デザイナ環境と実行環境で動作が異なったため若干はまりました。
結果を残しておきます。

実装
KINGAKU_A,KINGAKU_B,KINGAKU_Cの計算をVariableで定義
表示フィールドにVariable名を設定


<variable class="java.lang.Double" incrementtype="Column" name="V_ROW_KINGAKU_GOUKEI" resettype="Column">
    <variableexpression>
    &lt;![CDATA[($F{KINGAKU_A}.equals(null)?0:new Double($F{KINGAKU_A}))+
    ($F{KINGAKU_B}.equals(null)?0:new Double($F{KINGAKU_B}))+
    ($F{KINGAKU_C}.equals(null) ? 0 : new Double($F{KINGAKU_C}))]]&gt;
</variableexpression>
</variable>

<textfield isblankwhennull="true" pattern="#,##0">
    <reportelement height="9" printwhengroupchanges="GroupName" width="48" x="695" y="0">
    <box leftpadding="3" rightpadding="3">
    <textelement markup="none" textalignment="Right" verticalalignment="Middle">
        <span fontname="IPA明朝">
    </span></textelement>
    <textfieldexpression class="java.lang.Double">&lt;![CDATA[$V{V_ROW_KINGAKU_GOUKEI}]]&gt;</textfieldexpression>
</box></reportelement></textfield>


2018年11月14日水曜日

Accessにてレコード超過によりデータが作成できなかった件 (未完結)

原因究明できていないため、参考までとしてください。

Accessの2GB制限と実際に投入できるデータサイズに対する実証および考察です。

ことの経緯


社内SE作業で、10,000件×10,000件の組み合わせデータを作成する必要があり、Excelではできず、Accessに頼ることにしました。

Excelにある2つのシート(各10,000件)をAccessへインポート
その後、クエリで2つのテーブルをCROSS JOINで新テーブルへINTO(1億件INSERT)

すると、謎のエラー。

accdbファイルを見ると、2GBを超えていました。Accessは2GBまでしかサポートしていないため、エラーとなったようです。

「ま~データ多いからな~」と思いつつ、今はMySQLへリンクテーブル張ってそこへ流し込んでいる段階なのですが、時間があるのでこの記事を書く事にしました。

2GBって何バイト?


改めて計算したところ、20億バイト。


これがテーブル定義なので、20Byte × 1億 件 でざっくり計算しても超えてしまいますね。

なので、母数を減らすことにしました。

10,000件 × 2,500件

これであれば、500MBに収まる試算です

でも同じエラーが出るよ???

レコードの容量計算を行うための情報収集。
ディスクのブロックサイズによって利用されるディスク領域が異なる。と。NTFSの情報を参照します。

fsutil fsinfo ntfsinfo c:

4096と出ました。つまり、4KB
今回の直接の原因にはならなそうです。

ここまでで一旦まとめ

今回の作業の目的はマトリックスデータを作って利用することであり、Accessを使ってどうこうという事ではなかったため、これ以上の深追いはしないことにしました。

考えられることとしては
1)Access内部で一時領域にディスクを利用していてそれでオーバーする
2)テーブルのインデックスなど、付加情報も容量見積に入れる必要あり
3)SELECT INTO (つまり手抜き)なので、結果作成されるテーブルのフィールド型が想定と違う? →その後データ件数を減らして実証しましたが、想定通り、元のテーブルの型を引き継いでいました

あたりが考えられますが、その詳細については今後必要に応じて調べていこうと思います