今天因为要在 nimbula 实例上测试 Oracle Database 12c DBaas 的 IO 性能,因为 nimbula 实例不方便安装 Oracle Database 软件,就从一台已经安装了该软件的机器上copy过来一个 Oracle Home 目录,但是无论怎么设置环境变量,始终都报如下错误: export ORAC
今天因为要在 nimbula 实例上测试 Oracle Database 12c DBaas 的 IO 性能,因为 nimbula 实例不方便安装 Oracle Database 软件,就从一台已经安装了该软件的机器上copy过来一个 Oracle Home 目录,但是无论怎么设置环境变量,始终都报如下错误:
export ORACLE_HOME=/u01/app/oracle/product/12.1.0/dbhome_1
export PATH=$ORACLE_HOME/bin:$PATH
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib:/usr/local/lib:$LD_LIBRARY_PATH
-bash-4.1# orion
orion: error while loading shared libraries: libaio.so.1: cannot open shared object file: No such file or directory
在 nimbula 实例上查找 libaio.so.1 发现在拷贝的 Oracle Home 目录下,也确实存在该目录,只是没有添加到 LD_LIBRARY_PATH 中,将该路径加入变量中后
/u01/app/oracle/product/12.1.0/dbhome_1/lib/stubs/libaio.so.1
export ORACLE_HOME=/u01/app/oracle/product/12.1.0/dbhome_1
export PATH=$ORACLE_HOME/bin:$PATH
export LD_LIBRARY_PATH=$ORACLE_HOME/lib:/lib:/usr/lib:/usr/local/lib:/u01/app/oracle/product/12.1.0/dbhome_1/lib/stubs:$LD_LIBRARY_PATH
可是在执行 orion 测试命令时又遇到另一个错误,提示 stubs 下的 lib 只是一个 link ,这个路径不应包含在 LD_LIBRARY_PATH 中。
于是又将该路径从变量中移除。感觉此问题可能和这里的 Oracle Home 是从其他机器拷贝而来有关。对比一下原机器和现有 nimbula 实例发现。
在 google 搜索到一个很有用的link对解决此问题有很大帮助:http://www.pipperr.de/dokuwiki/doku.php?id=dba:oracle_io_last_werkzeug_orion
在 nimbula 实例上进入 orion 所在路径然后执行 ldd 命令查看 orion 所调用的模块发现缺少两个 libaio.so1 包,而前面的find命令已经在Oracle Home/lib下已经找到该
lib包,这里只有一种可能这里所缺的libaio.so.1和上面的其他的lib包一样,可能只是一个link指向 Oracle Home/lib 下的文件。
-bash-4.1# cd $ORACLE_HOME/bin
-bash-4.1# ldd ./orion
linux-vdso.so.1 => (0x00007fffa5b96000)
libclntsh.so.12.1 => /u01/app/oracle/product/12.1.0/dbhome_1/lib/libclntsh.so.12.1 (0x00007fbe55d1e000)
libclntshcore.so.12.1 => /u01/app/oracle/product/12.1.0/dbhome_1/lib/libclntshcore.so.12.1 (0x00007fbe557cd000)
libcell12.so => /u01/app/oracle/product/12.1.0/dbhome_1/lib/libcell12.so (0x00007fbe55531000)
libskgxp12.so => /u01/app/oracle/product/12.1.0/dbhome_1/lib/libskgxp12.so (0x00007fbe55236000)
libaio.so.1 => not found
libdl.so.2 => /lib64/libdl.so.2 (0x00007fbe5502d000)
libm.so.6 => /lib64/libm.so.6 (0x00007fbe54da9000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fbe54b8b000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x00007fbe54972000)
librt.so.1 => /lib64/librt.so.1 (0x00007fbe5476a000)
libc.so.6 => /lib64/libc.so.6 (0x00007fbe543d6000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbe58a0e000)
libnnz12.so => /u01/app/oracle/product/12.1.0/dbhome_1/lib/libnnz12.so (0x00007fbe53cc0000)
libons.so => /u01/app/oracle/product/12.1.0/dbhome_1/lib/libons.so (0x00007fbe53a7c000)
libaio.so.1 => not found
libaio.so.1 => not found
在拷贝 Oracle Home 的源主机上发现,果然是 nimbula 实例缺少相应的包。
-bash-3.2# hostname
slcn06cn13
-bash-3.2# find / -name libaio.so.1
/usr/lib64/libaio.so.1
/usr/lib/libaio.so.1
-bash-3.2# cd /u01/app/oracle/product/12.1.0/dbhome_1/bin
-bash-3.2# ldd orion
linux-vdso.so.1 => (0x00007fff043ff000)
libclntsh.so.12.1 => not found
libclntshcore.so.12.1 => not found
libcell12.so => not found
libskgxp12.so => not found
libaio.so.1 => /usr/lib64/libaio.so.1 (0x00007f08dd3fa000)
libdl.so.2 => /lib64/libdl.so.2 (0x000000363a800000)
libm.so.6 => /lib64/libm.so.6 (0x000000363a000000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x000000363ac00000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x000000363e000000)
librt.so.1 => /lib64/librt.so.1 (0x000000363b000000)
libc.so.6 => /lib64/libc.so.6 (0x0000003639c00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003639800000)
这下终于知道原因了,尝试将源主机上的 /usr/lib64/libaio.so.1 和 /usr/lib/libaio.so.1 拷贝到 nimbula 实例上对应的目录问题立即解决。
转载请注明作者出处及原文链接,否则将追究法律责任:
作者:xiangsir
原文链接:http://blog.csdn.net/xiangsir/article/details/18262689
QQ:444367417
MSN:xiangsir@hotmail.com

