ブックマークの同期失敗・・・

自宅PC、職場PC、HT-03A(Android)でブックマークを同期する方法を探している。

で、↓こうしてみた。これで実現できそうだが・・・

• HT-03AはDolphin BrowerでGoogleブックマークと同期。
• 自宅PC、職場PCはChromeのブックマーク同期を利用。

残念！

Chromeのブックマーク同期はGoogleドキュメントのフォルダとして実現していて、Googleブックマークと同期しているわけではという罠。

Google先生、Googleブックマークというサービスを提供していながら、何故Chromeのブックマーク同期はGoogleドキュメントを使うんでしょうか・・・

【SQL Server】インデックスの一覧を抽出するSQL

SELECT
    i.name AS index_name
    ,o.name AS table_name
    ,col.name AS column_name
FROM
    sysindexkeys ik
    ,sysobjects o
    ,syscolumns col
    ,sysindexes i
WHERE
        ik.id = o.id
    AND ik.id = col.id
    AND ik.colid = col.colid
    AND ik.id = i.id
    AND ik.indid = i.indid
    AND o.xtype = 'U'
ORDER BY
    i.name
    ,ik.id
    ,ik.indid
    ,ik.keyno
 

【Oracle】CPU使用時間の長いクエリを特定するためのSQL

SELECT

*
FROM
    (
        SELECT
             sql_id
            ,last_load_time
            ,executions
            ,cpu_time
            ,cpu_time / executions / 1000000
            ,sql_id
            ,TRANSLATE( sql_text, '#' || CHR(13) || CHR(10), '#' ) sql_text
        FROM
            v$SQL
        WHERE
                module = 'w3wp.exe'
            AND executions > 0
            AND last_load_time>='2010-01-01/00:00:00'
        ORDER BY
            cpu_time / executions DESC
    )
WHERE
        rownum <= 30;

---

last_load_time：最後に読み込まれた日時
executions：実行回数
cpu_time：CPU使用時間
sql_text：SQL（全てじゃない）


※例はワーカープロセス(w3wp.exe)からのアクセスで、2010年01月01日の00時00分00秒以降にCPU負荷が高かったクエリを抽出するもの。

【要調査なSQL】

• 1回当たりのCPU仕様時間(cpu_time/executions) の値が異常に高いもの(数十秒とか)
• 1回当たりのCPU仕様時間(cpu_time/executions) が1秒以上で実行回数(executions)が多いもの

2フェーズ・コミットとインダウト・トランザクション

2フェーズ・コミット

2フェーズ・コミットは準備フェーズ、コミットフェーズの2つのフェーズでトランザクションを処理することでトランザクションの原子性を保障するメカニズムです。

■ 2フェーズ・コミットを採用しない場合
2フェーズ・コミットを採用しない場合、下図のように原子性が保障できません。

■ 2フェーズ・コミットでは
2フェーズ・コミットでは、準備フェーズでDBはコミット準備を行いトランザクション・マネージャへコミット可能票を投票し、コミットフェーズで全てのDBがコミット可能票を投票した場合コミットします。
拒否票が1票でも投票された場合はロールバックします。

2フェーズ・コミットでは、このように２つのフェーズでトランザクションの原子性を保障します。

※図中の不確定区間(インダウト)はコミット/ロールバックのどちらを行うかが確定していない区間を指します。

インダウト・トランザクション

2フェーズ・コミットのコミットフェーズで障害が発生した場合、DBのトランザクションがコミット/ロールバックが確定しないインダウト状態となります。
このインダウト状態が発生したトランザクションをインダウト・トランザクションと言います。
インダウト・トランザクションはリカバリするまでアクセスしていたデータをロックし続けます。そのため早期な検出、リカバリが必要になります。

下図ではDB２でインダウト状態が発生しています。

MSDTC×Oracleの環境ではOracle MTS Recovery Service、リカバリ・ジョブ(DBMS_JOBパッケージで登録するジョブ)で自動リカバリを実現します。
MSDTC×Oracleの自動リカバリについてはいずれ詳細をPOSTします。

SSISパッケージのProtectionLevel

SSISパッケージの編集を複数の開発環境で行う場合はProtectionLevelに注意。

• DontSaveSensitive：接続文字列中のパスワードなど機微なプロパティが空白に置き換えられる
• EncryptAllWithPassword：パッケージ全体をパスワードを使って暗号化する。
• EncryptAllWithUserKey：パッケージ全体をユーザープロファイルを使って暗号化する。
• EncryptSensitiveWithPassword：接続文字列中のパスワードなど機微なプロパティをパスワードを使って暗号化する。
• EncryptSensitiveWithUserKey：接続文字列中のパスワードなど機微なプロパティをユーザープロファイルを使って暗号化する。

【単一の開発環境でパッケージを編集する場合】
EncryptAllWithUserKey、またはEncryptSensitiveWithUserKey

【複数の開発環境でパッケージを編集する場合】
EncryptAllWithPassword、またはEncryptSensitiveWithPassword



※当然、開発時、配置時、運用時で適切なProtectionLevelを設定するべき。


参考：http://msdn.microsoft.com/ja-jp/library/ms141747.aspx

Snipt

http://snipt.org/

コードの色づけをしたHTMLを作成してくれるツール。
コード用にURLを生成するので共有したいときに便利。

Twitterでコードについて呟くときとか、良いかも。