Wednesday, June 29, 2011

RAC Maintenance

RAC Maintenance
1. crsctl
1.1 check crs status
$ ./crsctl check crs
CSS appears healthy
CRS appears healthy
EVM appears healthy
-- check single status
$ ./crsctl check cssd
CSS appears healthy
$ ./crsctl check crsd
CRS appears healthy
$ ./crsctl check evmd
EVM appears healthy

1.2 start and stop crs
-- START CRS:
$ ./crsctl start crs
Attempting to start CRS stack
The CRS stack will be started shortly
-- STOP CRS:
$ ./crsctl stop crs
Stopping resources.
Successfully stopped CRS resources
Stopping CSSD.
Shutting down CSS daemon.
Shutdown request successfully issued.

1.3 check Votedisk
$ ./crsctl query css votedisk
0. 0 /dev/raw/raw2
located 1 votedisk(s).

1.4 check ocr
$ ./ocrconfig -showbackup

2. crs_stat
2.1 check point app
$ ./crs_stat ora.raw2.vip
NAME=ora.raw2.vip
TYPE=application
TARGET=ONLINE
STATE=OFFLINE

2.2 use –v ,check point app
$ ./crs_stat -v ora.raw2.vip
NAME=ora.raw2.vip
TYPE=application
RESTART_ATTEMPTS=0
RESTART_COUNT=0
FAILURE_THRESHOLD=0
FAILURE_COUNT=0
TARGET=ONLINE
STATE=OFFLINE

2.3 use –p ,check point app
$ ./crs_stat -p ora.raw2.vip
NAME=ora.raw2.vip
TYPE=application
ACTION_SCRIPT=/u01/app/oracle/product/crs/bin/racgwrap
ACTIVE_PLACEMENT=1
AUTO_START=1
CHECK_INTERVAL=60
DESCRIPTION=CRS application for VIP on a node
FAILOVER_DELAY=0
FAILURE_INTERVAL=0
FAILURE_THRESHOLD=0
HOSTING_MEMBERS=raw2
OPTIONAL_RESOURCES=
PLACEMENT=favored
REQUIRED_RESOURCES=
RESTART_ATTEMPTS=0
SCRIPT_TIMEOUT=60
START_TIMEOUT=0
STOP_TIMEOUT=0
UPTIME_THRESHOLD=7d
USR_ORA_ALERT_NAME=
USR_ORA_CHECK_TIMEOUT=0
USR_ORA_CONNECT_STR=/ as sysdba
USR_ORA_DEBUG=0
USR_ORA_DISCONNECT=false
USR_ORA_FLAGS=
USR_ORA_IF=eth0
USR_ORA_INST_NOT_SHUTDOWN=
USR_ORA_LANG=
USR_ORA_NETMASK=255.255.255.0
USR_ORA_OPEN_MODE=
USR_ORA_OPI=false
USR_ORA_PFILE=
USR_ORA_PRECONNECT=none
USR_ORA_SRV=
USR_ORA_START_TIMEOUT=0
USR_ORA_STOP_MODE=immediate
USR_ORA_STOP_TIMEOUT=0
USR_ORA_VIP=10.85.10.123

2.4 use –ls
$ ./crs_stat -ls
Name Owner Primary PrivGrp Permission
-----------------------------------------------------------------
ora.raw.db oracle oinstall rwxrwxr--
ora.raw.dmm.cs oracle oinstall rwxrwxr--
ora....aw2.srv oracle oinstall rwxrwxr--
ora....w1.inst oracle oinstall rwxrwxr--
ora....w2.inst oracle oinstall rwxrwxr--
ora....SM1.asm oracle oinstall rwxrwxr--
ora....W1.lsnr oracle oinstall rwxrwxr--
ora.raw1.gsd oracle oinstall rwxr-xr--
ora.raw1.ons oracle oinstall rwxr-xr--
ora.raw1.vip root oinstall rwxr-xr--
ora....SM2.asm oracle oinstall rwxrwxr--
ora....W2.lsnr oracle oinstall rwxrwxr--
ora.raw2.gsd oracle oinstall rwxr-xr--
ora.raw2.ons oracle oinstall rwxr-xr--
ora.raw2.vip root oinstall rwxr-xr—

2.5 use –t
$ ./crs_stat –t
Name Type Target State Ho
-----------------------------------------------
ora....c01.lsnr application ONLINE ONLINE gnd-rac01
ora....c01.gsd application ONLINE ONLINE gnd-rac01
ora....c01.ons application ONLINE ONLINE gnd-rac01
ora....c01.vip application ONLINE ONLINE gnd-rac01
ora....c02.lsnr application OFFLINE OFFLINE gnd-rac02
ora....c02.gsd application ONLINE ONLINE gnd-rac02
ora....c02.ons application ONLINE ONLINE gnd-rac02
ora....c02.vip application ONLINE ONLINE gnd-rac02
3. srvctl
3.1 start database
$ ./srvctl start database -d bossmain

3.2 start one instance to point status
$ ./srvctl start database -d bossmain -i bossmain1 -o mount
$ ./srvctl start database -d bossmain -i bossmain1 -o nomount

3.3 close database
$ ./srvctl stop database -d bossmain

3.4 close one instance
$ ./srvctl stop instance -d bossmain -i bossmain1 -o immediate
$ ./srvctl stop instance -d bossmain -i bossmain1 -o abort

3.5 start service on one instance
$ ./srvctl start service -d bossmain -s rawservice -i bossmain1
-- check service status
$ ./srvctl status service -d bossmain –v

3.6 start service on one instance
$ ./srvctl stop service -d bossmain -s rawservice -i bossmain1
-- check service status
$ ./srvctl status service -d bossmain –v

3.7 start/stop/check all nodeapps
$ srvctl start|stop|status|enable nodeapps -n
4. RAC Start
4.1 Maintenance of database and operating system, server
a. stop database
$ lsnrctl stop (each node stop listener)
$ $AGENT_HOME/bin/emctl stop agent (each node stop dbconsole)
$ srvctl stop database -d bossmain (stop all database)
$ srvctl stop nodeapps -n p570db3 (stop node1 service)
$ srvctl stop nodeapps -n gnd-rac02 (stop node2 service)
$ crs_stop –all
Or
$ crsctl start crs
b. close host
c. close power
d. start server
$ srvctl start nodeapps –n rac01 (start node1 service)
$ srvctl start nodeapps -n rac02 (start node2 service)
$ srvctl start database -d bossmain (start all database)
$ lsnrctl start (each node start listener)
$ $AGENT_HOME/bin/emctl start agent (each node start dbconsole)

4.2 Adjust the database parameters of the time, only to close all instances, do not restart the OS and the Server.
a. stop database
$ lsnrctl stop (each node stop listener)
$ srvctl stop database -d database (stop all database)
a. start database
$ srvctl start database -d tpc (start all database)
$ lsnrctl start (each node start listener)

4.3 Adjust the one database parameters of the time, only to close this instances, do not restart the OS and the Server.
a. stop instance
$ lsnrctl stop (one node stop listener)
$ srvctl stop database -d bossmain -i bossmain1 (stop one instance)
a. start instance
$ srvctl start database -d bossmain -i bossmain1 (start one instance)
$ lsnrctl start (one node start listener) restart one instance $AGENT_HOME/bin/emctl stop agent lsnrctl stop srvctl stop instance -d bossmain -i bossmain1 srvctl start instance -d bossmain -i bossmain1 lsnrctl start $AGENT_HOME/bin/emctl start agent

Tuesday, June 28, 2011

to find common column name in tables

Use data dictionary views.

select * from sys.all_tab_columns where owner like 'owner_name ' and column_name like 'column_name' ;


e.g.

select a.column_name,b.table_name from
(select column_name, count(*) from sys.all_tab_columns
group by column_name
having count(*)>1) a, sys.all_tab_columns b
where
a.column_name=b.column_name
order by a.column_name

Essentially you get the column names from the all_tab_columns where which
are appears in more than 1 table, then you join the table names to them
again from the same dictionary view.
I hope, this helps.

Saturday, June 25, 2011

البناء بطريقة الميكانو Modern method for the manufacture of bricks

Mr. Sabih hamid invented
Modern method for the manufacture of bricks and this method provides much of the cost with the addition of new features of the blocks in terms of both durability and weight and insulating the temperature, and method of construction does not need to cement in the installation
For more details Send message to e-mail
sabeehalatabi@yahoo.com


http://www.youtube.com/watch?v=UBNiakssmHc






ابتكر المهندس صبيح حميد جاسم العتابي
طريقة حديثة لصناعة الطابوق وهذه الطريقة توفر الكثير من الكلفة مع اضافة مميزات جديدة للطابوقة من حيت المتانة والوزن وعازلة لدرجة الحرارة ,وطريقة البناء لا تحتاج الى الاسمنت في التثبيت
وللمزيد من التفاصيل ارسل رساله الى البريد الالكتروني
sabeehalatabi@yahoo.com

Thursday, June 23, 2011

تنبؤات نوستراداموس

ولد ميشيل نوستراداموس في اليوم الرابع عشر من كانون الأول /ديسمبر من عام 1503 ميلادية في مدينة سان ريمي دي بروفانس في فرنسا . وهو يهودي الأصل ولكن أسرته تخلت عن اليهودية و اعتنقت العقيدة الكاثوليكية . و كان متأثر جدا بجده الذي قام بتعليمه قواعد اللاتينية و الإغريقية و العبرية و أصول الرياضيات و التنجيم برع في العلوم الطبية و أهتم بصورة خاصة بالتنجيم . وذاع صيته في تلك الفترة بأنه يشفي الأمراض تزوج في سنة1534 ميلادية و رزق بولد وبنت ولكن انتشار وباء الطاعون في تلك الفترة أدى إلى موت زوجته وطفليه وكان لعجزه في إنقاذهم الأثر البالغ في حياته . وبعد عدة سنوات تزوج من أرملة ثرية وبدأ بتأليف الكتب في الغيبيات مما شجعه في النهاية بكتابة كتابه الشهير (القرون ) حيث نشره لأول مرة في عام 1555 ميلادية .



ولقد كتب التنبؤات بشكل مقاطع شعرية من أربعة أبيات مبهمة المعاني ومليئة بمختلف المصطلحات من لغات متعددة مثل اللاتينية و البروفنسالية و الإيطالية وغيرها ... ولقد احتوى كتاب ( القرون ) على بعض التنبؤات من ستة أبيات شعرية و سماها ( السداسيات ) و أخرى سماها ( الإنذارات ) . وقد استعمل طريقة الجناس التصحيفي أي تغيير أماكن الحروف في الكلمة أو حذف أو تغيير حرف أو حرفين منها أو استخدام الأسماء القديمة و المنسية للمدن و الدول التي كان يعنيها في تنبؤاته و ذلك لإخفاء المعنى عن العامة من الناس و لقد قام بكل هذا حتى لا يقع في قبضة محاكم التفتيش التي كانت تحرق كل من يدّعي بمعرفته الكهانة و السحر . و لقد ساعدته واستعانت به الملكة كاترين دي مديتشي ملكة فرنسا مما ساعده في نشر كتابه و دون خوف من محاكم التفتيش ولكنه أبقى على الترميز فيه و استمر في البلاط الفرنسي إلى أن مات سنة 1566 ميلادية .



