↧
Statistics Collection Recommendations – Teradata Database 14.10 - comment by carrie
↧
Using the ResUsageSAWT table to Monitor AMP Worker Tasks - comment by vasudev
Thank you very much Carrie. Got clarified now.
↧
↧
Easing Into Using the New AutoStats Feature - comment by Sandeepyadav
Hi carrie,
I am planning to use STATS MANAGER for stats automation on two databases first. We are using TD14.10 that was upgraded from 14.00 to 14.10 last week. The DBS Control field NoDot0Backdown is false right now.
My question is -
If i enable the USECOUNT using DBQL query logging for one database without changing the NoDot0Backdown to true then will it recommend for de-activate stats on tables which are not being used in this database?.
can you please tell little about other impact by enable this parameter NoDot0Backdown to true.
Thanks- Sandeep.
↧
Easing Into Using the New AutoStats Feature - comment by Sudheer Vankayala
Hi Carrie,
This is very useful Info. I tried a lot to download "Automated Statistics Management" but failed to do.Request you to send me the document to my Email Id sudheer.0228@gmail.com
Thanks in Advance!!
↧
Easing Into Using the New AutoStats Feature - comment by carrie
Sandeep,
There are several good reasons to set NoDot0Backdown = TRUE when you get onto 14.10. Use of extended object names require it, as does use of increased data block and spool block sizes. You need that setting at TRUE in order to get the advantages of the new statistics histogram Version 6, which is able to record the Update/Delete/Insert counts at the time the stats were collected. UDI counts are part of what UseCount logging creates, and without UDI counts being integrated in the stats collection process you will risk having a negative impact on the threshold Change Percent capability.
If you want to use new 14.10 features fully, it's a good idea to set NoDot0Backdown = TRUE.
The only potential down side of this is that you will not be able to back down to 14.0, should you wish to do that.
In terms of the impact on AutoStats, the identification and deactivation of unused stats by Analyze jobs will still work even if NoDot0Backdown is False. In that scenario, the Analyze job will still read the USECOUNT data that tracks optimizer stats usage. However, as mentioned above, there will be negative impacts to other features, mostly the change-based THRESHOLD capabilties.
Although it is not the best practice, AutoStats does allow the automation of databases that do not have USECOUNT enabled. Functionally, Analyze and Collect jobs should still run without failure but those features requiring UDI counts will not operate effectively.
Thanks, -Carrie
↧
↧
Easing Into Using the New AutoStats Feature - comment by Sandeepyadav
Thanks a lot carrie :)
↧
Easing Into Using the New AutoStats Feature - comment by Sandeepyadav
Hi Carrie,
I have one more doubt. It will be a great help if you provide some input.
I have enabled XMLPLAN and STATUSAGE logging for one account and enable database logging USECOUNT for three databases. We are using PDCR that moves the XMLPLAN data from DBC to PDCR database but it does not move the data for USECOUNT .i.e. DBC.OBJECTUSAGE into PDCR.
So Analyse Job which database I have to mention in “Database containing log tables” field for USE DBQL option in“Edit Evaluation Method Settings” in STATS MANAGER Portal as XMLPLAN data is in PDCR and USECOUNT data is in DBC.
Thanks-Sandeep.
↧
New opportunities for statistics collection in Teradata 14.0 - comment by PeterSchwennesen
Hi Carrie
I have SQL Assistant v.15.00 and I cannot drop STAT.
Can you help me with the syntax for dropping STAT?
CREATE MULTISET TABLE T1 (val INTEGER); COLLECT STATISTICS T1 COLUMN val; DROP STATISTICS T1;
then line DROP STATISTICS T1; fails with the Error "Query is invalid".
The code is working ok when I use Assistant 13.11
Peter Schwennesen
↧
Easing Into Using the New AutoStats Feature - comment by carrie
Sandeep,
Analyze Jobs will always read USECOUNT data from DBC.ObjectUsage regardless of what the “Database containing log tables” is set to.
Although it is true that USECOUNT is now enabled using DBQL syntax, from the perspective of AutoStats its underlying storage table does not fall into the category of traditional per-request log tables such as DBC.QryLogV and DBC.QryLogXMLV.
Thanks, -Carrie
↧
↧
New opportunities for statistics collection in Teradata 14.0 - comment by carrie
Hi Peter,
I tried your syntax on a pre-14.0 version of SQLA and it worked fine for me.
Unfortunately, I'm not going to be able to help you with SQLA behavior or release changes. You will need to find someone with client side background or experience with SQLA for that.
I suggest that you post your question on the Teradata Forum, or see if you can find any blog postings here in Dev X related to client functionality.
Best regards, -Carrie
↧
Easing Into Using the New AutoStats Feature - comment by Sandeepyadav
Thanks a lot Carrie :)
↧
New opportunities for statistics collection in Teradata 14.0 - comment by PeterSchwennesen
I already did. Becaus there was a new systax, I thought that there also was a new for drop, but I now know that there is not, and that it is an bug in SQL Assistant version 15.00.00.00, it was fixed i versin 15.00.00.03.
But this version are not to be found under downloads
br
Peter Schwennesen
↧
Teradata 13.10 Statistics Collection Recommendations - comment by ksing
Hi Carrie,
Any recommendations regarding collection of stats on No PI table? Will collecting stats on such table help?
↧
↧
Recommended Dictionary Statistics to Collect in Teradata 14.0 - comment by Sandeepyadav
Hi Carrie,
I am using TD 14.10. During stats colletion on DBC tables i got warning :
COLLECT STATISTICS DBC.Indexes COLUMN (TableId, IndexNumber, DatabaseId);
*** Update completed. 2 rows changed.
*** Warning: 9683 The DBQL ObjectUsage logging is not enabled. The change percentag
e to skip statistics collection is determined based on dynamic A
MP sampling, which can only detect the row count change.
*** Total elapsed time was 1 second.
before scheduling it on production system i ran it on VMware and i got this warning. i am little confuse with change percentage in warning as i didn't mention it in stats.
Stats collection syntex as mentioned by you and stats syntex before 14.0, both are same or is there any benefits combine these different colomn statistics in single collect statement.
Thanks - Sandeep.
↧
Teradata 13.10 Statistics Collection Recommendations - comment by carrie
Considerations for collecting stats are generally the same for a NoPI table and a PI table. Other than (obviously) not collecting stats on the PI of a NoPI table.
However, stats on a NoPI table might not provide much value if the NoPI table is just being used for staging, and is sort of temporary. When used as a staging table, for example, you might not need to be concerned with stats on predictates or join columns, depending on what you are doing with the staging table. In some cases just collecting on SUMMARY stats would be adequate, because that would provide things like the row count, average row size, and average block size to the optimizer. And SUMMARY stats are very quick to collect.
But there is no reason you cannot collect stats on a NoPI table's columns, if you believe they will be useful.
Thanks, -Carrie
↧
Recommended Dictionary Statistics to Collect in Teradata 14.0 - comment by carrie
Sadeep,
It is normal to get this warning if statistics have been skipped and you do not have USECOUNT logging on.
If you look up that message (or google it), here is what it says:
9683: The DBQL ObjectUsage logging is not enabled. The change percentage to skip statistics collection is determined based on dynamic AMP sampling, which can only detect the row count change.
Explanation:
The DBQL ObjectUsage logging is not enabled. The change percentage to skip this statistics collection is determined based on the dynamic AMP sampling which can only detect the row count change. Therefore, the system cannot accurately determine the update and the combination of insert and delete counts on the target table.
Notes:
This warning is issued when the DBQL ObjectUsage logging is not enabled and statistics collection is skipped.
Remedy:
Turn on ObjectUsage logging for the target database if more accuracy is needed.
Skipping is a technique in Teradata Database 14.10 that the optimizer uses when you have asked for stats recollection but the table does not appear to have changed enough since the last collection to warrant that recollection. Under those conditions the optimizer may skip the re-collection. You can read more about skipping in the Teradata 14.10 Statistics Enhancement orange book.
In this case, the warning is telling you that skipping happened, but that it did not happen with as much accuracy as it could, if USECOUNT logging had been turned on. Instead of using actual Update, Delete and Insert counts that you would have available with USECOUNT logging, only random AMP sampling was used, and random sampling only detects a table's growth. If you deleted as many rows as you inserted since the last collection, random AMP sampling would interpret that as no change, while USECOUNT logging would recognize the change.
Thanks, -Carrie
↧
Recommended Dictionary Statistics to Collect in Teradata 14.0 - comment by Sandeepyadav
Thanks Carrie :)
↧
↧
Utility Session Management - It's Inside the Database in Teradata 13.10! (UPDATED) - comment by vincent91
Hi carrie,
I'm not sure to be in the right topic. If not sorry.
My question is about the session limit defined in workload Designer/Utility Sessions/Session based utility.
The session limit can be defined for Fastload, TPT Load operator, Stand Alone FastLoad, Stand Alone MultiLoad ... But something is missing in the list : TPT STREAM.
How can I define a session limit for TPT STREAM utility ?
Thanks
↧
Utility Session Management - It's Inside the Database in Teradata 13.10! (UPDATED) - comment by vincent91
My Teradata Viewpoint version is V14.10.00.04-b38
↧
Utility Session Management - It's Inside the Database in Teradata 13.10! (UPDATED) - comment by carrie
Vincent,
Session management in Workload Designer only covers the load utilities, and TPT Stream is SQL-based, so it not it is not officially a utility. The number of sessions is a parameter on the TPT Streams or TPump job, and has to be specified there. Number of sessions can secondarily be controlled by managing the number of such jobs that are started up at the same time.
You might want to inquir post a question on one of the Teradata Forums and ask what other Teradata practitioners do to manage the number of sessions used by TPT Streams or Tpump jobs. Unfortunately, there is not centralized place to do that.
Thanks, -Carrie
↧
Hi Terry,
I wish I could help you, but this is not an area of familiarity for me. And I have no idea who might know something like this.
I'd suggest you post this question on one of the Teradata Forums, and see of anyone else has ideas about it. That will give your question much greater exposure than tagging it on as a comment at the bottom of this blog. Or contact your Teradata account team and see if they can locate the appropriate resource within Teradata who might be able to advise you.
Thanks, -Carrie