Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!
create dashboards using apex 18.1
Hi APEX masters,
We are creating a DB portal with all information related to the databases . And would need ideas on creating dashboards in apex 18.1, please suggest some sample applications or screenshots.
Thanks in advance,
R
We are creating a DB portal with all information related to the databases . And would need ideas on creating dashboards in apex 18.1, please suggest some sample applications or screenshots.
Thanks in advance,
R
Do more with
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Hi,
That's not an easy-to-answer question without knowing more about what you are planning to do. Dashboards could look completely different, depending on if you want charts or just reports. A good start usually is the sample application (e.g. https://apex.oracle.com/pl
Best wishes
Markus
That's not an easy-to-answer question without knowing more about what you are planning to do. Dashboards could look completely different, depending on if you want charts or just reports. A good start usually is the sample application (e.g. https://apex.oracle.com/pl
Best wishes
Markus
What data do you have available?
Do you have OEM? If so, do you need a dashboard or does the grid control already give it to you?
Do you have OEM? If so, do you need a dashboard or does the grid control already give it to you?
Hi sdstuber,
As i mentioned earlier building a DB portal , and would need ideas to have dashboard page !! Apart from the below what else can be added on the dashboard, so that dba's would like to see the first thing about their databases.
We have pages for -
Long ops, no-bind sql, realtime, blocking sessions, performance, capacity, health check, inventory, alerts
Let me know your suggestions., which I can display as reports or charts on dashboard.
hope this helps.
Thanks,
R
As i mentioned earlier building a DB portal , and would need ideas to have dashboard page !! Apart from the below what else can be added on the dashboard, so that dba's would like to see the first thing about their databases.
We have pages for -
Long ops, no-bind sql, realtime, blocking sessions, performance, capacity, health check, inventory, alerts
Let me know your suggestions., which I can display as reports or charts on dashboard.
hope this helps.
Thanks,
R
Obviously any of those "could" be a report. If you can make a sql statement to return any of those, then you can put the results into a report - that doesn't mean you should though.
A Dashboard should contain actionable information.
So, "no-bind sql" - if you have a report that shows all of the statements that are not using binds, or a chart that counts them for each database, will or can anyone do anything with that information? If you have a fleet of 3rd party applications, having a chart that lists their failings likely won't produce much unless you can leverage your SLA.
Be careful with making reports of sql statements, because they can expose private data, especially if the application doesn't use binds.
Blocking sessions, you can make a report, or a chart, or both. I've generated trees before to show lock hierarchies.
Generally though, these are not as helpful as you might expect as some locking can be expected in many applications without indicating a problem.
Performance - I would recommend using OEM's charts and tools first. I understand in a previous question you said you were asked to write your own tool instead of using OEM. - I've been down that path before, the better approach, both technically and professionally would be to push back to your management that the tools they are asking for are already available. If you can't tell your management that they are heading down the wrong path, then that means they don't respect your opinion - which is not only demeaning to you, but it also brings into question their managerial skills if they build a team of people who's expertise is not heeded.
What I would suggest is using OEM as a base, and then augmenting it where needed.
For instance, I tied OEM into our ticketing and inventory system. This allows for correlating user requests with specific OEM targets (databases and/or servers.) Once I had the correlations, building reports or charts on them was easy.
I created a system-wide "dashboard" of db versions and platforms - (i.e. how many 11g,12c,18c on each OS platform) this shows our upgrade/patching status as well as showing overall storage trends. You could generate these in OEM, but it was easier to produce the visualizations we were looking for in APEX.
If someone is asking you to build a dashboard but has given you no requirements as to what information you are supposed to expose, then simply generate a blank page. It'll be easy, secure, and fullfill your requirements.
It should also help illustrate that asking for information without being told "which" information is rather silly.
Unless you're just looking for practice, don't build a dashboard of things you "can" gather, build a dashboard of things that target value opportunities to your department and/or company. In other words - you (or your management) must identify your own KPIs and then go build or buy a tool that tracks and reports them.
A Dashboard should contain actionable information.
So, "no-bind sql" - if you have a report that shows all of the statements that are not using binds, or a chart that counts them for each database, will or can anyone do anything with that information? If you have a fleet of 3rd party applications, having a chart that lists their failings likely won't produce much unless you can leverage your SLA.
Be careful with making reports of sql statements, because they can expose private data, especially if the application doesn't use binds.
Blocking sessions, you can make a report, or a chart, or both. I've generated trees before to show lock hierarchies.
Generally though, these are not as helpful as you might expect as some locking can be expected in many applications without indicating a problem.
Performance - I would recommend using OEM's charts and tools first. I understand in a previous question you said you were asked to write your own tool instead of using OEM. - I've been down that path before, the better approach, both technically and professionally would be to push back to your management that the tools they are asking for are already available. If you can't tell your management that they are heading down the wrong path, then that means they don't respect your opinion - which is not only demeaning to you, but it also brings into question their managerial skills if they build a team of people who's expertise is not heeded.
What I would suggest is using OEM as a base, and then augmenting it where needed.
For instance, I tied OEM into our ticketing and inventory system. This allows for correlating user requests with specific OEM targets (databases and/or servers.) Once I had the correlations, building reports or charts on them was easy.
I created a system-wide "dashboard" of db versions and platforms - (i.e. how many 11g,12c,18c on each OS platform) this shows our upgrade/patching status as well as showing overall storage trends. You could generate these in OEM, but it was easier to produce the visualizations we were looking for in APEX.
If someone is asking you to build a dashboard but has given you no requirements as to what information you are supposed to expose, then simply generate a blank page. It'll be easy, secure, and fullfill your requirements.
It should also help illustrate that asking for information without being told "which" information is rather silly.
Unless you're just looking for practice, don't build a dashboard of things you "can" gather, build a dashboard of things that target value opportunities to your department and/or company. In other words - you (or your management) must identify your own KPIs and then go build or buy a tool that tracks and reports them.
I will throw out an addendum to my previous response - there can be value in simply trying things.
I got started in APEX development (back when it was still called HTMLDB) doing almost exactly what you're trying to do now.
A coworker and I spent a few weeks generating lots of different reports and charts mostly to learn how to do it. We picked our data sources simply by what the two of us though was interesting. Eventually some other people started making requests and that formed the basis of an application that ran for well over a decade. - The vast majority of it was completely ignored though because our exploratory and learning exercises weren't useful to others.
When APEX 5 came out, I retired the old application and consolidated all of the information that our users actually touched into a new single summary page that pulled from the OEM repository as its data source.
So - if you really have no firm requirements, and you really don't know what to put on your dashboard, then just try whatever comes to mind that you think you can be some kind of value, either intrinsically valuable to others, or educationally to you and the other developers.
If your management is giving you little or no direction, then ask your DBAs, your system admins, other developers, your project managers, your manager's manager, etc what they think of your application. Get feedback and requests, and head in that direction. Either you'll find there is zero interest at all and the project can be closed down, or it'll gather steam with these various user groups seeking the information they will find valuable.
I got started in APEX development (back when it was still called HTMLDB) doing almost exactly what you're trying to do now.
A coworker and I spent a few weeks generating lots of different reports and charts mostly to learn how to do it. We picked our data sources simply by what the two of us though was interesting. Eventually some other people started making requests and that formed the basis of an application that ran for well over a decade. - The vast majority of it was completely ignored though because our exploratory and learning exercises weren't useful to others.
When APEX 5 came out, I retired the old application and consolidated all of the information that our users actually touched into a new single summary page that pulled from the OEM repository as its data source.
So - if you really have no firm requirements, and you really don't know what to put on your dashboard, then just try whatever comes to mind that you think you can be some kind of value, either intrinsically valuable to others, or educationally to you and the other developers.
If your management is giving you little or no direction, then ask your DBAs, your system admins, other developers, your project managers, your manager's manager, etc what they think of your application. Get feedback and requests, and head in that direction. Either you'll find there is zero interest at all and the project can be closed down, or it'll gather steam with these various user groups seeking the information they will find valuable.
Premium Content
You need an Expert Office subscription to comment.Start Free Trial