小学校の「プログラミング教育の必修化」この言葉をつい最近まで勘違いしていました。

ネットやパソコン教室のチラシでもプログラミング方法について

いろいろな内容のものは目にしてましたので、てっきり新しく科目が

できるものだと思っていました。

実際には算数や理科等、今の教科科目の中にプログラミング（考え方）を取り入れていこうという

趣旨のもので単純に「プログラムを書く」というものではなさそうです。

既に授業での活用も行っている学校もある様で、レゴの振り子ロボットを理科の授業で

使用し、プログラミングをしてロボットの動作を実験結果としてグループ発表するという

事を行ったそうです。

実験の計画を立て、プログラミングを使用した実験を行い、その結果を発表し合う

ということでアクティブラーニング中にプログラミングを組み込むという事を実施したそうです。

各教科の授業計画の中にアクティブラーニングの活用を考えかつ、更にはプログラミングの

組み込みも考慮しないといけないとは！・・・・・小学校の先生って大変ですね。

我が娘も小学２年生ですが、担任の先生には頭が下がる思いです。

Microsoft 製品のOS(Windows Server 2008)のサポート期限が
2020年1月14日と迫っており、最近は各学校様から新しいサーバー
に関するお問い合わせが多くなっております。

そしてサーバーの他にも、各部署やご家庭でよくご使用されている
「Windows 7」もサポート期限が2020年1月14日となっております。

既に新しいサーバー等への移行がお済みの学校様も増えてきておりますので、
もし、新しいサーバー等への移行等をご検討されていらっしゃるようでしたら、
いつでもお気軽にご一報を頂ければと思います。

OracleからPostgreSQLへのデータ移行 – 1.型指定 であらかたデータ移行はできましたが、次に問題になったのがバイナリデータでした。

最初にORA-24345エラーが発生。これについては ORA-24345 が発生するならこのディレクティブを1にしろ、と書かれているLONGTRUNCOK 1を設定することで解消しました。オンラインドキュメントではLONGTRUNKOK になっていますが、configファイルでは LONGTRUNCOK です。

そしてblobカラムに格納されていたデータが、一見移行できているように見えて途中で途切れているなどの問題が発生しました。

LONGREADLENに十分なサイズを指定することで解消しますが、余り大きくすると今度はOutOfMemoryが発生してしまいます。

OutOfMemoryを防ぐにはDATA_LIMITを小さくすれば良いのですが、そうするとデータ移行に時間がかかるようになります。

これらを踏まえて、1レコードあたりのデータサイズが大きなテーブルとそれ以外のテーブルについて出力を分けることにしました。

1レコードあたりのデータサイズの大きなテーブルをカンマ区切りでリストアップ。configファイルを二つ作り、一方には先のテーブル名をEXCLUDE に指定。もう一方には ALLOW に指定します。

ALLOW に指定した方のconfigではLONGREADLENを大きくとり、DATA_LIMITを小さくします。

これで通常のデータについては移行を手早く、サイズの大きなデータについてもエラーを回避し確実に移行できるようになりました。

弊社でもOracleからPostgreSQLへの移行作業を行うことがあり、データ移行には定番でしょうが ora2pg を使用しています。

基本的にドキュメントのとおりに実行知ればデータ移行が完了してしまう優れものですが、いくつかハマったポイントもあるので書いてみたいと思います。

ちなみにLinuxで動作させる方が多いかと思いますが、ActivePerl をインストールすればWindowsでも問題もなく動作します。

ActivePerlのインストール後にパッケージマネージャでdmakeをインストールし、ora2pgのソースコードを適当なフォルダに展開、コマンドプロンプトからperl .\Makefile.pl して dmake installで終わりでした。

Oracleクライアントのインストールの手間を考えるとWindows環境で実行する方が簡単かもしれません。

さてora2pgでのデータ移行ですが、とりあえず接続先情報以外はconfigをそのまま使用して移行してみたのですが自動で行われた型指定とプログラムの動作に問題が生じました。

例えば、NUMBER(4,0)等がsmallintで移行されてしまいます。これが.NET Framework2の頃に作成された、SELECT結果を DataTable に格納、そのまま DataGridView にバインドしているようなプログラムで問題になりました。intを想定していたものが PostgreSQL+smallintだとshortになっており、DataErrorイベントが発生することに。

これをデータベース側で回避するとした場合、ora2pgのコンフィグファイルで変換する型を指定することになります。DATA_TYPE項目ですね。

Oracleの型:PostgreSQLの型, Oracleの型2:PostgreSQLの型2… のように指定するだけですが2つほどポイントが。

一つは、精度指定のカンマをバックスラッシュでエスケープすることです。これは公式ドキュメントのDATA_TYPEの項目にもしっかり書かれているのですが、読み飛ばしていたため、スクリプトで型変換リストを作成した際にハマってしまいました。

二つ目は、精度指定で小数点以下桁数が0の場合にはカンマ以降が不要という点です。公式ドキュメントの例に DATA_TYPE NUMBER(*\,0):bigint という記述があり、これを参考に NUMBER(4\, 0):integer と書いたのですが numeric(4) に変換されてしまいました。

最初、指定が反映されない理由分からず悩みましたが、実はNUMBER(4):integer のようにカンマ以降が不要でした。

数値データの取得後、プログラム上での扱いについては他にも小数点以下が全て0の場合に10 になるか 10.00 になるかといった問題も発生しました。これについては弊社ではプログラム側で対応しました。