أن استشهادي بما جاء في كتاب التنبؤات هو ليس من باب الدعاية لهذا الكتاب لأنه في الواقع لا يحتاج لها لأنه طبع ومنذ صدوره لأول مرة مئات المرات و بكل اللغات العالمية . و لكن لأن ما وجدته فيه من ذكر لأحداث تهم عالمنا العربي و الإسلامي و لأن التاريخ اثبت أن اغلب ما كتبه نوستراداموس من تنبؤات قد حدث فعلا ولو أن بعض التنبؤات لم يستطيع المفسرون للتنبؤات أن يجدوا لها تفسير و هذا ليس عيبا في التنبؤات ولكنه قصور في إمكانيات المفسرين . و قد يقول أحد من الناس انه يجب أن لا يستشهد برجل يهودي الأصل و بكتاب يتحدث عن الغيبيات التي هي لله وحده فأقول أن الاستشهاد بأهل الكتاب إذا كان فيه ما يؤيد المنظور الإسلامي ويتفق معه فلا بأس في دراسته والتعريف به و ابلغ البراهين على العدو أن تأخذ من فمه ما يدينه و ما يؤيد حجتك عليه . أما القول بأن الغيب لله سبحانه و تعالى فقط فهو صحيح ولكن الله سبحانه و تعالى يصطفي من عباده من يشاء ليظهر الآيات والدلائل على يديه وقد يكون لله الحكمة البالغة في إظهار هذه الغيبيات على يد رجل يهودي حتى تكون ابلغ أثرا وسيقوم أبناء جلدته بنشرها وتعريف الناس بها لأنها لو ظهرت على يد رجل مسلم لتم طمسها و إزالتها من الوجود و لأدعّوا إن هذا الرجل إنما يريد أن ينتصر لدينه . ثم إن الغيب المقصود معرفة الله سبحانه و تعالى به فهو الغيب المطلق الكلي وليس شذرات من الغيب لأن الكثير من الناس قد مروا بمعرفة جزء من الغيب في فترة من فترات حياتهم فكم من الناس حدثت لهم أحداث لها تأثير في حياتهم و تراهم يقولون انهم أما حلموا بحدوث هذا الأمر أو أن إحساسا داخليا قويا حدث لهم بحدوث مثل هذا الأمر . إذا فالغيب المطلق كله لله يطلع من يشاء على ما يريد من هذا الغيب لغاية لا يعلمها إلا هو سبحانه . من هنا نستنتج انه جائز لنا أن ندرس و نعرف ما ورد في كتاب ( القرون ) . و الآن إليكم بعض هذه التنبؤات و تفسير ما تعني وفي الحقيقة أن بعض التفاسير للتنبؤات استطعت أنا أن أحللها و تبدأ من النبؤات التي تتحدث عن الاحتلال العراقي للكويت و ما بعدها. ويجب الانتباه إلى أن كلمة قرن هنا لا تعني مائة سنة بل مائة نبؤة . ولقد رمز نوستراداموس إلى الغرب بـ ( فرنسا ) و إلى العالم المسيحي بـ ( إيطاليا ) و لأمريكا بـ ( أسبانيا ) .





القرن الثاني - النبؤة السادسة



قرب الميناء و في مدينتين

ستحدث كارثتان ليس لهما مثيل

جوع وطاعون في الداخل,

ناس يطرحون خارجا بفعل السيف

سوف يبكون من اجل الحصول

على مساعدة من الله العظيم الأبدي .





إن هذه النبؤة تصور ما حدث في مدينتي هيروشيما و ناكازاكي اليابانية عندما ألقت أمريكا عليهما القنبلة الذرية في الحرب العالمية الثانية .





القرن التاسع- النبؤة الخامسة والخمسين



إن حربا مخيفة تدار في الغرب و في

السنة التالية سيأتي مرض ساري رهيب جدا

بحيث سيهاجم الصغار و الكبار حينما

تكون النار و الدم و الحرب و الطيران في فرنسا .



هنا يصف الحرب العالمية الأولى و انتشار وباء الطاعون ولقد أدى هذا المرض إلى موت خمسة عشر مليون إنسان في سنة 1918 ويصف حالة فرنسا أثناء الحرب .





القرن الثالث- النبؤة الثامنة و الخمسين



بالقرب من الراين سيولد قائد عظيم

للشعب في شمال الألب وسيأتي

متأخرا ليدافع عن نفسه ضد روسيا

و هنغاريا و سيكون مصيره مجهولا.



هنا يصف ولادة هتلر و حربه ضد روسيا و هنغاريا وكيف إن مصيره لازال مجهولا و مسالة موته مثاراً للعديد من الشكوك.





القرن الثاني – النبؤة الرابعة و العشرون



البهائم التي يدفعها الجوع ستعبر الأنهار

الجزء الأعظم من ساحة المعركة سيكون ضد هتلر

سيجر القائد العظيم في قفص حديدي

عندما لا يراعي ابن ألمانيا أي قانون.



إن ذكر هتلر واضح جدا في هذه الرباعية ولو انه هنا قد قام بتصحيف اسم هتلر و كتبه (هسلر).





القرن الثاني – النبؤة التاسعة عشر



قادمون جدد سيبنون مدنا بلا دفاعات

و يحتلون أماكن غير قابلة للسكن

بسعادة يضعون أيديهم على الحقول

و المنازل و الأرض و المدن ,

فيما بعد سيكون في هذه الأرض

المجاعات و الأمراض و الحروب التي تستمر وقتا طويلا.



يصف هنا عودة اليهود إلى فلسطين واحتلالها ويشير إلى الحروب التي ستحدث عندها وما تجلبه من دمار و أمراض على شعوب المنطقة .





القرن الثالث- النبؤة السابعة و التسعين



بقانون جديد أراضي جديدة

ستحتل في سوريا و الأردن

و فلسطين وستتقوض القوة العربية

وستنهار عند الانقلاب الصيفي(12 حزيران)



يصف هنا حرب الأيام الستة (5 -10) حزيران 1967 و احتلال إسرائيل للجولان و قطاع غزة و الضفة الغربية و سيناء .





السداسية الحادية و الثلاثين



السلالة التي واجهت المخاطر

و المجازفات التي لم تخسر أبدا

حربا في بلد قريب من فكرة

المسيحية عند المغادرة.

ستفاجأ بعمل غريب تقوم به مصر

أما شعب مصر فسيكون مبتهجا بهذا الإنجاز.



يصف هنا حرب يوم الغفران (حرب أكتوبر 1973 ) و الهجوم المصري على إسرائيل وفرح الشعب المصري و العربي بالنصر في هذه الحرب.





القرن الأول – النبؤة السبعين



ثورة وحرب و مجاعة لن تتوقف في إيران

,التعصب الديني سيخون الشاه

الذي ستبدأ نهايته في فرنسا على

يد رجل دين (أو نبي) معتصم في معتزل .



يصف هنا قيام الثورة الإسلامية في إيران و وجود الإمام آية الله الخميني في فرنسا ثم يذكر قيام حرب (حرب الخليج الأولى) .





القرن السابع – النبؤة الثانية و العشرون



سيهاجم العراقيون حلفاء أسبانيا

بينما الناس أما يمتعون أنفسهم

أو يتضاحكون أو يأكلون أو نيام.

البابا سيهرب قرب الرون ,احتلال إيطاليا و الفاتيكان .



يصف هنا الاحتلال العراقي للكويت و يصف أن الاحتلال سيكون ليلا لأن الناس تكون حينها أما تلهو أو تتسامر أو نيام . و لقد وصف الكويتيون بحلفاء أسبانيا لأن أمريكا اكتشفها الأسبان و كانت مستعمرة أسبانية . و اليــهود والمسيحيون دائما يطــلقون على الأنبياء أو رجال الدين اسم ( الملك) وهنا قام نوستراداموس بعكس التسمية و أطلق على أمير الكويت اسم البابا. و احتلال إيطاليا و الفاتيكان يقصد به احتلال القوات الغربية و الأمريكية للسعودية حيث أن إيطاليا تشابه السعودية لأن فيها الفاتيكان و في السعودية توجد الكعبة المشرفة لدى المسلمين .





القرن السادس ـ النبؤة التاسعة



سوف ترتكب الفضائع في الهياكل المقدسة

و سيظنها الناس من سمات الشرف و مما يدعو للاحترام

يرتكبها شخص ينقشون صورته على الفضة

و الذهب و الأوسمة

و ستكون النهاية بشكل عذاب غريب جدا

إن هذه النبؤة تكاد أن تصف ما قام به صدام حسين و زمرته في جنوب العراق أثناء الانتفاضة الشعبية حيث تم ارتكاب افضع الجرائم في مقامات الأئمة الأطهار في مدينتي النجف الأشرف و كربلاء المقدسة من قتل و ذبح و تدمير .... و كان النظام يصور ما يقوم به على انه عملية إعادة الأمن و الهدوء لمناطق و مدن سيطر عليها ولتي صورها دخلتها قوات معادية من خارج الحدود

( الإيرانيون ) . و من اكثر من حاكم العراق كان قد نقش صورته على الذهب و الفضة والأوسمة العسكرية و النقود و غيرها و يصف نهاية هذا الحاكم بأنها ستكون بشكل عذاب غريب جدا ...





القرن الثاني ـ النبؤة الثانية و الستين



سيموت ( mabus ) الغازي الشرير سريعا

بعد أن يقيم مجزرة

للإنسان و الحيوان لكن الثأر

سيتم فجأة بسبب خطابات لا نهاية لها

ستحكم القوة و هو سيزول الجوع و العطش

حالما يعبر المذنب قبة السماء

هذه من اغرب النبؤات التي تذكر صدام حسين بالأسم فـلو كتبت الاسم المذكور( mabus ) على ورقة و نظرت إليه بالمرأة لوجدت أن الاسم يقرأ صدام ( sudam ) أي بمعنى آخر أن تقرأ الاسم من اليمين لليسار أي بأتجاه القراءة بالعربية و لعل نوستراداموس تعمد استخدام هذه الطريقة للتنبيه على أن الاسم عربي !!!! . و من الغريب أن مترجم الكتاب فسر الكلمة على أنها الغازي الشرير و لا ادري هل هي مصادفة أم لا!!! . و تقول النبؤة أن صدام سيموت بعد أن يرتكب مجزرة للإنسان و الحيوان

و من ثم سيتم الثأر منه و ستسيطر القوة و سيزول الجوع و العطش الاقتصادي بعد موته !!) حالما يمر مذنب في السماء ( ربما يصف هنا انطلاق صاروخ أو ما شابه يقضي على صدام و يقتله) .





القرن الثامن ـ النبؤة السبعين



سوف يدخل : شرير , بغيض , سيئ الصيت

يستبد بأهل ما بين النهرين

كل الأصدقاء تصنعهم السيدة الزانية

الأرض توقع الرهبة و سوداء المظهر





