Archives of the TeradataForum

Message Posted: Wed, 31 Jan 2007 @ 21:32:56 GMT

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

An excellent point from John Hall.

Most savings are realized from less then a few percent of the total number of tables in your average data warehouse.

I'm not knocking tools here. I think they are easy to use and can speed up the implementation and refresh of MVC in your warehouse. They certainly would save me some time.

I'm just not sure that tools really provide enough benefit to shops with the personnel, time, and the skills to do it on their own. Especially trying to convince managers to purchase something, when it can be done in-house, relatively cheaply.

In response to the vendor's perspective.

1.) Corruption and Responsibility Thereof.

I don't see how the vendor is responsible for data corruption via their tool.

The person responsible for using it should test it thoroughly before implementing.

And use a safe implementation procedure. Not replace your production table then drop it without any data validation. Even if the tool is at fault, there is bound to be some human error if you corrupt your only online copy of the data.

Also I don't see how corruption should enter the picture. If you are doing compression you should definitely build a staging or cloned table and then rename. Period. Even in V2r6.2.xxxx when you are able to Alter Table to add compression. It is not as good idea to monkey with production tables, especially if there is constant reporting or 24/7 active loads going against the table.

2.) Maximum Benefit

Surgical precision is not necessary in this. You will do very will in compressing the very largest of your tables.

You don't want to compress every thing in you warehouse (Think of the poor architects. And modelers.)

It is messy and difficult to maintain model wise.

3.) Debugging

Couple hundred lines of code... Maybe a thousand.. Pretty easy to debug.

4.) Point and Click

Yes that's a nice feature. But dangerous if you are tinkering with production data.

5.) Support

For a DBA he generally responsible for all data and system integrity anyhow. I'm not clear on the added value of vendor support for issues regarding compression.

6.) Centralized Solution.

Centralized =? Site License = Lots of $$$

Plus I don't want anyone doing this.

7.) Report the potential results to management with graphs and charts?

Excel works fine, honestly the charts I have seen in tools are not that useful.

3-D and pretty doesn't compensate for practicality and flexibility

8.) Did the individual understand that compressing some tables can actually make them bigger?

The individual should read the whitepapers and manuals first, to understand the impact of compression and how it works.

9.) Does the in-house solution provide a filter so the largest tables could be compressed first?

Of course. Its can be more flexible, by rank of size within db by overall size whatever you want.

10.) Did the scripts evaluate columns not eligible for compression such as VARCHAR and give you the option to convert to CHAR with compression?

This is a little bit tricky for an in-house solution.

But simple demographic analysis on the columns in question on VERY large tables should give you a good indication as to whether to convert or not.

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