New version of Oracle Simulate ASH is ready to download and test. You can find it here - sash-v2.3
New features:
- new easier installation process
- new metrics history (IO and system)
- improved support for RAC / multi database in one repository
- Oracle scheduler is used to manage jobs
This version of OraSASH has been tested with Oracle 10g and 11g R1 and R2 as a target database and Oracle 11gR2 Express Edition as repository.
regards,
Marcin
New features:
- new easier installation process
- new metrics history (IO and system)
- improved support for RAC / multi database in one repository
- Oracle scheduler is used to manage jobs
This version of OraSASH has been tested with Oracle 10g and 11g R1 and R2 as a target database and Oracle 11gR2 Express Edition as repository.
regards,
Marcin
17 comments:
marcin,
do you have screenshots?
Hi Karl,
This is repository only and set of collecting jobs only - no GUI - at least not at that time.
regards,
Marcin
Hi Marcin,
I've just downloaded it, I'm trying it this week, thanks a lot for sharing....
Ciao
Alberto
Hello, I've HAD an error while publishing my comments so same player try again :
I have ora-00907 missing right parenthesis while running the congig.sql script while trying to install sash on my oracle 10GR2 Windows box.
Seems to be related to "filter_preds=>" part of the code.
Are you using 10gR2 box as repository or target database ?
Can you send me a logs files from your working directory ?
Hi Marcin,
just wondering if you have plans to modify scripts to gather information w/o database link if it is local database.
For all installations I set SASH (2.2 and 2.3) it is local monitoring
and have not got any yet where I use db as repository to get data from remote databases.
And I think if it is the same schema would be used for repository and gathering of data it would better not to replace some of v$... and dba_... views with sash_... ones but rather use sash$... names, especially those
which are available in all (SE, XE, etc) editions.
Thank you,
Andrey
Hi Andrey,
Thanks for your comment. I was working on same issue wit Alberto and I send him new development version from svn/git. It should support local repositories as I used sys.v_$ instead of v$. It is still under development / testing but I will appreciate any additional tests.
sash$ is a good idea but we will loose possibility to use same queries against real ASH and S-ASH but it can be added as option and have a script to switch from sash$ to v$.
regards
Hi Marcin,
would it be possible to get those scripts for installation (for local db monitoring)?
In regards to ability to use the same scripts for ASH and S-ASH,
what scripts do you mean?
Thanks,
Andrey
Hi Andrey,
You can download script from Git - https://github.com/pioro/orasash/tree/master/sash_dev
At the beginning S-ASH delivered same view like ASH so you can run
select sql_id, count(*) from v$active_session_history group by sql_id;
on both without any changes. I also tried to use S-ASH as repository for ASH Viewer (ASHV) without any code change and it works with simulated v$ views.
But I see your point - if you are using S-ASH only views like sash$ will be more comfortable without mixing it with build in views. If you have a list of sash$ you want to include in code feel free to share it with me.
regards,
Marcin
Hi Marcin, Andrey,
Yes I'm using yet to test my local db monitor Sash version.
I linked also other remote DBs about 1 month ago.
we can switch to sash$ to v$, it's a very powerfull feature for this tool.
Ciao
Alberto
Marcin,
I just checked the code for sash_pkg
and see that database link still used and mandatory.
What I meant is to set v_dblink variable to be default null
and change the code to avoid '@'
there. If database is not remote then there is no need in db link
and for remote databases database link can be defined as '@dblink'
or the code can be modified to add
'@' to sqls if v_dblink is not null.
In regards sash$ views I have not
thought much yet, but definitely do
not want to have substitution for
views like v$instance, dba_objects, etc.
which are available in all editions.
Thanks,
Andrey
Hi Andrey,
OK I see your point now - my approach was to create local db links to keep code simpler but if for any reasons you think it will be better to get rid of db links in local config I can take a look on that.
regards,
Marcin
Hi all,
I think if it were possible keep dblink in local would be better to code maintenance to create a standard configuration also with a remote dbs
However for local config I agree with Andrey
Ciao
Hi Marcin,
since 2.2 I was using 2 different
schemas (SASH_REPO and SASH) for
repository and monitoring in the same database and was creating a link
using localhost but even it is a local dblink it is still a db link.
It would be interesting to know
how people use SASH - mostly through
remote db links or just for local
monitoring.
In regards to code change, I put
v_dblink ... default null to procedures
and in sash_targets has db_link empty but started to get problems
with getting data through v$...
although it can be resolved I think
through v_$ (have not tested it yet)
Thanks,
Andrey
Hi Marcin,
what do you think about implementation of lightweight jobs in the packages. I just modified them (for collect_ash) and created collect_ash_light w/o dbms_lock and scheduled it as LW job to run every second. I am planning to change it for collect_other (which is for some reason not scheduled using add_instance_job btw) as well to avoid PLSQL lock timer event (although it is from idle class)
Thanks,
Andrey
Hi,
Sorry for asking, but since SE1 and SE are the only available versions for me, I need to be carefull about what views I an querying- is this package of yours actually to the full able to be used if one ain't able to buy Enterprise Edition needed packages?
Hi,
This is main idea of S-ASH - you can use it in ANY version (SE1, SE and EE) without additional packs.
It is using only views which are available without additional costs.
regards,
Marcin
Post a Comment