يصف هنا السفياني و احتلاله العراق ( ما بين النهرين ) و يصفه بالشرير و البغيض و سيئ الصيت و كيف انه سيستبد بأهل العراق و يعمل بهم السيف و هذا ما ذكره أهل البيت ( عليهم السلام ) من أن السفياني سيأتي إلى العراق قبل ظهور الإمام المهدي (عليه السلام ) و يقتل خلقا كثير و خاصة في بغداد و الكوفة و سيستهدف بصورة خاصة السادة الأشراف من أهل البيت و اتباعهم . ثم يقول أن كل الأصــــدقاء( أي الأخيار ) ســـيكونون من بابل ( اليهود و النصارى يطلقون على بابل اسم السيدة الزانية لان نبوخذنصر الملك البابلي دمر دولتهم و اخذ الكثير من اليهود سبايا إلى بابل ...) و نحن نعرف أن منطقة بابل فيها مدينة الكوفة التي ستكون مركز لانطلاق الإمام المهدي ( عليه السلام ) في حربه ضد الغرب و الولايات المتحدة الأمريكية لتحرير القدس الشريف و نشر العدل و السلم في العالم و يصف الأرض بأنها سوداء المظهر و هذا دليل على إن الإمام المهدي ( عليه السلام ) سيبسط سيطرته على جميع الأرض لأن اللون الأسود هو من صفات لباس أهل البيت عليهم السلام .



ظهور الإمام المهدي (عليه السلام)

القرن الخامس – النبؤة الخامسة و الخمسين



في منطقة الجزيرة العربية سيلد

حاكم مسلم قوي هذا الحاكم سينهك

ويرهق أسبانيا عند فتحه لمدينة

غر ناطة و إيطاليا أيضا عن طريق البحر.



يصف هنا ظهور الإمام المهدي (عليه السلام) (الله اكبر) في الجزيرة العربية وعرفنا من الأحاديث النبوية الشريفة انه سيظهر أول الأمر في المدينة المنورة ثم يتجه نحو مكة المكرمة …. وكيف انه سيفتح أسبانيا و سيفتح إيطاليا (فيها الفاتيكان) قبلة العالم المسيحي .



القرن الثالث – النبؤة الرابعة و التسعين



لمدة خمسمائة سنة أخرى

سوف ينتبهون إليه فهو زينة عصره

ثم سيبعث فجأة وحي عظيم

سيجعل أناس ذلك القرن مسرورين



يصف هنا ظهور الإمام المهدي ( عليه السلام ) وكيف إن الناس ستنتبه إلى وجوده لأن نوستراداموس يقول أن الناس سينتبهون إليه بعد خمسمائة سنة أخرى ( و هذا يتناسب مع ما يقوله الشيعة في انه غائب عن أعين الناس و لا أحد يعرف شخصه حماية له من أعدائه) أي انه في زمان نوستراداموس كان موجودا و لكن لا أحد ينتبه إليه و يصفه بأنه زينة عصره ( و هذا شيء أكيد ) لما سيقوم به من نصرة دين الله سبحانه و تعالى و لقد حدد تاريخ الظهور بعد خمسمائة سنة تقريبا من كتابة هذه النبؤة و هي تقارب السنة التي ستظهر من خلال البحث . ويبين أن هناك وحي عظيم سيظهر فجأة وسيجعل الناس في سعادة وهذا ما اخبر به أهل البيت (عليهم السلام) أيضا حيث ذكر حديث متواتر عنهم أن الإمام المهدي ( عليه السلام ) سيظهر علوم و أسرار القرآن الكريم و سيضيف للعلم الموجود حين ظهوره ما نسبته خمسة و عشرين إلى اثنين و سيستخرج كنوز الأرض .





القرن الثالث – النبؤة الحادية و الستين

جماعات كبيرة و طوائف إسلامية

مناوئة للمسيح سوف تنشأ

في العراق و سوريا قرب

نهر الفرات مع قوة من الدبابات.

ستعتبر القانون المسيحي عدوها.



