AWS上で、Oracle DBの11.2.0を試している。 例の如く、EC2インスタンスのprivate ipがOS起動毎に変わる影響で、EMが起動しない。EMのレポジトリを再作成しようとしたが、表題のエラーが発生して再作成が失敗する。また、シューティングしている中で以下のようなエラーも発生。 CONFIG: ORA-00955: name is already used by an existing object ググって、以下の情報を見つけた。 http://blog.mclaughlinsoftware.com/oracle-architecture-configuration/changing-windows-hostname-and-oracle-enterprise-manager/ http://arjudba.blogspot.com/2008/04/stack-of-problems-while-creating.html http://forums.oracle.com/forums/thread.jspa?threadID=1057381&tstart=0&start=45 １、先ず、いつものようにEMのレポジトリをドロップ emca -deconfig dbcontrol db -repos drop ２、SYSMAN関連のオブジェクトを、手動でドロップ DROP USER sysman CASCADE; DROP PUBLIC SYNONYM setemviewusercontext; DROP ROLE mgmt_user; DROP PUBLIC SYNONYM mgmt_target_blackouts; DROP USER mgmt_view; DROP PUBLIC SYNONYM MGMT_AVAILABILITY; ３、EMのレポジトリを再作成 emca -config dbcontrol db -repos recreate private ipが変わることで、listener.oraやtnsnames.oraも書き換えねばならず、若干嵌ったが、なんとかEM起動した。
Monthly Archives: March 2011
EBSブートしたルートパーティションの領域拡張
us-westのEC2環境を使い始めたのを機に、昨年末話題になっていたEC2インスタンスのEBSブートを試した。 その際、以下の各サイトを参考にさせて頂いた。 http://nxdxa.blogspot.com/2010/02/amazon-ebs-ec2.html http://blog.suz-lab.com/2010/01/migrating-centos-s3-based-ami-to-ebs.html http://coderslike.us/2009/12/07/amazon-ec2-boot-from-ebs-and-ami-conversion/ ネット上の情報を見るに、EC2インスタンスのEBSブートには、以下のようなメリットがあるようだ。 ・S3ベースのインスタンスと比較し、起動が速い。 ・インスタンス停止時に”terminate”ではなく”stop”を実行することで、ルートパーティション上のデータが消されないで済む。 ・S3ベースのインスタンスのルートパーティションの領域は、10GBが上限。一方、EBSベースの場合、1TBまで領域を拡張できる。 1つ目、2つ目のメリットについては噂通り。 インスタンスの起動時間は計測したわけではないが、速くなっている印象を受けた。 また、ルートパーティション上で変更を加えた場合（/etcの下のファイルをイジる、とか・・・）、以前ならec2-bundle-volしないといけなくてウザかったのだが、その必要はなくなった。インスタンスをterminateせず、stopしておけば、ルートパーティション上のデータは消えず、課金もされない。個人でちょくちょく使う利用者にとってはうれしい機能だ。 一方、3つ目のメリット、ルートパーティションの領域拡張については、最初若干うまくいかなかった。 参考にさせて頂いた3つめのサイトの情報を基に、インスタンス起動時にblock-device-mappingを指定してルートパーティションの領域を拡張しようとしたのだが、これがどうにもうまくいかない。ec2run -hの情報を見て色々試行錯誤したのだが、コマンドだとうまくいかない・・・なんでだろう？ C:\Amazon Web Services>ec2run ami-XXXXXXXX –block-device-mapping /dev/sda1=:50 -k xxxx -g xxxx -z us-west-1a WARNING: Ignoring extra parameter(s): [ :50 ] Invalid argument for option ‘-b, –block-device-mapping MAPPING’: ‘/dev/sda1’ (-h for usage) 結局、インスタンスはAWS Management Consoleで普通に起動させ、起動後にサーバにログインし、resize2fsしたら普通にうまくいった。 (以下はCentOSの例) [root@hogehoge ~]# df -k Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda1 10321208 2340744 7456176 24% / none 870472 0 870472 0% /dev/shm [root@hogehoge ~]# [root@hogehoge ~]# resize2fs /dev/sda1 resize2fs 1.39 (29-May-2006) Filesystem at /dev/sda1 is mounted on /; on-line resizing required Performing an on-line resize of /dev/sda1 to 13107200 (4k) blocks. The filesystem on /dev/sda1 is now 13107200 blocks […]
Amazon EC2 APIで、us-east以外のregionを管理
Amazon EC2でus-west(N. California)にインスタンスを立てたのだが、インスタンス上でec2-describe-instancesしても、何も表示されない。 どうやら、Amazon EC2 API Toolsのデフォルトregionは、us-eastになっているようだ。 http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/index.html?setting-up-your-tools.html By default, the Amazon EC2 tools use the Eastern United States region (us-east-1) with the us-east-1.ec2.amazonaws.com service endpoint URL. This section describes how to specify a different region by changing the service endpoint URL. regionの切り替えは、環境変数で行う。EC2_URLに、管理を行いたいregionのURLを設定する。 以下は、us-west、Linux環境の例。Windowsなら、当然ながらsetにすること。 export EC2_URL=https://ec2.us-west-1.amazonaws.com URLのFQDN部分は、ec2-describe-regionsで調べられる模様。 [root@hogehoge ~]# ec2-describe-regions REGION eu-west-1 ec2.eu-west-1.amazonaws.com REGION us-east-1 ec2.us-east-1.amazonaws.com REGION us-west-1 ec2.us-west-1.amazonaws.com