The attached article outlines an apparently "ground breaking"
semi-homegrown parititioning strategy on a VLDB hosted on an MS SQL
Server.

http://www.sqlmag.com/Innovators/Zareer.pdf

I am mildly interested in the idea due to the similarity of a
situation we have here with a honking big database that will only get
bigger. I would love to get some feedback.

sumGirl wrote:
>
> The attached article outlines an apparently "ground breaking"
> semi-homegrown parititioning strategy on a VLDB hosted on an MS SQL
> Server.
>
> http://www.sqlmag.com/Innovators/Zareer.pdf
>
> I am mildly interested in the idea due to the similarity of a
> situation we have here with a honking big database that will only get
> bigger. I would love to get some feedback.

Good informiation you will find in the library
(you can also search for more using 'informix fragmentation' in rhe
small
search input thingie near top of the page)

http://www-106.ibm.com/developerwork...n/0206fan.html

and here:
http://www-106.ibm.com/developerwork...07noronha.html

One difference to the techniques mentioned in the pdf you attached is
that
to my knowledge there is no way to exclude some fragments from
database backup
by making fragments read-only.
You will want to read about onbar and its feature to backup/restore
per dbspace
(every fragment does need its own dbspace, but the dbspace can host
more
than one fragment, if they are from different tables)
Also I think that fragment attching / detaching is a very good
feature, if
handled properly.
Head to the docs, the SQL syntax guide has it all and more.

dic_k
--
Richard Kofler
SOLID STATE EDV
Dienstleistungen GmbH
Vienna/Austria/Europe

sumGirl wrote:

> The attached article outlines an apparently "ground breaking"
> semi-homegrown parititioning strategy on a VLDB hosted on an MS SQL
> Server.
>
> http://www.sqlmag.com/Innovators/Zareer.pdf
>
> I am mildly interested in the idea due to the similarity of a
> situation we have here with a honking big database that will only get
> bigger. I would love to get some feedback.

They overcame the limitations of the product by exploiting the
limitations.

Suffice it to say they wrote the article in such a way as to sound
innovative but it really wasn't innovative at all. It was just a
bunch of cleverly written statements in the article with jargon and
obfuscation. Interesting that they used the word "partitioning"
everywhere in the article, but in the real world partitioning is
nowhere to be found in SQL-Server. A lot of razzle-dazzle, but in
reality just a lot of manual effort for these guys since SQL-Server
doesn't really have tools or an architecture for big data. They
had to write a lot of scripts to make their situation managable.
( 23 million rows isn't a lot of data compared to what we have,
which is probably 100 times that ) They had to create a lot of
methods and tables to make things work.

For your Informix environment I'm not sure the same rules would
apply simply because you can partition data more professionally,
and with more effect than SQL-Server. What's really interesting
is that in SQL-Server docs they specifically tell you to **not**
use filegroups in a SAN! So much for these guys reading the fine
manual. )

Considering too that it's a SQL-Server mouthpiece magazine it has
to make much ado about nothing, as if SQL-Server is on a par with
DB2 or Informix or Oracle. Almost laughable to even see an article
like this, kind of like a family having an article about a wedding
or birthday.