يصف هنا جيوش الإمام المهدي ( عليه السلام ) التي ستحرر العراق و سوريا من جيش السفياني وعن انضمام الناس لجيش الإمام المهدي (عليه السلام) (ذكرت الأحاديث عن أهل البيت (عليهم السلام) إن السفياني سيتنصر و سيعلق الصليب في عنقه و من هنا جاءت عداء الإمام المهدي ( عليه السلام ) للقانون المسيحي . وسيتخذ الإمام المهدي (عليه السلام) مدينة الكوفة مركزا لدولته.



القرن الرابع – النبؤة التاسعة و التسعون



الابن الأكبر لابنة أحد الملوك

سوف يرد السلتين على أعقابهم بعيدا

سوف يستعمل الصواعق, الكثير منها

و بصفوف منتظمة , قليلة و بعيدة,

ثم تدخل في أعماق الغرب .



يصف هنا كيف إن الإمام المهدي ( عليه السلام ) سيقوم بدحر الفرنسيين ( الغرب ) و هزيمتهم وضرب أعماق الغرب (أمريكا) بصواريخ قليلة و بعيدة. و كما ذكرت سابقا بأن المسيحيين دائما يطلقون على النبي أو ( البابا ) لقب الملك و بالعكس . و نجد أن نوستراداموس يتفق مع ما ذهب إليه الشيعة …. ولهذا فهو يقصد هنا (الابن الأكبر لابنة أحد الملــوك) ( أي انه اكبر الأبناء سنا ( و هو ما ينطبق على الإمام المهدي ( عليه السلام ) و الذي يقول به الشيعة على أساس انه اكبر أبناء الرسول ( صلى الله عليه و آله و سلم ) من نسل ابنته فاطمة الزهراء عليها السلام ) .



القرن السادس – النبؤة الثانية و الأربعين

ستسقط سلطة الجمهورية الفرنسية

بسبب القوات الإسلامية .

التي تنهمك في أعمال أخرى

و تبسط سلطانها على إيطاليا .

و التي سيحكمها شخصا يدعي النباهة و الفطنة .

يصف هنا غزو القوات الإسلامية للغرب و إيطاليا ( التي تمثل العالم المسيحي) ومن المحتمل أن أحد قادة المسلمين من جنود الإمام المهدي ( عليه السلام ) سيتولى الحكم فيها .



القرن الأول – النبؤة الثالثة و السبعين

ستهاجم فرنسا من خمسة جوانب

بسبب الإهمال, إيران تستنفر الجزائر

و تونس , ليون , وسيفيل , و برشلونة

تستسلم ولن ينقذها الجيش الإيطالي .



يصف هنا الهجوم الإسلامي على فرنسا و احتلال عدة مدن فيها ولن يستطيع الجيش الإيطالي أي ( القوات المسيحية ) إنقاذها . (ذكر هنا إن إيران هي التي ستعطي الأوامر للقوات الإسلامية في الجزائر وتونس لاحتلال فرنسا ) لأن نوستراداموس يعطي عدة ألقاب للإمام المهدي (عليه السلام ) مثل, العربي , الآسيوي , الإيراني ( لأن أول بوادر ظهوره برايات تخرج من خراسان و التي هي منطقة مشتركة بين أفغانستان وإيران ) كما انه من المعروف أن إيران هي الدولة الوحيدة التي تدين بالمذهب الشيعي الذي ينتسب إليه الإمام المهدي (عليه السلام ) ….



القرن الأول – النبؤة الثامنة عشر



بسبب الإهمال و الفتنة من جانب الفرنسيين

سيكون الطريق مفتوحا أمام المسلمين في البر و البحر

وسيلطخ نهر السين بالدماء,

و مرسيليا ستحجبها السفن و الطائرات .



يصف هنا ضرب القوات الإسلامية للغرب و تقدمهم وكيف أن الطريق سيكون مفتوحا أمامهم و كيف أن المدن الأوربية ستحجبها السفن و الطائرات الحربية من شدة القتال الذي سيقوده الإمام المهدي

( عليه السلام ) ضد قوى الشر في العالم .



القرن التاسع – النبؤة الرابعة و الأربعين



يا أهل جنيف ….غادروا مدينتكم,

عصركم الذهبي يستحيل إلى عصر الحروب.

ومن يثور أو يتمرد على الزعيم الإيراني

فسيقمع حالا قبل هذه الأحداث سترون علامات في السماء.

يصف هنا الغزو الإسلامي لمدينة جنيف (مقر الأمم المتحدة الأوربي ) وهنا أيضا يصف الإمام المهدي (عليه السلام) بالزعيم الإيراني و إن كل من يحاول أن يحارب الإمام المهدي ( عليه السلام ) سيدمر في الحال بواسطة القوات الإسلامية .

القرن الثاني – النبؤة التاسعة و العشرون

سينطلق الزعيم الآسيوي من بلده

ليعبر ابينين و يدخل فرنسا و هو

سيعبر السماء و الأنهار و الجبال

و يرغم كل بلد أن يدفع الضريبة.

يصف هنا كيف أن جيش الإمام المهدي (عليه السلام) سيصل إلى الغرب بواسطة السفن و الطائرات . ثم سيرغم كل الدول الغير إسلامية لدفع الجزية .( و هذا يدل على إن المسلمين لن يقوموا بإجبار النصارى للدخول في الدين الإسلامي بل سيطلب منهم دفع الجزية و هذا عكس ما أقنعهم به اليهود ).





الإنذار – الأربعون



لكونها بذرت الموت , فان البلاد الأوربية

الشرقية السبع ستشهد نتائج و

عواقب مهلكة, و ستغمرها القواصف

و العواصف و الأوبئة و وحشية الأعداء,

الزعيم الآسيوي سيجعل الغربيين

يفرون ,و سيخضع أعدائه السالفين .



يصف هنا ما سيقع للدول أوربا الشرقية من دمار في حربهم ضد الإمام المهدي (عليه السلام) و الذي يصفه هنا أيضا بالزعيم الآسيوي . و كيف إن الأوربيين سيهزمون أمام قواته. وكيف انه سيخضع كل أعدائه.

القرن الثاني – النبؤة الثلاثين

رجل يحيي آلهة هانيبال الجهنمية

رعب البشرية , لا رعب بعدئذ ابدا

كما إن الصحف لا تحكي عما هو أسوء بالماضي

ثم سيأتي إلى الروم من خلال بابل.



هذه من اغرب النبؤات و التي تعطي صورة و وصف لا يقبل الشك حيث يصف هنا كيف إن الإمام المهدي (عليه السلام) سيقوم بأحياء الدين الإسلامي من جديد (هانيبال قائد عسكري من شمال أفريقيا نال بسبب فتوحاته العسكرية شهرة واسعة . ولقد استعار نوستراداموس اسم هذا القائد العربي ) . ويصف كيف أن حروب الإمام المهدي (عليه السلام) لتحرير العالم من الظلم و الاضطهاد ستسبب الهلع للناس من شدة القتال الذي سيستخدم فيه اشد أنواع الأسلحة فتكا بحيث أن الصحف لم تذكر حربا اشد ضراوة منها. ثم يذكر المكان الذي سيتخذه الإمام المهدي (عليه السلام) كمنطلق لحربه ضد الغرب ولقد ذكر إنها من بابل و من المعروف إن منطقة بابل في العراق هي المنطقة التي تقع فيها مدينة الكوفة التي تواترت أحاديث أهل البيت (عليهم السلام) أن الإمام المهدي(عليه السلام) سيتخذ مدينة الكوفة مركزا لدولته و هذا ما يؤيد صحة ما ذكروه .



القرن الأول – النبؤة الخامسة و الخمسين

في الأرض ذات المناخ المعاكس لبابل

ستراق الكثير من الدماء

و ستبدو السماء غير عادلة في البر والبحر

و الجو. طوائف و مجاعة , ممالك , أوبئة , اضطراب.



و هذه أيضا من اغرب النبؤات و التي يصف نوستراداموس هنا كيف إن أي دولة تكون ضد الإمام المهدي ( عليه السلام ) (لان نوستراداموس أطلق على المكان الذي سينطلق منه الإمام المهدي (عليه السلام) اسم ( بابل ) لوجود مدينة الكوفة فيها ) سيراق فيها الكثير من الدماء (بسبب الحرب) ويذكر أن الناس في تلك الدول ستشعر إن الله سبحانه و تعالى تخلى عنهم بحيث أن قواتهم ستدمر في البر و البحر و الجو ونتيجة لهذا ستنتشر الأوبئة و الاضطرابات و المجاعة في هذه الدول .





القرن الأول – النبؤة السابعة و الثمانين



نار مزلزل الأرض من مركز الأرض

سوف تسبب هزات حول المدينة

الجديدة ستتحارب صخرتان عظيمتان

مدة طويلة ثم ستضفي اريثوزا لونا

احمر على نهر جديد.



يصف هنا الحرب التي ستكون بين قوتين عظيمتين هما جيش الإمام المهدي(عليه السلام) و أمريكا وكيف إن من مركز الأرض ( لو وضعت خارطة العالم أمامك و نظرت إلى موقع العراق لوجدت إنه يقع في مركز الأرض ) ستضرب المدينة الجديدة (و هي تطلق على مدينة نيويورك ) ( انظر كلمة (حول) أي ليس في داخل المدينة و لعلها تكون للتحذير من الاستمرار بالمقاومة ( التي يقوم بها أنصار الشيطان من عسكريين و لا ذنب للناس بها ) طبعا هذا يتناسب مع الهدف النبيل الذي جاء به الإمام المهدي ( عليه السلام ) .



القرن السادس – النبؤة السابعة و التسعين

سوف تحترق السماء في خمسة

و أربعون درجة ويدنو الحريق من

المدينة الجديدة و يقفز اللهب الكبير

المنتشر إلى الأعلى مباشرة.

عندما يريدون الحصول على دليل من النورمانديين .



يصف هنا كيف أن انفجارات ستقع بالقرب ( لاحظ هنا كلمة يدنو أيضا ) من مدينة نيويورك و بواسطة القنابل النووية (لان نوستراداموس هنا بالتأكيد يصف انفجارا لقنبلة نووية لأنها كما نعرف نحن عند انفجارها فان لهيبها يقفز إلى الأعلى و بسرعة هائلة مكونة ما يشبه الفطر ) و المعروف إن مدينة نيويورك تقع بين خطي عرض 40 درجة و 45 درجة المتوازيين في الولايات المتحدة.بينما يكون الأمريكيون ينتظرون شيئا من الغرب . طبعا كل هذا سيكون بسبب حرب الإمام المهدي ( عليه السلام ) ضدهم مما تبين سابقا.



القرن الأول –النبؤة الحادية و التسعين



ستبدو الآلهة للبشرية

إنها هي السبب في اندلاع حرب

عظمى و قبل أن تبدو السماء للعيان

خالية من الأسلحة و الصواريخ

سيوقع الضرر الأعظم في اليسار.



يصف هنا كيف أن العالم كله سيعرف أنن الحرب التي سيقوم بها الإمام المهدي (عليه السلام) هي بأمر من الله العلي القدير .و أن قبل نهاية هذه الحرب ستدمر و بقوة الولايات المتحدة الأمريكية ( لأنها هي الواقعة على اليسار ) لأنها هي و بما تمتلك من قوة عظمى ستكون القوة الأكبر ضد الإمام المهدي (عليه السلام) وعند القضاء عليها فأن الحرب ستنتهي آنذاك.



القرن السادس – النبؤة الثالثة و الثلاثون

تمتد يده أخيرا في الآلوس الدموي

سيكون عاجزا عن حماية نفسه في البحر

سوف يخشى اليد العسكرية بين النهرين

وسيجعله الشخص الأسود الغاضب يندم على فعلته.



و هذه من اغرب التنبؤات التي ذكرها نوستراداموس حيث انه ذكر الإمام المهدي ( عليه السلام ) بصورة لا تخطئه و لقد احتار فيها المترجمون للتنبؤات في معنى الاســـم الوارد في النبؤة وذكر اغــلب المترجمين الاسم كما ورد ( الوس ) بل أن البعض منهم قام بحذفه كما في الترجمة الإنكليزية أما في الأصل الفرنسي فهي موجودة . و هنا ترجم المترجم كلمة ((ALUS المذكورة في النبؤة على إنها (الآلوس ) ( مضيفا للكلمة أل التعريف العربية ) و لا يعرف معناها و تركها للتاريخ يحل لغزها حين تحدث تلك الواقعة و أنا سأكشف عن ما قصده نوستراداموس فيها . إن نوستراداموس هنا وكعادته استخدم الجناس التصحيفي أو الترخيم عندما يتعلق الأمر بأسماء أشخاص أو ألقابهم فلقد قام بحذف حرف ( I ) من نهاية الاسم لأننا لو أضفنا هذا الحرف فان الكلمة تصبح (ALUSI ) (الوصي) ويصبح المعنى واضحا جدا حيث إننا نعرف إن لقب الأوصياء يطلق على الأئمة الاثنى عشر من أهل البيت(عليهم السلام) و الإمام المهدي(عليه السلام) هو أحد الأوصياء إذا ممكن أن يطلق عليه (الوصي) و يتفق نوستراداموس هنا أيضا مع ما يذهب إليه الشيعة . و نوستراداموس يصف هنا شخصا معينا قد يكون قائدا عسكريا أو رئيس دولة يحاول أن يقتل الإمام المهدي ( عليه السلام ) أو القضاء على قواته و يكون خائفا من القوة العسكرية (جيش الإمام المهدي ) الموجودة بين النهرين (العراق) ولكن رجلا من جنود الإمام المهدي(عليه السلام) ( و صفه بأنه اسود أي انه ( شيعي ) لان اللباس الأسود يرمز إلى الشيعة أو قد يكون رجلاً عربيا مسلما من أفريقيا (اسود) سيقوم بالقضاء عليه وعلى قواته وهي في البحر ( ربما في أحد الأساطيل الحربية أو في إحدى حاملات الطائرات و يدمرها) .



القرن التاسع – النبؤة الستين



بعمامة سوداء يقاتل البربري ... إراقة دماء

ترتجف دالماشيا, سوف يقيم إسماعيل الكبير جرفه

ضفادع ترتجف تحت العون البرتغالي .



و هذه أيضا من النبؤات الغريبة فهي تتحدث عن رجل يلبس العمامة السوداء و نحن نعرف أن لبس اللون الأسود هو من مميزات لباس الشيعة لأنه لباس أهل البيت ( عليهم السلام ) . و عادة ما يطلق الغربيون على العرب تسمية ( البربر ) و ذكر أسم إسماعيل يؤكد أن المقصود بالمقاتل البربري هو المقاتل العربي ( نسبة إلى نبي الله إسماعيل ( عليه السلام ) الذي ينتسب إليه العرب ) و أن الإمام المهدي ( عليه السلام) سيقيم ( جرفه ) الدولة الإسلامية الكبرى و يذكر أن إراقة دماء ستكون في المدن الغربية و أمريكا . و يصف هنا حالة الخوف التي عليها القوات العسكرية الغربية البحرية ( لأنه يصفهم بالضفادع ) و اعتقد أن هذه القــوات موجودة في كـــندا ( لان أسبانيا تعني أمريكا إذا فالبرتغال تعني هنا كندا ) و الله اعلم .



إن المفسرون الغربيين عند تفسيرهم لتنبؤات نوستراداموس يعترفون بأن هناك حرب ستقع في المستقبل بينهم و بين المسلمين و هم يفسرون الانتصارات الإسلامية التي ذكرها نوستراداموس ستكون في مواقع و أماكن محدودة و لكن النصر النهائي سيكون للغرب و يستندون على أن الدول الإسلامية ضعيفة و متهالكة فلا يمكن أن تصمد في حرب يقودها الغرب ضدهم و يقولون أن المسلمين قد يكسبون في بعض المعارك و لكننا سنكسب الحرب في النهاية بل أن البعض منهم قال أن نوستراداموس قد أخطأ في كتابة هذه التنبؤات . و لكننا لو تمعنا النظر في النبؤات و مما سيكشف عنه في هذا الكتاب سنكتشف أن النصر النهائي سيكون للمسلمين بقيادة الإمام المهدي ( عليه السلام ) إنشاء الله .



منقول

Wednesday, June 15, 2011

Introduction to Oracle 10g's New SQL Tuning Advisor

Come along and see how Oracle has helped us in alleviating the pain associated with tuning SQL.

Gone are the days of staring at countless structures and statistics just attempting to tune a SQL statement. Oracle has once again given us a great tool that will assist us with manual tuning of SQL statements. This tool is called the SQL tuning advisor and it will eat SQL statements for lunch and spit out optimizing techniques and recommendations we can use in our efforts. Who better to tune a SQL statement than the Oracle engine itself? Now, whether it produces the best suggestions all of the time will be up for debate as we all get into the habit of using this tool. However, in theory, since Oracle knows the optimizer, and we can still throw out "intelligent" hints, the advisor should be able to tune better than anyone else should. Well, I suggest we look at it and then you can experiment and let me know the instances where it did not decide the proper execution path or didn't re-write the query any better.

If you were to use Oracle's method of providing the SQL Tuning Advisor with SQL statements, you would have to capture them through the Automatic Database Diagnostic Monitor (ADDM) or through the Automatic Workload Repository AWR. Others of us, who do not want to use OEM or actually want to generate a tuning effort on statements that are working their way through development, will want to provide a user defined tuning set. The interface to the tuning advisor is through a package call DBMS_SQLTUNE. The best way to show its capabilities is to actually just step through the procedures required to produce and analyze a tuning set. The example I am showing here is definitely the simplest to get you up and running with this advisor but should give you a firm jumping off spot to further you investigation.

Creation of a Tuning Task

The first step in using the Tuning Advisor is the creation of a tuning task. The particular example I will be taking you through will only create a tuning task for a single SQL statement, but in theory, you can create tuning sets composed of many SQL statements that can be supplied by you or selected out of the shared pool. For this article, we will follow a very simple example that will take you through the use of the tuning advisor in order to get familiar with it and see how it works and if it provides us with adequate information to assist us in our tuning efforts.

Our Particular Example

The Purpose of our SQL is to join two tables, CUSTOMER & CUST_ORDER to get a count of the number of orders a company has.
These two tables were created with
NO indexes
NO statistics
NO referential integrity
The desired outcome is to have Oracle's Tuning Advisor step us through making modifications to the table structures and SQL to get an optimal execution
After taking the advice of the tuning advisor, we will execute the SQL statement to see if we actually improved the execution of the SQL.
We will iterate through changes to the structures and SQL until we are happy with the outcome.
The first step in using the advisor is to define the tuning task we desire. For our purposes here, we will just be supplying a single SQL statement into the tuning task and thus we should create the following procedure and execute it. The only in-puts to the CREATE_TUNING_TASK that may need explanation are the scope and time_limit variables. Scope can take the form of two values LIMITED & COMPREHENSIVE. The limited scope, basically, only produces a reasonable explain plan so if you want anything more you will find yourself running this advisor in the comprehensive scope mode. Comprehensive will go through iterations and different analysis of the SQL statement looking at statistics and structures to determine alternate access methodologies that can be used as well as point out deficiencies in the structures or SQL provided. The time_limit variable tells the tuning advisor how long to run (in seconds) and analyze your SQL statement.

create_tuning_task_comprehensive

SQL > CREATE or REPLACE PROCEDURE create_tuning_task IS
2 tuning_task VARCHAR2(30);
3 sqltext CLOB;
4 BEGIN
5 sqltext := 'select cust_name,count(*)'
6 ||' from customer, cust_order'
7 ||' where customer.cust_no = cust_order.cust_no'
8 ||' and customer.cust_no = 8'
9 ||' group by cust_name';
10 tuning_task := DBMS_SQLTUNE.CREATE_TUNING_TASK(
11 sql_text => sqltext,
12 user_name => 'SYS',
13 scope => 'COMPREHENSIVE',
14 time_limit => 30,
15 task_name => 'CUST_ORDERS',
16 description => 'Tuning effort for counting customer orders');
17 END create_tuning_task;
18 /

SQL > exec create_tuning_task
PL/SQL procedure successfully completed.

Execution of a Tuning Task

Once you have created the tuning task you need only execute it through the EXECUTE_TUNING_TASK function. This should run for the designated time_limit you specified in the tuning task.

execute_tuning_task

SQL > BEGIN
2 DBMS_SQLTUNE.EXECUTE_TUNING_TASK( task_name => 'CUST_ORDERS' );
3 END;
4 / PL/SQL procedure successfully completed.
Reporting on the tuning task

After you have executed the tuning task, you need only use the REPORT_TUNING_TASK function to get a comprehensive display of what the advisor has found. After looking over a few of these reports, you will soon develop an eye for their format. A header section tells you about the when and how you executed the tuning task. Following that, Oracle then produces a "Findings" section where it details what it has found and supplies recommendations that it may have for you. Then it produces an explain area showing the explain path it has for the current SQL.

report_tuning_task

SQL > SET LONG 1000
SQL > SET LONGCHUNKSIZE 1000
SQL > SET LINESIZE 100
SQL > SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK( 'CUST_ORDERS') FROM DUAL;

GENERAL INFORMATION SECTION
-------------------------------------------------------------------------------
Tuning Task Name : CUST_ORDERS
Scope : COMPREHENSIVE
Time Limit(seconds): 30
Completion Status : COMPLETED
Started at : 07/18/2004 17:17:52
Completed at : 07/18/2004 17:18:11

-------------------------------------------------------------------------------
SQL ID : a1s4nzcnjc70f
SQL Text: select cust_name,count(*) from customer, cust_order where
customer.cust_no = cust_order.cust_no and customer.cust_no = 8
group by cust_name

-------------------------------------------------------------------------------
FINDINGS SECTION (2 findings)
-------------------------------------------------------------------------------

1- Statistics Finding
---------------------
Table "SYS"."CUST_ORDER" was not analyzed.

Recommendation
--------------
Consider collecting optimizer statistics for this table.
execute dbms_stats.gather_table_stats(ownname => 'SYS', tabname =>
'CUST_ORDER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
method_opt => 'FOR ALL COLUMNS SIZE AUTO')

Rationale
---------
The optimizer requires up-to-date statistics for the table in order to
select a good execution plan.

2- Statistics Finding
---------------------
Table "SYS"."CUSTOMER" was not analyzed.

Recommendation
--------------
Consider collecting optimizer statistics for this table.
execute dbms_stats.gather_table_stats(ownname => 'SYS', tabname =>
'CUSTOMER', estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
method_opt => 'FOR ALL COLUMNS SIZE AUTO')

Rationale
---------
The optimizer requires up-to-date statistics for the table in order to
select a good execution plan.

-------------------------------------------------------------------------------
EXPLAIN PLANS SECTION
-------------------------------------------------------------------------------
1- Original
-----------

------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 183K| 13M| 49567 (2)| 00:09:55 |
| 1 | SORT GROUP BY | | 183K| 13M| 49567 (2)| 00:09:55 |
| 2 | MERGE JOIN CARTESIAN| | 183K| 13M| 49553 (1)| 00:09:55 |
| 3 | TABLE ACCESS FULL | CUSTOMER | 177 | 11505 | 49 (0)| 00:00:01 |
| 4 | BUFFER SORT | | 1034 | 13442 | 49518 (2)| 00:09:55 |
| 5 | TABLE ACCESS FULL | CUST_ORDER | 1034 | 13442 | 279 (2)| 00:00:04 |
------------------------------------------------------------------------------------
Initial Performance

This is the current real-time experienced performance of our example SQL that we are providing to the tuning advisor. As you can see, the execution plan is what the advisor spit out and we are doing quit a bit of physical and logical reads. Moreover, the recursive calls and sorts could hopefully be tuned.

Initial Performance

SQL > select cust_name,count(*)
2 from customer, cust_order
3 where customer.cust_no = cust_order.cust_no
4 and customer.cust_no = 8
5 group by cust_name;
Elapsed: 00:00:02.81

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=649 Card=171805 Bytes=13400790)
1 0 SORT (GROUP BY) (Cost=649 Card=171805 Bytes=13400790)
2 1 MERGE JOIN (CARTESIAN) (Cost=635 Card=171805 Bytes=13400790)
3 2 TABLE ACCESS (FULL) OF 'CUSTOMER' (TABLE) (Cost=51 Card=2 Bytes=130)
4 2 BUFFER (SORT) (Cost=598 Card=71961 Bytes=935493)
5 4 TABLE ACCESS (FULL) OF 'CUST_ORDER' (TABLE) (Cost=292 Card=71961 Bytes=935493)

Statistics
----------------------------------------------------------
895 recursive calls
0 db block gets
1772 consistent gets
1160 physical reads
0 redo size
465 bytes sent via SQL*Net to client
508 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
12 sorts (memory)
0 sorts (disk)
1 rows processed


Continuation of Tuning Task

The first suggestion given by the tuning advisor was to gather statistics on the two structures that we are joining as it can only produce valid analysis and suggestions if it has them. We subsequently cut and past the calls to GATHER_TABLE_STATS, it has given us.

SQL > execute dbms_stats.gather_table_stats(
ownname => 'SYS',
tabname => 'CUST_ORDER',
estimate_percent =>
DBMS_STATS.AUTO_SAMPLE_SIZE,
method_opt =>
'FOR ALL COLUMNS SIZE AUTO');
PL/SQL procedure successfully completed.

SQL > execute dbms_stats.gather_table_stats(
ownname => 'SYS',
tabname => 'CUSTOMER',
estimate_percent =>
DBMS_STATS.AUTO_SAMPLE_SIZE,
method_opt =>
'FOR ALL COLUMNS SIZE AUTO');
PL/SQL procedure successfully completed.
In order to re-execute the tuning task, we must first reset the results we have gathered. This is done by a simple call to RESET_TUNING_TASK.

reset_tuning_task

SQL> BEGIN
2 DBMS_SQLTUNE.RESET_TUNING_TASK
( task_name => 'CUST_ORDERS' );
3 END;
4 /

PL/SQL procedure successfully completed.
We then call the EXECUTE_TUNING_TASK function.

execute_tuning_task

SQL > BEGIN
2 DBMS_SQLTUNE.EXECUTE_TUNING_TASK( task_name => 'CUST_ORDERS' );
3 END;
4 /
PL/SQL procedure successfully completed.
Then we produce the report to see if anything has gotten better.

report_tuning_task

SQL > SET LONG 1000
SQL > SET LONGCHUNKSIZE 1000
SQL > SET LINESIZE 100
SQL > SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK( 'CUST_ORDERS') FROM DUAL;

GENERAL INFORMATION SECTION
-------------------------------------------------------------------------------
Tuning Task Name : CUST_ORDERS
Scope : COMPREHENSIVE
Time Limit(seconds): 30
Completion Status : COMPLETED
Started at : 07/18/2004 18:13:51
Completed at : 07/18/2004 18:13:55

-------------------------------------------------------------------------------
SQL ID : a1s4nzcnjc70f
SQL Text: select cust_name,count(*) from customer, cust_order where
customer.cust_no = cust_order.cust_no and customer.cust_no = 8
group by cust_name

-------------------------------------------------------------------------------
FINDINGS SECTION (1 finding)
-------------------------------------------------------------------------------

1- Restructure SQL finding (see plan 1 in explain plans section)
----------------------------------------------------------------
An expensive cartesian product operation was found at line ID 2 of the
execution plan.

Recommendation
--------------
Consider removing the disconnected table or view from this statement or
add a join condition which refers to it.

Rationale
---------
A cartesian product should be avoided whenever possible because it is an
expensive operation and might produce a large amount of data.

-------------------------------------------------------------------------------
EXPLAIN PLANS SECTION
-------------------------------------------------------------------------------

1- Original
-----------

------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 18 | 347 (6)| 00:00:05 |
| 1 | SORT GROUP BY | | 1 | 18 | 347 (6)| 00:00:05 |
| 2 | MERGE JOIN CARTESIAN| | 68508 | 1204K| 342 (5)| 00:00:05 |
| 3 | TABLE ACCESS FULL | CUSTOMER | 1 | 15 | 50 (2)| 00:00:01 |
| 4 | BUFFER SORT | | 68508 | 200K| 297 (7)| 00:00:04 |
| 5 | TABLE ACCESS FULL | CUST_ORDER | 68508 | 200K| 291 (5)| 00:00:04 |
Performance of putting statistics on the tables

SQL > select cust_name,count(*)
2 from customer, cust_order
3 where customer.cust_no = cust_order.cust_no
4 and customer.cust_no = 8
5 group by cust_name;
Elapsed: 00:00:01.67

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=348 Card=1 Bytes=18)
1 0 SORT (GROUP BY) (Cost=348 Card=1 Bytes=18)
2 1 MERGE JOIN (CARTESIAN) (Cost=343 Card=64969 Bytes=1169442)
3 2 TABLE ACCESS (FULL) OF 'CUSTOMER' (TABLE) (Cost=51 Card=1 Bytes=15)
4 2 BUFFER (SORT) (Cost=298 Card=64969 Bytes=194907)
5 4 TABLE ACCESS (FULL) OF 'CUST_ORDER' (TABLE) (Cost=292 Card=64969 Bytes=194907)

Statistics
----------------------------------------------------------
328 recursive calls
0 db block gets
1530 consistent gets
1487 physical reads
0 redo size
465 bytes sent via SQL*Net to client
508 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
7 sorts (memory)
0 sorts (disk)
1 rows processed
In this particular report, you can see that our FINDINGS section has been reduced and now we only have one. Also, note that while the performance of the SQL statement changes slightly it is doing the same amount of work as without the statistics. The tuning advisor report is telling us that we have a Cartesian product within the explain plan and that we should try to reduce it. I was really hoping that the advisor would make suggestions and point out that these two structures did not have a primary key or where not indexed. Just by looking at the SQL statement, a common observer would think there would be indexes on the CUST_NO field. Since I know there are not any indexes on these structures, I decide to put them in place by the following DDL and see what the advisor tells me.

Creation of indexes for our two tables

SQL > create index customer_ix01 on customer (cust_no);
Index created.

SQL > create index cust_order_ix01 on cust_order (cust_no);
Index created.
After creating the indexes and running the RESET_TUNING_TASK, EXECUTE_TUNING_TASK and REPORT_TUNING_TASK, we get the following tuning report. I was really hoping to get rid of that Cartesian product operation as I felt that Oracle would know now that I was in fact joining the tables properly. In addition, if you look at the performance statistics generated after running the SQL statement you can see that the performance is quite good and most of us would stop at this point. But hey, Oracle knows better, right?

report_tuning_task

SQL > SET LONG 1000
SQL > SET LONGCHUNKSIZE 1000
SQL > SET LINESIZE 100
SQL > SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK( 'CUST_ORDERS') FROM DUAL;

GENERAL INFORMATION SECTION
-------------------------------------------------------------------------------
Tuning Task Name : CUST_ORDERS
Scope : COMPREHENSIVE
Time Limit(seconds): 30
Completion Status : COMPLETED
Started at : 07/18/2004 19:47:34
Completed at : 07/18/2004 19:47:38

-------------------------------------------------------------------------------
SQL ID : a1s4nzcnjc70f
SQL Text: select cust_name,count(*) from customer, cust_order where
customer.cust_no = cust_order.cust_no and customer.cust_no = 8
group by cust_name

-------------------------------------------------------------------------------
FINDINGS SECTION (1 finding)
-------------------------------------------------------------------------------

1- Restructure SQL finding (see plan 1 in explain plans section)
----------------------------------------------------------------
An expensive cartesian product operation was found at line ID 2 of the
execution plan.

Recommendation
--------------
Consider removing the disconnected table or view from this statement or
add a join condition which refers to it.

Rationale
---------
A cartesian product should be avoided whenever possible because it is an
expensive operation and might produce a large amount of data.

-------------------------------------------------------------------------------
EXPLAIN PLANS SECTION
-------------------------------------------------------------------------------

1- Original
-----------

-------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 18 | 136 (5)| 00:00:02 |
| 1 | SORT GROUP BY | | 1 | 18 | 136 (5)| 00:00:02 |
| 2 | MERGE JOIN CARTESIAN | | 64969 | 1142K| 131 (1)| 00:00:02 |
| 3 | TABLE ACCESS BY INDEX ROWID| CUSTOMER | 1 | 15 | 2 (0)| 00:00:01 |
| 4 | INDEX RANGE SCAN | CUSTOMER_IX01 | 1 | | 1 (0)| 00:00:01 |
| 5 | BUFFER SORT | | 64969 | 190K| 134 (5)| 00:00:02 |
| 6 | INDEX RANGE SCAN | CUST_ORDER_IX01 | 64969 | 190K| 129 (1)| 00:00:02 |
Performance after adding indexes

SQL > select cust_name,count(*)
2 from customer, cust_order
3 where customer.cust_no = cust_order.cust_no
4 and customer.cust_no = 8
5 group by cust_name;

Elapsed: 00:00:01.16

Execution Plan
-------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=137 Card=1 Bytes=18)
1 0 SORT (GROUP BY) (Cost=137 Card=1 Bytes=18)
2 1 MERGE JOIN (CARTESIAN) (Cost=131 Card=64969 Bytes=1169442)
3 2 TABLE ACCESS (BY INDEX ROWID) OF 'CUSTOMER' (TABLE) (Cost=2 Card=1 Bytes=15)
4 3 INDEX (RANGE SCAN) OF 'CUSTOMER_IX01' (INDEX) (Cost=1 Card=1)
5 2 BUFFER (SORT) (Cost=135 Card=64969 Bytes=194907)
6 5 INDEX (RANGE SCAN) OF 'CUST_ORDER_IX01' (INDEX) (Cost=129 Card=64969 Bytes=194907)

Statistics
----------------------------------------------------------
378 recursive calls
0 db block gets
193 consistent gets
137 physical reads
0 redo size
465 bytes sent via SQL*Net to client
508 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
11 sorts (memory)
0 sorts (disk)
1 rows processed
The only way I could think of to eliminate that annoying Cartesian message was to give Oracle a bit more information in the SQL statement. I did this by adding "and cust_order.cust_no = 8" to the SQL statement. This should take away all doubt about what I am trying to do even though I have linked the CUST_ORDER.CUST_NO to CUSTOMER.CUST_NO columns. Just remember that if you want to change the SQL, you must go back and re-do all the steps here from creation, execution, and report with the added call to a DROP_TUNING_TASK.

drop_tuning_task

exec dbms_sqltune.drop_tuning_task('CUST_ORDERS')
After recreating the tuning task and producing the report, here is what we got. Good, we got rid of the Cartesian warning and the advisor tells us that there are no more recommendations we can do. Looking at the actual performance of the SQL statement, we can see that the only change was a reduction of the number of sorts.

report_tuning_task

SQL > SET LONG 1000
SQL > SET LONGCHUNKSIZE 1000
SQL > SET LINESIZE 100
SQL > SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK( 'CUST_ORDERS') FROM DUAL;

GENERAL INFORMATION SECTION
------------------------------------------------------
Tuning Task Name : CUST_ORDERS
Scope : COMPREHENSIVE
Time Limit(seconds): 30
Completion Status : COMPLETED
Started at : 07/18/2004 19:56:06
Completed at : 07/18/2004 19:56:09
------------------------------------------------------
SQL ID : 9xdx7wamdfqd6

DBMS_SQLTUNE.REPORT_TUNING_TASK('CUST_ORDERS')
------------------------------------------------------
SQL Text: select cust_name,count(*) from customer, cust_order where
customer.cust_no = cust_order.cust_no and customer.cust_no = 8
and cust_order.cust_no = 8 group by cust_name
-------------------------------------------------------
There are no recommendations to improve the statement.
-------------------------------------------------------
Performance after addition of "and cust_order.cust_no = 8

SQL > select cust_name,count(*)
2 from customer, cust_order
3 where customer.cust_no = cust_order.cust_no
4 and customer.cust_no = 8
5 and cust_order.cust_no = 8
6 group by cust_name;
Elapsed: 00:00:00.92

Execution Plan
----------------------------------------------------------
0 SELECT STATEMENT Optimizer=ALL_ROWS (Cost=132 Card=1 Bytes=18)
1 0 SORT (GROUP BY) (Cost=132 Card=1 Bytes=18)
2 1 NESTED LOOPS (Cost=131 Card=1 Bytes=18)
3 2 TABLE ACCESS (BY INDEX ROWID) OF 'CUSTOMER' (TABLE) (Cost=2 Card=1 Bytes=15)
4 3 INDEX (RANGE SCAN) OF 'CUSTOMER_IX01' (INDEX) (Cost=1 Card=1)
5 2 INDEX (RANGE SCAN) OF 'CUST_ORDER_IX01' (INDEX) (Cost=129 Card=1 Bytes=3)

Statistics
----------------------------------------------------------
378 recursive calls
0 db block gets
193 consistent gets
137 physical reads
0 redo size
465 bytes sent via SQL*Net to client
508 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
10 sorts (memory)
0 sorts (disk)
1 rows processed
While it may have seemed a bit long-winded to get to our conclusion and optimal SQL statement tuned, we did get there. Moreover, Oracle helped us in a way that was not available to us before. Now even if you are not the greatest SQL coder on the planet, you can get recommendations from the expert, Oracle.



By James Koopmann

Tuesday, June 14, 2011

Quickly Improve SQL Performance with dbms_stats

Oracle Tips by Burleson Consulting

Updated for 11g on September 17, 2010

The old fashioned “analyze table” and dbms_utility methods for generating CBO statistics are obsolete and somewhat dangerous to SQL performance. This is because the cost-based SQL Optimizer (CBO) relies on the quality of the statistics to choose the best execution plan for all SQL statements. The dbms_stats utility does a far better job in estimating statistics, especially for large partitioned tables, and the better stats results in faster SQL execution plans.

Let’s see how dbms_stats works. It’s easy! Here is a sample execution of dbms_stats with the options clause:

exec dbms_stats.gather_schema_stats( -
ownname => 'SCOTT', -
estimate_percent => dbms_stats.auto_sample_size, -
method_opt => 'for all columns size repeat', -
degree => 34 -
)
When the options clause is specified you may specify GATHER options. When GATHER AUTO is specified, the only additional valid parameters are ownname, stattab, statid, objlist and statown; all other parameter settings are ignored.

exec dbms_stats.gather_schema_stats( -
ownname => 'SCOTT', -
options => 'GATHER AUTO'
)
There are several values for the options parameter that we need to know about:

gather – re-analyzes the whole schema.

gather empty – Only analyze tables that have no existing statistics.

gather stale – Only re-analyze tables with more than 10% modifications (inserts, updates, deletes).

gather auto – This will re-analyze objects which currently have no statistics and objects with stale statistics. Using gather auto is like combining gather stale and gather empty.

exec dbms_stats.gather_schema_stats( ownname => 'BILIING', options => 'gather auto' );

Note that both gather stale and gather auto require monitoring. If you issue the “alter table xxx monitoring” command, Oracle tracks changed tables with the dba_tab_modifications view. Below we see that the exact number of inserts, updates and deletes are tracked since the last analysis of statistics.

SQL> desc dba_tab_modifications;

Name Type
--------------------------------
TABLE_OWNER VARCHAR2(30)
TABLE_NAME VARCHAR2(30)
PARTITION_NAME VARCHAR2(30)
SUBPARTITION_NAME VARCHAR2(30)
INSERTS NUMBER
UPDATES NUMBER
DELETES NUMBER
TIMESTAMP DATE
TRUNCATED VARCHAR2(3)
The most interesting of these options is the gather stale option. Because all statistics will become stale quickly in a robust OLTP database, we must remember the rule for gather stale is > 10% row change (based on num_rows at statistics collection time).


Hence, almost every table except read-only tables will be re-analyzed with the gather stale option. Hence, the gather stale option is best for systems that are largely read-only. For example, if only 5% of the database tables get significant updates, then only 5% of the tables will be re-analyzed with the “gather stale” option.

The CASCADE Option

When analyzing specific tables, the cascade option can be used to analyze all related indexes.

The Oracle documentation notes that using the cascade option gathers statistics on the table, plus all indexes for the target table. Using this option is equivalent to running gather_table_stats plus running gather_index_stats for each index on the table. If you always want indexes analyzed when running gather_table_stats you can use the set_database_prefs, set_global_prefs, or set_table_prefs, to always include indexes when gather_table_stats is executed.

exec dbms_stats.gather_table_stats( -
ownname => 'PERFSTAT', -
tabname => ’STATS$SNAPSHOT’ -
estimate_percent => dbms_stats.auto_sample_size, -
method_opt => 'for all columns size skewonly', -
cascade => true, -
degree => 7 -
)
The DEGREE Option

Note that you can also parallelize the collection of statistics because the CBO does full-table and full-index scans. When you set degree=x, Oracle will invoke parallel query slave processes to speed up table access. Degree is usually about equal to the number of CPUs, minus 1 (for the OPQ query coordinator).

Automating Sample Size with dbms_stats

Now that we see how the dbms_stats options works, get see how to specify the sample size for dbms_stats. The following estimate_percent argument is a new way to allow Oracle’s dbms_stats to automatically estimate the “best” percentage of a segment to sample when gathering statistics:

estimate_percent => dbms_stats.auto_sample_size

You can verify the accuracy of the automatic statistics sampling by looking at the dba_tables sample_size column. It is interesting to note that Oracle chooses between 5% to 20% for a sample_size when using automatic sampling.

In our next installment we will look at automatics the collection of histogram data from dbms_stats.

11g Update: Oracle guru Guy Harrison also offers this advice for 11g statistics collection on function-based index columns.

In 11g, I think there are two other ways to get statistics collected for indexed expressions:

1) Collect extended statistics directly on the expression. So for instance, if we had a function SALES_CATEGORY, we might do this:
DBMS_STATS.gather_table_stats
(ownname => USER,
tabname => ‘SALES’,
method_opt => ‘FOR ALL COLUMNS FOR COLUMNS
(sale_category(amount_sold))’ );

2) Create a virtual column on the expression, then index that column. So for the same example as above we might create the following virtual column, then index the column and collect stats as usual:
ALTER TABLE
SALES
ADD
sales_category
GENERATED ALWAYS AS
(sale_category(amount_sold));

I think I like the first method better, because the statistics will still exist even if the index is dropped and – unlike the second approach – it doesn’t change the logical structure of the table.
Arup Nanda has a great article on extended statistics with dbms_stats, specialty histogram analysis using function-based columnar data:

Next, re-gather statistics on the table and collect the extended statistics on the expression upper(cust_name).

begin
dbms_stats.gather_table_stats (
ownname => 'ARUP',
tabname => 'CUSTOMERS',
method_opt => 'for all columns size skewonly for columns (upper(cust_name))'
);
end;

Alternatively you can define the column group as part of the gather statistics command.
You do that by placing these columns in the method_opt parameter of the gather_table_stats procedure in dbms_stats as shown below:

begin
dbms_stats.gather_table_stats (
ownname => 'ARUP',
tabname => 'BOOKINGS',
estimate_percent=> 100,
method_opt => 'FOR ALL COLUMNS SIZE SKEWONLY FOR COLUMNS(HOTEL_ID,RATE_CATEGORY)',
cascade => true
);
end;

Monday, June 13, 2011

Auditing Enhancements (DBMS_AUDIT_MGMT) in Oracle Database 11g Release 2

Oracle 11g Release 1 turned on auditng by default for the first time. Oracle 11g Release 2 now allows better management of the audit trail using the DBMS_AUDIT_MGMT package.

Moving the Database Audit Trail to a Different Tablespace

The SET_AUDIT_TRAIL_LOCATION procedure allows you to alter the location of the standard and/or fine-grained database audit trail. It does not currently allow the alteration of the OS audit trail, although the documentation suggests this may happen in future. The procedure accepts two parameters:
AUDIT_TRAIL_TYPE: They type of audit trail that is to be moved.
AUDIT_TRAIL_LOCATION_VALUE: The tablespace the audit trail tables should be moved to.
The AUDIT_TRAIL_TYPE parameter is specified using one of three constants:
DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: Standard audit trail (AUD$).
DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: Fine-grained audit trail (FGA_LOG$).
DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD: Both standard and fine-grained audit trails.
Let's see this in action. First check the current location of the audit trail tables.
CONN / AS SYSDBA

SELECT table_name, tablespace_name
FROM dba_tables
WHERE table_name IN ('AUD$', 'FGA_LOG$')
ORDER BY table_name;

TABLE_NAME TABLESPACE_NAME
------------------------------ ------------------------------
AUD$ SYSTEM
FGA_LOG$ SYSTEM

SQL>
Next, create a new tablespace to hold the audit trail.
CREATE TABLESPACE audit_aux
DATAFILE '/u01/app/oracle/oradata/DB11G/audit_aux01.dbf'
SIZE 1M AUTOEXTEND ON NEXT 1M;
Then we move the standard audit trail to the new tablespace.
BEGIN
DBMS_AUDIT_MGMT.set_audit_trail_location(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
audit_trail_location_value => 'AUDIT_AUX');
END;
/

PL/SQL procedure successfully completed.

SQL>

-- Check locations.
SELECT table_name, tablespace_name
FROM dba_tables
WHERE table_name IN ('AUD$', 'FGA_LOG$')
ORDER BY table_name;

TABLE_NAME TABLESPACE_NAME
------------------------------ ------------------------------
AUD$ AUDIT_AUX
FGA_LOG$ SYSTEM

SQL>
Next we move the fine-grained audit trail.
BEGIN
DBMS_AUDIT_MGMT.set_audit_trail_location(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD,
audit_trail_location_value => 'AUDIT_AUX');
END;
/

PL/SQL procedure successfully completed.

SQL>

-- Check locations.
SELECT table_name, tablespace_name
FROM dba_tables
WHERE table_name IN ('AUD$', 'FGA_LOG$')
ORDER BY table_name;

TABLE_NAME TABLESPACE_NAME
------------------------------ ------------------------------
AUD$ AUDIT_AUX
FGA_LOG$ AUDIT_AUX

SQL>
Finally, we move them both back to their original location in a single step.
BEGIN
DBMS_AUDIT_MGMT.set_audit_trail_location(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD,
audit_trail_location_value => 'SYSTEM');
END;
/

PL/SQL procedure successfully completed.

SQL>

-- Check locations.
SELECT table_name, tablespace_name
FROM dba_tables
WHERE table_name IN ('AUD$', 'FGA_LOG$')
ORDER BY table_name;

TABLE_NAME TABLESPACE_NAME
------------------------------ ------------------------------
AUD$ SYSTEM
FGA_LOG$ SYSTEM

SQL>
The AUDIT_AUX tablespace is no longer used so we can drop it.
DROP TABLESPACE audit_aux;
The time it takes to move the audit trail tables depends on the amount of data currently in the audit trail tables, and the resources available on your system.
Controlling the Size and Age of the OS Audit Trail

The SET_AUDIT_TRAIL_PROPERTY procedure allows you to set the maximum size and/or age of the OS audit trail files. The procedure can set parameters for several purposes, but I will restrict the discussion to only those relevant to this section. A full list of the constants available can be found here.

The procedure accepts three parameters:
AUDIT_TRAIL_TYPE: The type of audit trail to be modified (AUDIT_TRAIL_OS, AUDIT_TRAIL_XML or AUDIT_TRAIL_FILES).
AUDIT_TRAIL_PROPERTY: The name of the property to be set (OS_FILE_MAX_SIZE or OS_FILE_MAX_AGE).
AUDIT_TRAIL_PROPERTY_VALUE: The required value for the property.
To check the current settings query the DBA_AUDIT_MGMT_CONFIG_PARAMS view.
COLUMN parameter_name FORMAT A30
COLUMN parameter_value FORMAT A20
COLUMN audit_trail FORMAT A20

SELECT *
FROM dba_audit_mgmt_config_params
WHERE parameter_name LIKE 'AUDIT FILE MAX%';

PARAMETER_NAME PARAMETER_VALUE AUDIT_TRAIL
------------------------------ -------------------- --------------------
AUDIT FILE MAX SIZE 10000 OS AUDIT TRAIL
AUDIT FILE MAX SIZE 10000 XML AUDIT TRAIL
AUDIT FILE MAX AGE 5 OS AUDIT TRAIL
AUDIT FILE MAX AGE 5 XML AUDIT TRAIL

SQL>
These defaults mean that OS and XML audit trail files will grow to a maximum of 10,000Kb, at which point a new file will be created. In addition, files older than 5 days will not be written to any more, even if they are below the maximum file size. Instead, a new file will be created and written to. Here are some examples of changing the settings.

-- Set the Maximum size of OS audit files to 15,000Kb.
BEGIN
DBMS_AUDIT_MGMT.set_audit_trail_property(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_OS,
audit_trail_property => DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE,
audit_trail_property_value => 15000);
END;
/

SELECT *
FROM dba_audit_mgmt_config_params
WHERE parameter_name LIKE 'AUDIT FILE MAX%';

PARAMETER_NAME PARAMETER_VALUE AUDIT_TRAIL
------------------------------ -------------------- --------------------
AUDIT FILE MAX SIZE 15000 OS AUDIT TRAIL
AUDIT FILE MAX SIZE 10000 XML AUDIT TRAIL
AUDIT FILE MAX AGE 5 OS AUDIT TRAIL
AUDIT FILE MAX AGE 5 XML AUDIT TRAIL

SQL>


-- Set the Maximum age of XML audit files to 10 days.
BEGIN
DBMS_AUDIT_MGMT.set_audit_trail_property(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_XML,
audit_trail_property => DBMS_AUDIT_MGMT.OS_FILE_MAX_AGE,
audit_trail_property_value => 10);
END;
/

SELECT *
FROM dba_audit_mgmt_config_params
WHERE parameter_name LIKE 'AUDIT FILE MAX%';

PARAMETER_NAME PARAMETER_VALUE AUDIT_TRAIL
------------------------------ -------------------- --------------------
AUDIT FILE MAX SIZE 15000 OS AUDIT TRAIL
AUDIT FILE MAX SIZE 10000 XML AUDIT TRAIL
AUDIT FILE MAX AGE 5 OS AUDIT TRAIL
AUDIT FILE MAX AGE 10 XML AUDIT TRAIL

SQL>
The CLEAR_AUDIT_TRAIL_PROPERTY procedure can be used to remove the size and age restrictions, or reset them to the default values. Setting the USE_DEFAULT_VALUES parameter value to FALSE removes the restrictions, while setting it to TRUE returns the restriction to the default value.
-- Reset the max size default values for both OS and XML audit file.
BEGIN
DBMS_AUDIT_MGMT.clear_audit_trail_property(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_FILES,
audit_trail_property => DBMS_AUDIT_MGMT.OS_FILE_MAX_SIZE,
use_default_values => TRUE );
END;
/

SELECT *
FROM dba_audit_mgmt_config_params
WHERE parameter_name LIKE 'AUDIT FILE MAX%';

PARAMETER_NAME PARAMETER_VALUE AUDIT_TRAIL
------------------------------ -------------------- --------------------
AUDIT FILE MAX SIZE 10000 OS AUDIT TRAIL
AUDIT FILE MAX SIZE 10000 XML AUDIT TRAIL
AUDIT FILE MAX AGE 5 OS AUDIT TRAIL
AUDIT FILE MAX AGE 10 XML AUDIT TRAIL

SQL>

-- Remove the max age restriction for both OS and XML audit file.
BEGIN
DBMS_AUDIT_MGMT.clear_audit_trail_property(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_FILES,
audit_trail_property => DBMS_AUDIT_MGMT.OS_FILE_MAX_AGE,
use_default_values => FALSE );
END;
/

SELECT *
FROM dba_audit_mgmt_config_params
WHERE parameter_name LIKE 'AUDIT FILE MAX%';

PARAMETER_NAME PARAMETER_VALUE AUDIT_TRAIL
------------------------------ -------------------- --------------------
AUDIT FILE MAX SIZE 10000 OS AUDIT TRAIL
AUDIT FILE MAX SIZE 10000 XML AUDIT TRAIL
AUDIT FILE MAX AGE NOT SET OS AUDIT TRAIL
AUDIT FILE MAX AGE NOT SET XML AUDIT TRAIL

SQL>

-- Reset the max age default values for both OS and XML audit file.
BEGIN
DBMS_AUDIT_MGMT.clear_audit_trail_property(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_FILES,
audit_trail_property => DBMS_AUDIT_MGMT.OS_FILE_MAX_AGE,
use_default_values => TRUE );
END;
/

SELECT *
FROM dba_audit_mgmt_config_params
WHERE parameter_name LIKE 'AUDIT FILE MAX%';

PARAMETER_NAME PARAMETER_VALUE AUDIT_TRAIL
------------------------------ -------------------- --------------------
AUDIT FILE MAX SIZE 10000 OS AUDIT TRAIL
AUDIT FILE MAX SIZE 10000 XML AUDIT TRAIL
AUDIT FILE MAX AGE 5 OS AUDIT TRAIL
AUDIT FILE MAX AGE 5 XML AUDIT TRAIL

SQL>
Purging Audit Trail Records

As with previous versions, you can manually delete records from the AUD$ and FGA_LOG$ tables and manually delete OS audit files from the file system, but DBMS_AUDIT_MGMT package gives you some new and safer mechanisms for maintaining the audit trail.

Note. If you are using Oracle Audit Vault, use that to manage your audit trail, not this functionality.
Initializing the Management Infrastructure

Before you can purge the database audit trail you must perform a one-time initialization of the audit management infrastructure. This is done using the INIT_CLEANUP procedure. The procedure accepts two parameters:
AUDIT_TRAIL_TYPE: The audit trail to be initialized (Constants).
DEFAULT_CLEANUP_INTERVAL: The default interval in hours, after which the cleanup procedure should be called again (1-999).
Note. The documentation seems to be incorrect about 2 points.
It claims that initializing the database audit trails move the AUD$ and FGA_LOG$ tables from the SYSTEM tablespace to the SYSAUX tablespace, unless they have already been moved out of the SYSTEM tablespace. This doesn't seem to be the case as the example below will show. Even though it doesn't happen automatically, it makes sense to move the audit tables into the SYSAUX tablespace or their own dedicated tablespace.
It claims it is not necessary to initialize the OS audit trails, yet in the example below you can clearly see the default cleanup intervals being set by the initialization process.
The following code checks the current parameter settings, initializes the audit management infrastructure for all audit trails with a default interval of 12 hours and rechecks the settings.
COLUMN parameter_name FORMAT A30
COLUMN parameter_value FORMAT A20
COLUMN audit_trail FORMAT A20

SELECT * FROM dba_audit_mgmt_config_params;

PARAMETER_NAME PARAMETER_VALUE AUDIT_TRAIL
------------------------------ -------------------- --------------------
DB AUDIT TABLESPACE SYSTEM STANDARD AUDIT TRAIL
DB AUDIT TABLESPACE SYSTEM FGA AUDIT TRAIL
AUDIT FILE MAX SIZE 10000 OS AUDIT TRAIL
AUDIT FILE MAX SIZE 10000 XML AUDIT TRAIL
AUDIT FILE MAX AGE 5 OS AUDIT TRAIL
AUDIT FILE MAX AGE 5 XML AUDIT TRAIL
DB AUDIT CLEAN BATCH SIZE 10000 STANDARD AUDIT TRAIL
DB AUDIT CLEAN BATCH SIZE 10000 FGA AUDIT TRAIL
OS FILE CLEAN BATCH SIZE 1000 OS AUDIT TRAIL
OS FILE CLEAN BATCH SIZE 1000 XML AUDIT TRAIL

SQL>

BEGIN
DBMS_AUDIT_MGMT.init_cleanup(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL,
default_cleanup_interval => 12 /* hours */);
END;
/

PL/SQL procedure successfully completed.

SQL>

SELECT * FROM dba_audit_mgmt_config_params;

PARAMETER_NAME PARAMETER_VALUE AUDIT_TRAIL
------------------------------ -------------------- --------------------
DB AUDIT TABLESPACE SYSTEM STANDARD AUDIT TRAIL
DB AUDIT TABLESPACE SYSTEM FGA AUDIT TRAIL
AUDIT FILE MAX SIZE 10000 OS AUDIT TRAIL
AUDIT FILE MAX SIZE 10000 XML AUDIT TRAIL
AUDIT FILE MAX AGE 5 OS AUDIT TRAIL
AUDIT FILE MAX AGE 5 XML AUDIT TRAIL
DB AUDIT CLEAN BATCH SIZE 10000 STANDARD AUDIT TRAIL
DB AUDIT CLEAN BATCH SIZE 10000 FGA AUDIT TRAIL
OS FILE CLEAN BATCH SIZE 1000 OS AUDIT TRAIL
OS FILE CLEAN BATCH SIZE 1000 XML AUDIT TRAIL
DEFAULT CLEAN UP INTERVAL 12 OS AUDIT TRAIL

PARAMETER_NAME PARAMETER_VALUE AUDIT_TRAIL
------------------------------ -------------------- --------------------
DEFAULT CLEAN UP INTERVAL 12 STANDARD AUDIT TRAIL
DEFAULT CLEAN UP INTERVAL 12 FGA AUDIT TRAIL
DEFAULT CLEAN UP INTERVAL 12 XML AUDIT TRAIL
Notice that the 'DB AUDIT TABLESPACE' for the database audit trails are unchanged and the 'DEFAULT CLEAN UP INTERVAL' for all four audit trails has been set.

The current initialization status of a specific audit trail can be checked using the IS_CLEANUP_INITIALIZED.
SET SERVEROUTPUT ON
BEGIN
IF DBMS_AUDIT_MGMT.is_cleanup_initialized(DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD) THEN
DBMS_OUTPUT.put_line('YES');
ELSE
DBMS_OUTPUT.put_line('NO');
END IF;
END;
/
YES

PL/SQL procedure successfully completed.

SQL>
To deconfigure the audit management infrastructure run the DEINIT_CLEANUP procedure.
BEGIN
DBMS_AUDIT_MGMT.deinit_cleanup(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL);
END;
/
Timestamp Management

The next thing to consider before purging the audit trail is how much data you wish to purge. The DBMS_AUDIT_MGMT package allows us to purge all the records, or all the records older than a specific timestamp. The timestamp in question is specified individually for each audit trail using the SET_LAST_ARCHIVE_TIMESTAMP procedure, which accepts three parameters:
AUDIT_TRAIL_TYPE: The audit trail whose timestamp is to be set (Constants). Only individual audit trails are valid, not the constants that specify multiples.
LAST_ARCHIVE_TIME: Records or files older than this time will be deleted.
RAC_INSTANCE_NUMBER: Optionally specify the RAC node for OS audit trails. If unset it assumes the current instance.
The following code specifies a timestamp of 5 days ago for the standard database audit trail. The setting is then checked by querying the DBA_AUDIT_MGMT_LAST_ARCH_TS view.
BEGIN
DBMS_AUDIT_MGMT.set_last_archive_timestamp(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
last_archive_time => SYSTIMESTAMP-5);
END;
/

COLUMN audit_trail FORMAT A20
COLUMN last_archive_ts FORMAT A40

SELECT * FROM dba_audit_mgmt_last_arch_ts;

AUDIT_TRAIL RAC_INSTANCE LAST_ARCHIVE_TS
-------------------- ------------ ----------------------------------------
STANDARD AUDIT TRAIL 0 13-DEC-09 01.57.54.000000 PM +00:00

SQL>
The timestamps for each audit trail can be cleared to allow a complete purge using the CLEAR_LAST_ARCHIVE_TIMESTAMP procedure.
BEGIN
DBMS_AUDIT_MGMT.clear_last_archive_timestamp(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD);
END;
/
Manual Purge

The CLEAN_AUDIT_TRAIL procedure is the basic mechanism for manually purging the audit trail. It accepts two parameters:
AUDIT_TRAIL_TYPE: The audit trail to be purged (Constants).
USE_LAST_ARCH_TIMESTAMP: Set to FALSE to purge all records/files, or TRUE to only purge records/files older than the timestamp specified for the audit trail.
The following code queries the last archive timestamp and total number of audit records, deletes standard database audit records older than the last archive timestamp, then returns the number of records again.
SELECT * FROM dba_audit_mgmt_last_arch_ts;

AUDIT_TRAIL RAC_INSTANCE LAST_ARCHIVE_TS
-------------------- ------------ ----------------------------------------
STANDARD AUDIT TRAIL 0 13-DEC-09 01.57.54.000000 PM +00:00

SQL>

SELECT COUNT(*) FROM aud$;

COUNT(*)
----------
2438

SQL>

BEGIN
DBMS_AUDIT_MGMT.clean_audit_trail(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
use_last_arch_timestamp => TRUE);
END;
/

PL/SQL procedure successfully completed.

SELECT COUNT(*) FROM aud$;

COUNT(*)
----------
76

SQL>
Automated Purging

The CREATE_PURGE_JOB procedure allows you to schedule a job to call the CLEAN_AUDIT_TRAIL procedure. When creating a purge job you can specify 4 parameters.
AUDIT_TRAIL_TYPE: The audit trail to be purged by the scheduled job (Constants).
AUDIT_TRAIL_PURGE_INTERVAL: The interval in hours between purges.
AUDIT_TRAIL_PURGE_NAME: A name for the purge job.
USE_LAST_ARCH_TIMESTAMP: Set to FALSE to purge all records/files, or TRUE to only purge records/files older than the timestamp specified for the audit trail.
The following code schedules a purge of all audit trails every 24 hours. The resulting job is visible in the DBA_SCHEDULER_JOBS view.
BEGIN
DBMS_AUDIT_MGMT.create_purge_job(
audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL,
audit_trail_purge_interval => 24 /* hours */,
audit_trail_purge_name => 'PURGE_ALL_AUDIT_TRAILS',
use_last_arch_timestamp => TRUE);
END;
/

PL/SQL procedure successfully completed.

SQL>

SELECT job_action
FROM dba_scheduler_jobs
WHERE job_name = 'PURGE_ALL_AUDIT_TRAILS';

JOB_ACTION
--------------------------------------------------------------------------------
BEGIN DBMS_AUDIT_MGMT.CLEAN_AUDIT_TRAIL(15, TRUE); END;

SQL>
The job can be disabled and enabled using the SET_PURGE_JOB_STATUS procedure.
BEGIN
DBMS_AUDIT_MGMT.set_purge_job_status(
audit_trail_purge_name => 'PURGE_ALL_AUDIT_TRAILS',
audit_trail_status_value => DBMS_AUDIT_MGMT.PURGE_JOB_DISABLE);

DBMS_AUDIT_MGMT.set_purge_job_status(
audit_trail_purge_name => 'PURGE_ALL_AUDIT_TRAILS',
audit_trail_status_value => DBMS_AUDIT_MGMT.PURGE_JOB_ENABLE);
END;
/
The interval of the purge job can be altered using the SET_PURGE_JOB_INTERVAL procedure.
BEGIN
DBMS_AUDIT_MGMT.SET_PURGE_JOB_INTERVAL(
audit_trail_purge_name => 'PURGE_ALL_AUDIT_TRAILS',
audit_trail_interval_value => 48);
END;
/
Purge jobs are removed using the DROP_PURGE_JOB procedure.
BEGIN
DBMS_AUDIT_MGMT.drop_purge_job(
audit_trail_purge_name => 'PURGE_ALL_AUDIT_TRAILS');
END;
/
There are two things to note about the automated functionality.
If purge jobs use the last archived timestamp and you do not manually move this timestamp forward, the job will run and have nothing to purge. You should reset the timestamp when you have made an archive of the audit information, that way your audit information is secure and the job can purge the excess data.
The purge job functionality is simply a wrapper over the DBMS_SCHEDULER package to make automating purge jobs easier.
For more information see: