JAWS DAYS 201803に行ってきました♪（ｖ＾＿＾）#jawsdays
JAWS DAYS 2018に参加してきましたのでレポートします。
開催日時：2018年3月10日（土）
場所：五反田
朝は準備が遅くなってしまって11時から参加となってしまったのですが、
参加した数セッションの中からピックアップしてご紹介したいと思います。
[AI/ML] AIの理解から始めるAI導入への戦略とAWS
point
・AIのモデルは計算式
・数値or数値で表現できるものしか扱えない
・AIの専門家だけではAIシステムは作れない
AIエンジニア、インフラ、DB、WEBエンジニア、データ収集の為のエンジニア、マーケータが必要
・目的ALで何を達成したいか？をはっきりさせる。
AIの技術サービスAWS
・API系
polly
Transcribe
Rekognition
Translate
Comprehend
・フラットフォーム系
Machene Learning
・コンサルタント系
ML Solutions Lab
最後に
・AIは労働不足を補ってくれる強力なパートナー
・AIと人間はお互いの不得意な部分をサポートできる関係
・AIについて正しく理解することが何より重要
ランチタイムセッション
シャケとブリという対話式のQ&Aボットを開発して業務改善を行っている。
このボットのおかげで２名しかいない情シスが大変助かっているそうです。
P3インスタンスではじめるDeep Learningと画像レコメンド
絵のタッチによるレコメンドを開発
1年前はビックデータ部には
自由に使えるGPUがなかった
オンブレ VS クラウド選定
・自由に使えるGPUが欲しい
・社内にAWSで困ったことがあれば聞ける環境
以上の理由でAWSを採用
まとめ
絵のタッチによるレコメンドの実現
AWSを活用したDL開発環境
モデルの学習と検証
LT
余興枠の清水さん
機械vs.人類
５分という短い発表の中に、自作機械でリバーシ対決見せてくれました。
会場も盛り上がって、とても面白かったです。いつも盛り上げてくれてありがとうございました。
その他LT
JAWS-UG沖縄からも安里さんが参戦。
来月開催予定のcrowd on the beachのご紹介。ビーチパーティ楽しみですね♪
個人的な感想
今回はAI、機械学習のセッションを中心に参加させていただいたのですが、
私の現在の業務では直接的には使用しておらず、どのセッションも聞きなれない単語ばかりで難しく感じたのですが、AIは
100%正解する万能機械ではないので、
間違いもあるということを理解し、その間違いを再度学習・検証して
お客様にも理解いただくことが大切。
AIは人間の仕事を奪うのではなく、労働不足を補ってくれる強力なパートナーである
という印象を受けました。
私はデータベースエンジニアなので今後ステップアップとしてAI（というか、データ分析など）少しづつ勉強して、いつかスピーカーできるよう頑張ります♪（ｖ＾＿＾）
謝辞
最後になりましたが、今回のJAWS DAYSスピーカー、運営、ボランティアの方々開催してくれて本当にありがとうございました。
#jawsdays
テーブルRENAMEからのテーブル新規作成で、テーブル再作成
元テーブルは一時的にバックアップを取っておき、
新テーブルはCREATE TABLEで作成する際の手順
①変更するテーブルの、PK名・外部キー名（自分が親テーブル、子テーブルどちらも）・INDEX名を漏れ無く調べる。
②テーブル名の変更
ALTER TABLE TABLE_NAME RENAME TO TABLE_NAME_BK;
③PK名の変更
ALTER TABLE TABLE_NAME_BK RENAME CONSTRAINT PK名 TO PK名_BK;
④外部キー名の変更
（自分が子テーブルとして他テーブルを参照している外部キー）
ALTER TABLE TABLE_NAME_BK RENAME CONSTRAINT FK名 TO FK名_BK;
⑤外部キーの削除
（自分が親テーブルとして他テーブルから参照されている外部キー）
ALTER TABLE REF_TABLE_NAME DROP CONSTRAINT FK名;
⑤INDEX名の変更
（名前付きPKを作成していた場合は、自動で名前付きINDEXが作成されているため、それも変更する）
ALTER INDEX INDEX名 RENAME TO INDEX名_BK;
⑥新定義テーブルの作成
CREATE TABLE TABLE_NAME(
~
CONSTRAINT PK名 PRIMARY KEY(COLUMN)
);
⑦外部キーの作成
（自分が親テーブルと子テーブルのどちらも作成）
ALTER TABLE TABLE_NAME ADD CONSTRAINT FKXXX
FOREIGN KEY (COLUMN) REFERENCES REF_TABLE_NAME(COLUMN);
⑧INDEXの作成
CREATE INDEX INDEX ON TABLE_NAME (COLUMN);
⑨旧テーブルから新テーブルへのデータ移行
（テーブル定義変更内容に合わせてデータを加工する）
INSERT INTO TABLE_NAME SELECT * FROM TABLE_NAME_BK;
COMMIT;
CSVに値出力
set head off -- ヘッダを出力しない
set trimspool on -- 行末以降の空白をカット
set pagesize 0 -- １ページのサイズを定義しない(=全行1ページ内に出力)
set termout off -- 画面に結果出力しない。お好みで。
set feedback off -- 結果件数表示のon/off お好みで。
set echo off -- スクリプトで入力されたコマンドを出力しない。
select col1 ||',' || col2 ||',' || col3 from TBL1;
- spool off
http://catnapper-mar.hatenablog.com/entry/20110422/1303493056
パーティションテーブル グローバルインデックスの注意点
パーティションテーブルの思わぬ落とし穴をここに残します。
まだ、調査段階なので 第一弾ってところです。
1、パーティションのindex運用の課題
パーティションテーブルで、グローバルインデックスを使用している場合、
INDEXが使用不可となりパフォーマンス低下！
2、回避案（案）
調べたところ、以下３つ案が見つかったので残します。
※検証は後日実施予定
①オンラインでグローバルインデックス作成
CREATE INDEX 索引名 ON パーティション表名(列名) LOCAL;
データを削除してから行うことで、UNUSABLEにしないようにできます。
③ローカルINDEXに変更
※オンラインでの変更手順は探せなかった・・ので、作業中は一時的にindexがない状態となる
1,create unique index PK名 on スキーマ.テーブル名_BK ("CLIENT_ID","CAR_DAY_DATE","STOCK_ID") LOCAL;
2,alter table スキーマ.テーブル名 ADD CONSTRAINT PK名 PRIMARY KEY ("CLIENT_ID","CAR_DAY_DATE","STOCK_ID") USING INDEX tablespace PK表領域;
Appendix
L技術情報
表のパーティション・タイプの確認
SELECT table_name,partitioning_type,partition_count
FROM dba_part_tables;
各パーティション表定義の確認
select table_name,partition_name,high_value
from dba_tab_partitions;
統計情報の取得もパーティション単位で可能
BEGIN DBMS_STATS.GATHER_TABLE_STATS
END;
/
パーティションアドバイザ
DataGuardに関するSQLコマンドまとめ！
アシストさんの記事ですが、
いざという時、超便利だと思うのでここにメモします
DataGuard構築後に使うSQLコマンドまとめ（逆引き） | アシスト
1.インスタンスのロール（プライマリかスタンバイ）を確認するSQL
3.スイッチオーバーが可能かどうかを確認するSQL
5.保護モードの設定を確認するSQL
--プライマリの場合
SQL> COL DB_UNIQUE_NAME FOR A20 COL DATABASE_ROLE FOR A20 SELECT DB_UNIQUE_NAME,DATABASE_ROLE FROM V$DATABASE;
DB_UNIQUE_NAME DATABASE_ROLE
-------------------- --------------------
v1123 PRIMARY
--スタンバイの場合
SQL> COL DB_UNIQUE_NAME FOR A20 COL DATABASE_ROLE FOR A20 SELECT DB_UNIQUE_NAME,DATABASE_ROLE FROM V$DATABASE;
DB_UNIQUE_NAME DATABASE_ROLE
-------------------- --------------------
v1123s PHYSICAL STANDBY
AWS初心者がEC2からS3の画像をマウントしてみた
agenda
- IAM Role作成
- EC2を２つ作成（1のRoleを使用）
- ELBで2のEC2設定（yum でhttpdインストール）
- S3作成＆画像UP
- s3fsインストール
- EC2からS3の画像をマウント
- 動作検証
EC2インスタンスにS3をマウントして使用する（IAM Role ver) - Qiita
【初心者向け】Amazon EC2にSSH接続する【Windows、Macintosh】 ｜ Developers.IO
このサイトを参考にさせていただきました。
悩んだ点と忘れそうな点だけ手順を以下に残します。
EC2接続
$chmod 600 <秘密鍵.pem>
$ssh -i <秘密鍵.pem> ec2-user@<パブリックDNS>
マウント
EC2でマウントする
$sudo vi /etc/fuse.conf
fuse.conf内は下記のようになっているので２行目の#を外してrootユーザー以外が利用できるようにする。
# mount_max = 1000
# user_allow_other（⇦ここの#を外す）
マウントでid,gidを使うので、事前に調べる必要がある。
$ id ec2-user
マウントコマンドは以下。
$/usr/local/bin/s3fs <S3バケット名> <マウント場所> -o rw,allow_other,uid=500,gid=500,default_acl=public-read,iam_role="<IAMロール名>"
$id ec2-user
今回の場合は以下でマウントした。
ドキュメントルートをそのままマウントするのはどうかと思うけど勉強用だから今は考えないでおく。
$/usr/local/bin/s3fs webserver-test-uses3 /var/www/html -o rw,allow_other,uid=500,gid=500,default_acl=public-read,iam_role="use-s3-webserver-test"
マウント確認
$df -h
おまけ
これでOS再起動後、WEBサイトが見れないってことはなさそう。
その他の設定は特に思いつかなかったので、今回はここまで。
以上、
【Oracle】FASTSTATFAILOVERのタイムアウト値を変更
DGMGRL コマンドラインを使用してプライマリサイトへ接続します。
- Primary側接続
$ dgmgrl
DGMGRL> connect sys/＜PW省略＞
- ステータス確認
DGMGRL> SHOW CONFIGURATION VERBOSE
DGMGRL> SHOW FAST_START FAILOVER
ファスト・スタート・フェイルオーバー: ENABLEDであること。
構成ステータス:SUCCESS であること。
FastStartFailoverThreshold:90であること。
- FASTSTATFAILOVERのタイムアウト値を変更
DGMGRL> EDIT CONFIGURATION SET PROPERTY FastStartFailoverThreshold=60;
プロパティ"faststartfailoverthreshold"が更新されました が表示されること。
- ステータス確認
DGMGRL> SHOW CONFIGURATION VERBOSE
DGMGRL> SHOW FAST_START FAILOVER
ファスト・スタート・フェイルオーバー: ENABLEDであること。
構成ステータス:SUCCESS であること。
FastStartFailoverThreshold:60であること。
