Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

ACD Database

Status
Not open for further replies.

dass2

Technical User
Apr 12, 2005
34
GB
Hi,

We had some exception groups that didnt run, following an upgrade from 7 to 9. I was 99.9% sure they where set up correctly but obviously had to dial in check they had run. When they didnt I had to dial into the network and manually run the procedures. Now, being a bit of a clever man I realised that the table on the ACC database called egrp contains about 10 fields called ID1,ID2,ID3 etc which records the exception group per procedure. My next question, one which I would be able to answer myself if I had access to the ACD is does the Oracle 7 database use auditing. I know for definite that the EGRP table must have been updated (the ID1 fields specifically) and I also know Oracle does have an audit function, which can be turned off and on. I do belive however that the Update,Select functions etc can be very resource demanding and demands abundances of space so Im not sure if this has been turned on. If it has I can verify that my changes where indeed made and get management off my back :/
GRRRRRRR!!!

Any help would be appreciated

Ben
 
Hi,

the table egrp ist used to create groups of exption-days.
For every exection-group you can select a maximum of 14 exeptions-days (ID1, ID2...) which are referenced by their exept_ID from table exept_day.
The defined exeption-groups are used in the schedules to determine if the schedule should run as usual or not.

When a schedule runs which executes a procedure, start and finish of the procedure is logged in the activity-log of the active controller.
The schedule settings may be confusing if you don't play with them all day long...
BUT... we had a similar problem (v8.3) when a procedure did not run one day.

You can verify your settings just by issuing SQL-queries.
If it helps, I can post my scripts to show the schedules wich run DNIS-procedures. They produce a list of DNIS and all the procedure steps which activate the CCTs on them together with the settings of all the schedules referencing them.

In the System-Administrator is an option to activate and deactivate DB-Audit. I'm not shure if you need a technician account to use it.
But the usual DB-account has not the privileges to query the oracle-audit-tables, just the table "audit" in the DTA-schema where login/logout and loading/deleting of CCTs is logged. Can't imagine that all the selects/update of the DB are logged there when audit is on, but perhaps it's worth to talk with Aspect about that. I even wouldn't try to enable audit without having talked to their support people. We had conditions where entries to call_today where written with delay caused by our high load even without audit enabled...

Another hint is to get the release-notes of the service-packs and CMs which are not yet installed on your system from eService and look for any issues/fixes concerning procedures and schedules.

Hope I can celp,
Chris


 
Thanks for that Chris, much appreciated. Yeah, I seen that option on Sys Admin to have audit enabled. I cant find much on it tho? What is it, what does it do and where is the audit trail stored?

Thx
 
The online help for the audit setting in system manager is confusing mea little bit.
I think this setting enables logging of granting/revoking access-rights to/from DB-users ("Reporting Client Security"). I played around with that, but couldn't find apropriate entries in the audit table.

BUT there is a table named "DB_audit". It is listet in the catalog of tables which may be grantet access, but doing so produces errors, can't grant any user access to this table. There is no description of this table in the docs...

Whatever, I don't think this would help you to determine if a scheduled procedure was running or not.
 
to find out is a procedure was run or not the ACD activity log is the place to go. It will show the begin/end of procedure 5:

01012005 060000 SYSINFO Background procedure activity(Begin/Comp Action BEGIN ProcNum 5

01012005 060000 SYSINFO Background procedure activity(Begin/Comp Action FINISHED ProcNum 5

To access use System Manager / Tools / Activity Log and login as "customer"

A possible reason for procedure not to run are if you schedule procedures at exactly the same time. Ideal one procedure or group at a time.
An invalid step also cause a procedure to fail, for example if a DNIS was deleted, which is used in the procedure.

BTW, the ACD uses the windows scheduling service.

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top