We currently have the 11g TTIMDB plugin deployed in our EM10g instance without issue and looking to migrate to 12c. We've installed/deployed the 22.214.171.124.0 plugin into our EM12c instance and deployed it to 12cR3 agent on our TTIMDB dev server.
When adding the TTIMDB target in the same manner it's deployed in 10g, the connection tested fine to the DB however the target is showing down with the following errors.....
1. Under Monitoring > All Metrics we get this... "The TimesTen database is down: [data source/db name] is not loaded"
2. Under Target Setup > Monitoring Configuration we test the connection, and though testing the connection when first configuring the plugin worked fine it's now failing... "
Response;Can't resolve a non-optional query descriptor property [DSN] (DSN)"
Any thoughts on what may be causing these errors?
I think these are two separate issues:
Q1. Can you check to see if the TimesTen database is loaded in memory? EM can only collect metrics when the database is loaded in memory. A quick way to test this, is to have a ttIsql session connected to TimesTen while you test Monitoring -> All Metrics.
Q2. This is a known EM 12c problem with "Test Connection" against an established TimesTen target. The message can be ignored.
Thanks for the quick reply. The DBA is in India so we'll have to confirm that the DB is memory with the session test tomorrow. Two questions though...
We are talking about the same thing. When I say check to see if the TimesTen database is loaded in-memory, I mean make sure the database is running.
By default a TimesTen database is loaded in memory (start up) upon the first connection to the database. When the last database connection exits, it will be automatically unload the database from memory (shut down).
As a best practice, you should change this database start up behavior by manually changing the RAM Policy setting.
That's why I suggested have an ttIsql connection to the database while testing EM. This will ensure the target database is up and running, so EM can connect to it.
If you can stay connected to the target database using ttIsql and EM is still reporting that the database is down, then yes there is another problem.
I would suggest recreating the target and try again.
The DB was restarted just as a precaution earlier today and verified up. I'll work with the DBA tomorrow hopefully and verify this for sure that the DB is up while I'm checking the metrics real-time. WRT to recreating the target, this has been several times already ;-)
Maybe you are confusing the main daemon running (TimesTen instance is up) with a specific database being up? When you install TimesTen you create a TimesTen 'instance'. This instance has several daemon components the most critical of which is the main daemon. When the main daemon is running the instance is 'up' and when the main daemon is not running the instance is 'down'. An instance may manage several distinct databases concurrently and those may each be up (in memory) or down (not in memory) independently of each other. In order for anything meaningful to happen within an instance the instance must be up.
The default behaviour for TimesTen is to load a database into memory when something connects to it, to maintain it in memory while there are open connections and to unload it from memory when the last connection is closed. This can be useful for development and testing environments but is not necessarily the best choice for production environments. Generally, in a production environment, you should set the database(s) to 'manual' ramPolicy:
ttAdmin -ramPolicy manual DSN
then you can explicitly load the database into memory (i.e. start up the database):
ttAdmin -ramLoad DSN
and, when all connections have been close, you can explicitly shut it down:
ttAdmin -ramUnload DSN
Many customers find this a better way to manage production databases than the default behaviour.