Archives of the TeradataForum

Message Posted: Tue, 21 Jun 2005 @ 23:45:33 GMT

	<Prev	Next>		<<First	<Prev	Next>	Last>>

The only thing you are really collecting with heartbeat/canaries is response time at different times of day. Some people chart those numbers for each 24 hour period, then throw out the detail, so you don't necessarily have to keep a lot of "stuff".

There are often different reasons for instituting heartbeat (or canary) queries, and it is the particular underlying reason that might help you determine how many are going to be useful to you. Eleven seems a bit high to me, but I do know of cases where sites have canaries in each PG. If you do that, keep them short and run them less frequently. The last thing you want to do is spend the time to set up some number of heartbeat queries, each which uses system resources to some degree when it runs, if in fact most are never going to be used for any productive purpose.

A single heartbeat query is often used simply to mirror the impact of system load, as it changes through the day or the week. The longer the query gets, the greater is the system load at that point in time. For that purpose you probably only need to be run a heartbeat query in a single performance group, often issued from Teradata Manager (where you can make it alertable under some conditions).

In V2R5, Teradata Manager runs all heartbeat queries from the same performance group, so there's limited value in running more than one from that platform. The performance group such a query will run in is the priority of Teradata Manager, which by default is $H. But you could setup Teradata Manager to run at $M if you wished, then your hearbeat would also run at $M.

Another place I have seen heartbeat (or canary) queries useful is for monitoring response time for response-sensitive or tactical performance groups. You would have to do this manually, however. DBQL is helpful here. Such queries can provide information on how well the system is delivering on response time expectations for that particular application, and, if you look at the output frequently, illustrate any problems before they get worse, so you can resolve them.

The purpose of having them in each PG, if you chose to do that, is to keep tabs on what's happening to response times within each PG at different times of the day, to track trends, zoom in on times when contention might be heavy, both within the PG and without. If it's the same identical query running everywhere, its relative performance in different PGs can give you a feel for how priorities are actually working at your site, and maybe help you tune priority scheduler going forward.

You might want to start off with a smaller number of heartbeat queries and see what value you are deriving from them in practice (is anyone actually looking at the output?), and then add more if you believe you need them.

Thanks, -Carrie

	<Prev	Next>		<<First	<Prev	Next>	Last>>