IF i turn off this parameter at instance level((DFT_MON_TABLE)) . will it remove monitoring on all the tables under that particular instance ?
Thanks
Setting DFT_MON_TABLE to OFF means that DB2 will not populate the monitoring elements controlled by this switch starting when the database(s) in the instance are activated. This does not mean that DB2 isn't monitoring, though: you (or another user) can still enable this switch for their particular session using the UPDATE MONITOR SWITCHES USING TABLE ON.
Related
I am on Enterprise Architect 13.5, creating a deployment diagram. I am defining our servers as nodes, and using attributes on them so that I can specify their details, such as Disk Controller = RAID 5 or Disks = 4 x 80 GB.
When dragging instances of these nodes onto a diagram, I can select "Set Run State" on them and set values for all attributes I have defined - just like it is done in the deployment diagram in the EAExample project:
Since our design will have several servers using the same configuration, my plan was to use the "initial value" column in the attribute definition on the node to specify the default configuration so that all instances I create automatically come up with reasonable values, and when the default changes, I would only change the Initial Values on the original node instead of having to go to all instances:
My problem is that even though I define initial values, all instances I create do not show any values when I drag them onto the diagram. Only by setting the Run State on each instance, I can get them to show the values I want:
Is this expected behavior? Btw, I can reproduce the same using classes and instances of them, so this is not merely a deployment diagram issue.
Any ideas are greatly appreciated! I'm also thankful if you can describe a better way to achieve the same result with EA, in case I am doing it wrong.
What you could do is to either write a script to assist with it or even create an add-in to bring in more automation. Scripting is easier to implement but you need to run the script manually (which however can add the values in a batch for newly created diagram objects). Using an add-in could do this on element creation if you hook to EA_OnPostNewElement.
What you need to do is to first get the classifier of the object. Using
Repository.GetElementByID(object.ClassifierID)
will return that. You then can check the attributes of that class and make a list of those with an initial value. Finally you add the run states of the object by assigning object.RunState with a crude string. E.g. for a != 33 it would be
#VAR;Variable=a;Value=33;Op=!=;#ENDVAR;
Just join as many as you need for multiple run states.
I am looking as the following article:
https://www.ibm.com/support/knowledgecenter/en/SSEPGG_10.1.0/com.ibm.db2.luw.admin.cmd.doc/doc/r0001988.html
I would like to ask about the IMMEDIATE and the DEFERRED part. Sorry I am still confuse and not really understand on it.
in the IMMEDIATE part, it explain that IMMEDIATE is the default, but it requires an instance attachment to be effective. , what does it means that requires an instance attachment to be effective? I though it should be straight take effect after I run the command?
For example:
db2 update dbm cfg using diaglevel 4 immediate
Does this direct take effect on my db2diag log files?
Take care to read the Db2 knowledge-center version that matches your Db2-version. Maybe you are using a more recent version of Db2 like V10.5 or v11.1.
For the DIAGLEVEL parameter, you can change it on the fly i.e. without needing to bounce the Db2-instnce. The new value is effective immediately and you can see this in the db2diag (which will increase quickly in size because of all the extra messages that will appear).
For "instance attachment" it means that you can run db2 attach ... command before running the db2 update dbm cfg ... The details are here.
However, if you are running as the Db2-instance owner and you are on the Db2-server directly (e.g. via ssh etc) then the instance-attachment is not necessary in this specific case. The instance-attachment is necessary when the instance is remote, or is not the current instance, or you are not running as the instance-owner etc.
Embedded SQL application for DB2LUW is developed in following steps:
db2 prep
db2 bind
Assume we have 2 DB2LUW nodes and DDL are identical for both nodes. When switching DB2LUW node, is precompilation for new node necessary? Or is it possible to start from binding by using the bind file generated when precompiled for the first node?
I mean is it possible to bind in the following way?
[for node1]
1. db2 prep
2. db2 bind
[for node2]
db2 bind by using bind file generated at step1 for node1?
Any comments are greatly appreciated!
It helps to use clearer terminology when asking for help.
If by 'node1' and 'node2' you mean different copies of the same database, possibly with different data, but the same DDL then you do not need to precompile again, you can simply bind using the previously generated bindfiles. This assumes both databases use the same platform of Db2. This is common when promoting embedded-SQL code between environments (development, various-testing, pre-production, production etc.). Any external routines need their deployables promoted appropriately. Always ensure that runstats are appropriate before you bind.
If your 'node1' and 'node2' are part of a High-Availability solution (either active:passive on failover/failback, or primary:standby after takeovers, or purescale-members), then it is the same database so you don't need to rebind. You can rebind if you want to - but not essential.
Is there any Wheel /POCO /Option to do this in Perl using the POE module:
I want to monitor a DB table for changed records (deleting /insert/ update) and react accordingly to those changes.
If yes could one provide some code or a link that shows this?
Not that I'm aware of, but if you were really industrious you could write one. I can think of two ways to do it.
Better one first: get access to a transaction log / replication feed, e.g. the MySQL binlog. Write a POE::Filter for its format, then use POE::Wheel::FollowTail to get a stream of events, one for each statement that affects the DB. Then you can filter the data to find what you're interested in.
Not-so-good idea: using EasyDBI to run periodic selects against the table and see what changed. If your data is small it could work (but it's still prone to timing issues); if your data is big this will be a miserable failure.
If you were using PostgreSQL, you could create a trigger on your table's changes that called NOTIFY and in your client app open a connection and execute a LISTEN for the same notification(s). You can then have POE listen for file events on the DBD::Pg pg_socket file descriptor.
Alternatively you could create a SQL trigger that caused another file or network event to be triggered (write to a file, named pipe or socket) and let POE listen on that.
Is it possible to set a database role before running a report? I have a number of databases each containing a number of schemas with the same set of tables, where each schema has a number of roles to control read, write, data management and so on. None of these are default roles.
In sqlplus or TOAD I can do SET ROLE , before running a select statement. I would like to do the same in BIRT.
It may be possible to do this using the afterOpen event for the ODA Data Source, but I have not found any examples on how to get and use the native connection in JavaScript.
I am not allowed to add or change anything on the server end.
You can make an additional call to the database in the afterOpen method of the Data Source using Java. You can use JavaScript or a Java Event Handler to execute the SET ROLE statement, or to call a stored procedure that will execute it for you. This happens after the initial db connection is made, but before the Data Set query runs. It will be a little tricky to use the data source connection to make that call however, and I don't have the code right now to provide as an example.
Another way is to create a stored proc Data Set that will execute the desired command, and have that execute first. Drag and drop the Data Set into the report design, and make it invisible. It will run first before any other queries. Not the cleanest solution, but easy to do
Hope that helps
Le Birt Expert
You can write a login trigger and do a set role in this trigger ( PL/SQL: DBMS_SESSION.SET_ROLE). You can determine the username, osuser, program and machine of the user who want to log in.
The approach to use a stored procedure for setting the role won't work - at least not on Apache Derby. Reason: lifetime of the set role is limited to the execution of the procedure itself - after returning from the procedure the role will be the same as before the procedure has been called, i.e. for executing the report the same as no role would have ever been set.