INNODBは、レドログと非論的なものを使用して、データの一貫性と信頼性を確保しています。 1.レドログは、クラッシュの回復とトランザクションの持続性を確保するために、データページの変更を記録します。 2.Undologsは、元のデータ値を記録し、トランザクションロールバックとMVCCをサポートします。

説明コマンドのキーメトリックには、タイプ、キー、行、および追加が含まれます。 1)タイプは、クエリのアクセスタイプを反映しています。値が高いほど、constなどの効率が高くなります。 2)キーは使用されているインデックスを表示し、nullはインデックスがないことを示します。 3)行はスキャンされた行の数を推定し、クエリのパフォーマンスに影響します。 4)追加の情報を最適化する必要があるというFilesortプロンプトを使用するなど、追加情報を提供します。

Temporaryを使用すると、MySQLクエリに一時テーブルを作成する必要があることが示されています。これは、異なる列、またはインデックスされていない列を使用して順番に一般的に見られます。インデックスの発生を回避し、クエリを書き直し、クエリのパフォーマンスを改善できます。具体的には、expliect出力に使用を使用する場合、MySQLがクエリを処理するために一時テーブルを作成する必要があることを意味します。これは通常、次の場合に発生します。1)個別またはグループビーを使用する場合の重複排除またはグループ化。 2)Orderbyに非インデックス列が含まれているときに並べ替えます。 3)複雑なサブクエリを使用するか、操作に参加します。最適化方法には以下が含まれます。1)OrderbyとGroupB

MySQL/INNODBは、4つのトランザクション分離レベルをサポートしています。 1.ReadunCommittedは、知らないデータを読み取ることができます。 2。読み込みは汚い読み取りを回避しますが、繰り返しのない読みが発生する可能性があります。 3. RepeatablerEadはデフォルトレベルであり、汚い読み取りと非回復不可能な読みを避けますが、幻の読み取りが発生する可能性があります。 4. Serializableはすべての並行性の問題を回避しますが、同時性を低下させます。適切な分離レベルを選択するには、データの一貫性とパフォーマンス要件のバランスをとる必要があります。

MySQLは、Webアプリケーションやコンテンツ管理システムに適しており、オープンソース、高性能、使いやすさに人気があります。 1)PostgreSQLと比較して、MySQLは簡単なクエリと高い同時読み取り操作でパフォーマンスが向上します。 2)Oracleと比較して、MySQLは、オープンソースと低コストのため、中小企業の間でより一般的です。 3)Microsoft SQL Serverと比較して、MySQLはクロスプラットフォームアプリケーションにより適しています。 4)MongoDBとは異なり、MySQLは構造化されたデータおよびトランザクション処理により適しています。

MySQLインデックスのカーディナリティは、クエリパフォーマンスに大きな影響を及ぼします。1。高いカーディナリティインデックスは、データ範囲をより効果的に狭め、クエリ効率を向上させることができます。 2。低カーディナリティインデックスは、完全なテーブルスキャンにつながり、クエリのパフォーマンスを削減する可能性があります。 3。ジョイントインデックスでは、クエリを最適化するために、高いカーディナリティシーケンスを前に配置する必要があります。

MySQL学習パスには、基本的な知識、コアの概念、使用例、最適化手法が含まれます。 1)テーブル、行、列、SQLクエリなどの基本概念を理解します。 2)MySQLの定義、作業原則、および利点を学びます。 3)インデックスやストアドプロシージャなどの基本的なCRUD操作と高度な使用法をマスターします。 4)インデックスの合理的な使用や最適化クエリなど、一般的なエラーのデバッグとパフォーマンス最適化の提案に精通しています。これらの手順を通じて、MySQLの使用と最適化を完全に把握できます。

MySQLの実際のアプリケーションには、基本的なデータベース設計と複雑なクエリの最適化が含まれます。 1)基本的な使用法:ユーザー情報の挿入、クエリ、更新、削除など、ユーザーデータの保存と管理に使用されます。 2)高度な使用法:eコマースプラットフォームの注文や在庫管理など、複雑なビジネスロジックを処理します。 3)パフォーマンスの最適化:インデックス、パーティションテーブル、クエリキャッシュを使用して合理的にパフォーマンスを向上させます。


ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

AtomエディタMac版ダウンロード
最も人気のあるオープンソースエディター

メモ帳++7.3.1
使いやすく無料のコードエディター

ZendStudio 13.5.1 Mac
強力な PHP 統合開発環境

VSCode Windows 64 ビットのダウンロード
Microsoft によって発売された無料で強力な IDE エディター

WebStorm Mac版
便利なJavaScript開発ツール
