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,
Rads RAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.


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. Take a look at the section cards and charts. Usually that should fit you with everything you need to know to build a dashboard.

Best wishes
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?
Rads RAuthor Commented:
Hi Markusld

Thanks for the link, will definitely check that.

Price Your IT Services for Profit

Managed service contracts are great - when they're making you money. Yes, you’re getting paid monthly, but is it actually profitable? Learn to calculate your hourly overhead burden so you can master your IT services pricing strategy.

Rads RAuthor Commented:
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.

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.
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.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Rads RAuthor Commented:
Hi sdstuber,

This is really helpful, will do check with my co-workers. Thanks a lot for taking time to explain so much in detail.

Really appreciate it.

Rads RAuthor Commented:
Thanks a lot.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Oracle Database

From novice to tech pro — start learning today.