By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,514 Members | 1,693 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,514 IT Pros & Developers. It's quick & easy.

Performance problem on Linux

P: n/a
Hi,

I have a ralatively simple SQL:

select FK from TABLE where upper(A) like 'B%' and upper(C) like 'D%'

We have DB2 UDB v7.1 FP 12 installed on Linux and on Windows 2003

On Linux using optimization level 5 as well as 9 and 0 the SQL uses
3'100'000'000 timerons !
On Windows 2003 the SQL needs 26'000 timerons

We have tested with SUSE Linux 9.1 as well as Redhat 7.2 , both with the
same dramtic results. And no, the number of zeros is correct.

The Table TABLE has 140'000 rows. The result set of the SQL returns 200
rows.

Any idea what could be causing this difference. The access plans are
identical (TABLE -> TBSACAN -> RESULT) but one is acceptable, the other not.

Runstats have been executed on both tables.

Another problem we have seen is, when we add an index on column A, the
access plan becomes totally different. DB2 will perform an index scan on
TABLE, then performs a FETCH and joins the result of the index scan with
TABLE (!), then does a TBSCAN and then returns the RESULT. The FETCH in this
case takes 3'000'000'000 timerons.

As I mentioned above, we tested using optimization levels 0, 5 and 9.
Comparing the optimized SQL on Windows and Linux showed, that no
optimization was necessary, neither on Windows, nor on Linux.

Any ideas?

Regards

Rudolf Bargholz
Nov 12 '05 #1
Share this Question
Share on Google+
23 Replies


P: n/a
Timerons are an arbitrary unit of measure. I don't believe that they are
comparable across platforms.

You didn't mention if the queries had been executed on the platforms and
the resultant execution times compared. I suspect that they'd be
comparable, assuming similar hardware and ignoring possible differences
caused by the different operating systems.

The access paths you described are what would be expected. Applying a
function (UPPER) to a column will require a table scan to evaluate. When
you have the index, the index is used first because it will cause less
I/O to process. The following scan was probably caused because the
optimizer determined that the results of the index processing would
retrieve enough of the table that scan would be faster than retrieving
individual pages of the table.

One way to optimize this is:
1. Add a column to the table, populating it with the first character of
each of the columns A and B, uppercased. This will require insert and
update triggers. (Update only if the column content can be modified.)
2. Create an index on the new upper cased column.
3. Cluster the table on the newly created index. You'll have to reorg
the table to make the clustering efffective.
4. Change the query to use the new column name and combine the two data
values to a pair of letters in the query.
The query will now use the new index to locate a range of rows that
match. Sequential detect will switch access mode to prefetch when that
results in less I/O. This technique will retrieve your data rows using
an index and the minimum possible I/O.

This does not take into account other possible issues caused by using
the new column as a clustering index. The table rows will grow by two
bytes/row (assuming NOT NULL) which will add 280,000 bytes table. You'll
also need space for the index. This is probably a fair tradeoff if the
query is frequently used. Explains run before and after the clustering
reorg can be used to determine if the clustering option is necessary to
avoid the table scan.

Soundex code are often used to provide some selectivity on names when
searching. You might consider using it instead of a single character for
selectivity.

Phil Sherman


Rudolf Bargholz wrote:
Hi,

I have a ralatively simple SQL:

select FK from TABLE where upper(A) like 'B%' and upper(C) like 'D%'

We have DB2 UDB v7.1 FP 12 installed on Linux and on Windows 2003

On Linux using optimization level 5 as well as 9 and 0 the SQL uses
3'100'000'000 timerons !
On Windows 2003 the SQL needs 26'000 timerons

We have tested with SUSE Linux 9.1 as well as Redhat 7.2 , both with the
same dramtic results. And no, the number of zeros is correct.

The Table TABLE has 140'000 rows. The result set of the SQL returns 200
rows.

Any idea what could be causing this difference. The access plans are
identical (TABLE -> TBSACAN -> RESULT) but one is acceptable, the other not.

Runstats have been executed on both tables.

Another problem we have seen is, when we add an index on column A, the
access plan becomes totally different. DB2 will perform an index scan on
TABLE, then performs a FETCH and joins the result of the index scan with
TABLE (!), then does a TBSCAN and then returns the RESULT. The FETCH in this
case takes 3'000'000'000 timerons.

As I mentioned above, we tested using optimization levels 0, 5 and 9.
Comparing the optimized SQL on Windows and Linux showed, that no
optimization was necessary, neither on Windows, nor on Linux.

Any ideas?

Regards

Rudolf Bargholz


Nov 12 '05 #2

P: n/a
Hi Phil,

Thanks for the reply. Comments below.

Regards

Rudolf

"Philip Sherman" <ps******@ameritech.net> schrieb im Newsbeitrag
news:QQ****************@newssvr28.news.prodigy.com ...
Timerons are an arbitrary unit of measure. I don't believe that they are
comparable across platforms.
If queies the take a fraction of a second on Windows but take thirty seconds
to one minute on Linux ....

You didn't mention if the queries had been executed on the platforms and
the resultant execution times compared. I suspect that they'd be
comparable, assuming similar hardware and ignoring possible differences
caused by the different operating systems.
The reason I am asking is because the one customer of ours that uses DB2 on
Linux is having dramatic speed problems. I cannot understand why they have
not contacted us earlier regarding these problems. I personally would go
crazy if I had to work at the speed they are used to.

Regarding the hardware, both test machines are very similar, nothing that
would explain to me the dramatic difference in access plan and timerons.

The access paths you described are what would be expected. Applying a
function (UPPER) to a column will require a table scan to evaluate. When
you have the index, the index is used first because it will cause less
I/O to process.
Why would Windows not use an index, but Linux does? I see no reason why an
index scan is used when a table scan is unavoidable.
The following scan was probably caused because the
optimizer determined that the results of the index processing would
retrieve enough of the table that scan would be faster than retrieving
individual pages of the table.
Shouldn't the optimizer react differently if I set the optimization level to
0 or 9? I tried 0, 5 and 9 and the access plan did not change.

One way to optimize this is:
1. Add a column to the table, populating it with the first character of
each of the columns A and B, uppercased. This will require insert and
update triggers. (Update only if the column content can be modified.)
2. Create an index on the new upper cased column.
3. Cluster the table on the newly created index. You'll have to reorg
the table to make the clustering efffective.
4. Change the query to use the new column name and combine the two data
values to a pair of letters in the query.
This is a cool idea :-) Thanks !

The query will now use the new index to locate a range of rows that
match. Sequential detect will switch access mode to prefetch when that
results in less I/O. This technique will retrieve your data rows using
an index and the minimum possible I/O.

This does not take into account other possible issues caused by using
the new column as a clustering index. The table rows will grow by two
bytes/row (assuming NOT NULL) which will add 280,000 bytes table. You'll
also need space for the index. This is probably a fair tradeoff if the
query is frequently used. Explains run before and after the clustering
reorg can be used to determine if the clustering option is necessary to
avoid the table scan.

Soundex code are often used to provide some selectivity on names when
searching. You might consider using it instead of a single character for
selectivity.

Phil Sherman


Rudolf Bargholz wrote:
Hi,

I have a ralatively simple SQL:

select FK from TABLE where upper(A) like 'B%' and upper(C) like 'D%'

We have DB2 UDB v7.1 FP 12 installed on Linux and on Windows 2003

On Linux using optimization level 5 as well as 9 and 0 the SQL uses
3'100'000'000 timerons !
On Windows 2003 the SQL needs 26'000 timerons

We have tested with SUSE Linux 9.1 as well as Redhat 7.2 , both with the
same dramtic results. And no, the number of zeros is correct.

The Table TABLE has 140'000 rows. The result set of the SQL returns 200
rows.

Any idea what could be causing this difference. The access plans are
identical (TABLE -> TBSACAN -> RESULT) but one is acceptable, the other not.
Runstats have been executed on both tables.

Another problem we have seen is, when we add an index on column A, the
access plan becomes totally different. DB2 will perform an index scan on
TABLE, then performs a FETCH and joins the result of the index scan with
TABLE (!), then does a TBSCAN and then returns the RESULT. The FETCH in this case takes 3'000'000'000 timerons.

As I mentioned above, we tested using optimization levels 0, 5 and 9.
Comparing the optimized SQL on Windows and Linux showed, that no
optimization was necessary, neither on Windows, nor on Linux.

Any ideas?

Regards

Rudolf Bargholz

Nov 12 '05 #3

P: n/a
Philip Sherman wrote:
One way to optimize this is:
1. Add a column to the table, populating it with the first character of
each of the columns A and B, uppercased. This will require insert and
update triggers. (Update only if the column content can be modified.)
2. Create an index on the new upper cased column.
3. Cluster the table on the newly created index. You'll have to reorg
the table to make the clustering efffective.
4. Change the query to use the new column name and combine the two data
values to a pair of letters in the query.


generated columns would be a way to even further simplify this because they
allow you to automate part of step 1 (no triggers needed there) and step 4
(db2 will reroute automatically for you if possible).

--
Knut Stolze
Information Integration
IBM Germany / University of Jena
Nov 12 '05 #4

P: n/a
Ian
Rudolf Bargholz wrote:


Any idea what could be causing this difference. The access plans are
identical (TABLE -> TBSACAN -> RESULT) but one is acceptable, the other not.

Runstats have been executed on both tables.


Does the table need to be reorged? How do the values for npages
and fpages compare between the two systems?

i.e. if FPAGES >>> NPAGES one one system (Linux) and not the other
(Windows), then you're likely to see some of what you're describing.



-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 100,000 Newsgroups - 19 Different Servers! =-----
Nov 12 '05 #5

P: n/a
Hi Ian,

Thanks for the reply.
Does the table need to be reorged?
Both machines are new DB2 installations. The DB has been newly created and
the data impoted into the DB2. We upped the bufferpools and ran a runstats.
Then the tests were performed. I do not think a reorg ought to be necessary,
or am I wrong in assuming this?
How do the values for npages
and fpages compare between the two systems?

i.e. if FPAGES >>> NPAGES one one system (Linux) and not the other
(Windows), then you're likely to see some of what you're describing.


Will check. Thanks for the tip. Perhaps the runstats are causing the problem
on Linux.

Regards

Rudolf
Nov 12 '05 #6

P: n/a
> Hi Ian,

Thanks for the reply.
Does the table need to be reorged?
Both machines are new DB2 installations. The DB has been newly created and
the data impoted into the DB2. We upped the bufferpools and ran a

runstats. Then the tests were performed. I do not think a reorg ought to be necessary, or am I wrong in assuming this?

You are probably wrong on that. Do a reorg, then runstats, and rebind any
packages (not required for dynamic SQL).
Nov 12 '05 #7

P: n/a
Thanks for that Mark. Will do and will report on my findings.

Regards

Rudolf

"Mark A" <no****@nowhere.com> schrieb im Newsbeitrag
news:QF***************@news.uswest.net...
Hi Ian,

Thanks for the reply.
Does the table need to be reorged?


Both machines are new DB2 installations. The DB has been newly created and the data impoted into the DB2. We upped the bufferpools and ran a

runstats.
Then the tests were performed. I do not think a reorg ought to be

necessary,
or am I wrong in assuming this?

You are probably wrong on that. Do a reorg, then runstats, and rebind any
packages (not required for dynamic SQL).

Nov 12 '05 #8

P: n/a
Hi Ian,
i.e. if FPAGES >>> NPAGES one one system (Linux) and not the other
(Windows), then you're likely to see some of what you're describing.


For your information, on both Linux and Windows the NPAGES=FPAGES and both
have a value of about 7000.

We are attempting the reorg on Linux at the moment to see if that helps.

Regards

Rudolf Bargholz

Nov 12 '05 #9

P: n/a
Hi Ian,

for your information, on both systems the NPAGES=FPAGES and both are around
7000. We are busy testing if the reorg will help.

Regards

Rudolf

"Ian" <ia*****@mobileaudio.com> schrieb im Newsbeitrag
news:41**********@corp.newsgroups.com...
Rudolf Bargholz wrote:

i.e. if FPAGES >>> NPAGES one one system (Linux) and not the other
(Windows), then you're likely to see some of what you're describing.

Nov 12 '05 #10

P: n/a
Hi Mark,
You are probably wrong on that. Do a reorg, then runstats, and rebind any
packages (not required for dynamic SQL).


We just completed a reorg of the table with the same results. The number of
timerons used on Linux is 3'000'000'000, on Windows 25'000 and the (very
simple) query on Linux takes forever. One thing we did notice on Linux was
that when performing a

select * from sysstat.TABLES

I get the following result:

Tabname Card Npages Fpages Overflow

Windows:
TEILNEHMER 139352 6503 6503 0

Linux:
TEILNEHMER 141454 7162 7162 50

On Linux most of the columns, especially the larger ones, have a value in
Overflow. Can anyone tell me what this means and if this might be
detrimental to the optimizers health? On Windows none of the columns have a
value set in Overflow. The Overflow value is assigned by the runstats, I
think.

Regards

Rudolf Bargholz




Nov 12 '05 #11

P: n/a
Hi,

did you do the RUNSTATS?
Nov 12 '05 #12

P: n/a
Hi,
did you do the RUNSTATS?


Yes, the runstats have been executed. They are executed for all tables on a
daily basis, e.g.

db2 runstats on table db2admin.TEILNEHMER with distribution and detailed
indexes all

Regards

Rudolf Bargholz
Nov 12 '05 #13

P: n/a
Rudolf,

all users disconnected, DB deactivated (just in case it's activated)
after REORG/RUNSTATS?

Any memory/sort related hints in the notify/error logs?
Nov 12 '05 #14

P: n/a
Hi,

the test environment we built is a new computer with clean Linux
installation and then DB2 v7.1 FP12 was installed. To Exlude all other
factors, we created a DB and then imported only the one test table into the
DB. There is only one user accessing the DB.

We have had a look at the db2diag.log and found nothing.

What we have found, is that if we install DB2 v8, the optimizer works
correctly and the time needed to SQL statements that require a full table
scan are comparable under Linux and Windows. The problem is, we cannot
afford to upgrade our Windows customers to DB2 v8 as these have bought the
software in the course of the past three years and do not have the money to
pay for something that gives them no real additional value. Also, upgrading
over 150 locations and 1500 workstations als over Switzerland is something
that will take us forever and there is no good reason why our customers
ought to pay us for the effort. We only have two customers on Linux at the
moment, and one of them will be moving to a Windows server in the next
couple of weeks due to the dramatic speed problems they have been
experiencing with DB2 v7 and Linux. The other customer insists on Linux,
which would be fine if there just were not these optimizer problems with DB2
v7 and Linux. Unfortunately, the situation is, they will be our installation
with the most number of users (~200) connected to one server and need Linux
for the built in Fail-Over support. Having to support two different DB2
versions in our app is not something I am looking forward to.

Thanks to you and all the others that have tried to help.

Regards

Rudolf Bargholz
"DB2 newsgroup user" <db**************@db2.newsgroup.user> schrieb im
Newsbeitrag news:20***********************@dyndns.org...
Rudolf,

all users disconnected, DB deactivated (just in case it's activated)
after REORG/RUNSTATS?

Any memory/sort related hints in the notify/error logs?


Nov 12 '05 #15

P: n/a
Rudolf,

I really haven't followed your thread before today, but I have just
experienced
something just this morning and I wondered if it is relevent to your
situation too.

We had a server running on RH using ext3 filesystem, and all was
great.

We have just moved the same database to an identical Blade Server, but
with SLES and reiserfs - just the copying across of the backup images
and restore ran incredibly more slowly (5x slower) on the
SLES/reiserfs system. We are just changing the install to ext3 to see
if this makes any significant difference ?

Also, are your CPUSPEED and IO config. parameters (OVERHEAD and
tranfer rate)correct/reasonable or wildly wrong?

Paul.
Nov 12 '05 #16

P: n/a
Paul Reddin wrote:
Rudolf,

I really haven't followed your thread before today, but I have just
experienced
something just this morning and I wondered if it is relevent to your
situation too.

We had a server running on RH using ext3 filesystem, and all was
great.

We have just moved the same database to an identical Blade Server, but
with SLES and reiserfs - just the copying across of the backup images
and restore ran incredibly more slowly (5x slower) on the
SLES/reiserfs system. We are just changing the install to ext3 to see
if this makes any significant difference ?

Also, are your CPUSPEED and IO config. parameters (OVERHEAD and
tranfer rate)correct/reasonable or wildly wrong?

Paul.


I had a small database (coupla gigabytes) running on RHL 7.3 with using
SMS on ext3 dedicated partitions on 10,000rpm Ultra-2/LVD SCSI hard
drives. I wondered if the journalling would be a noticeable overhead
factor, enough to notice. I had a job that ran in 10 hours, and converting
the partitions to ext2 made the 10 hour job run about 15 minutes faster
(IIRC). Enough to notice, but not enough to get excited about.

I run the same thing now (database has grown considerably) on a much
faster machine running RHEL 3 ES, and the whole 10 hour job runs in less
than an hour; it can run in about 35 minutes if nothing else is running on
the machine. But there are 4 dedicated 10,000rpm Ultra/320 SCSI drives on
there and there is no file system (as far as Linux is concerned, it is raw).

I suggest, if your kernel is new enough, and your database is suited to
it, that you try using raw file systems, at least for the larger tables.

--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 16:05:00 up 1 day, 7:40, 3 users, load average: 1.12, 1.05, 1.01

Nov 12 '05 #17

P: n/a
Hi Jean-David,

thanks for the tips.
I suggest, if your kernel is new enough, and your database is suited to
it, that you try using raw file systems, at least for the larger tables.


Our IBM support here in Switzerland advised strongly against using raw
devices with DB2 v7 due to many unresolved issues. Anyway, the data we are
talking about is in a 'small' table (~200000 rows), the only table in the
database instance.

Regards

Rudolf Bargholz
Nov 12 '05 #18

P: n/a
Hi Rudolf,

At database creation time are you using
the defult settings for the tablespace creation?

If yes are you sure that they are the same on Windows and Linux?
Isn't it by chance that you have different pagesizes fro your
tablespaces?

One more question how come the two table have different cardinality
(even if slightly)?

Hope this help

Fabrizio

Tabname Card Npages Fpages Overflow

Windows:
TEILNEHMER 139352 6503 6503 0

Linux:
TEILNEHMER 141454 7162 7162 50



--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
Nov 12 '05 #19

P: n/a
Hi Fabrizio,
At database creation time are you using
the defult settings for the tablespace creation?
Yes, we use the default settings. The databases are set up to use SMS
Tablespaces. What we have just now found is, that for the automatically
created tablespaces (4kB - USERSPACE1) DB2 has set a transfer rate of 46000,
compared to 0.9 for the 8kB tablespaces we created manually. Perhaps this is
the source of all our problems. We are busy setting up a new test system to
try out what happens to the optimizer when we play around with the transfer
rate.
If yes are you sure that they are the same on Windows and Linux?
Isn't it by chance that you have different pagesizes fro your
tablespaces?
All tablespaces use a 4kB page size
One more question how come the two table have different cardinality
(even if slightly)?


This also has us stumped. The stats are calculated using the runstats, so we
have no influence on the values. We have tried setting the overflow to 0
manually, but this did not help.

Regards

Rudolf Bargholz
Nov 12 '05 #20

P: n/a
Rudolf Bargholz wrote:
Hi Jean-David,

thanks for the tips.

I suggest, if your kernel is new enough, and your database is suited to
it, that you try using raw file systems, at least for the larger tables.

Our IBM support here in Switzerland advised strongly against using raw
devices with DB2 v7 due to many unresolved issues. Anyway, the data we are
talking about is in a 'small' table (~200000 rows), the only table in the
database instance.

OK. I am running DB2 V8.1.6 (and ran V8.1.5 for a little while) and that
worked just fine with RHEL 3 ES. That came with kernel-smp-2.4.21-4.EL
and is now running with 2.4.21-15.0.4.ELsmp. I never ran with V7. I went
straight from V6.1.something to V8.1.5. And whatever kernel Red Hat Linux
7.3 had (that I ran on my old machine) did not support raw file systems.

--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 06:55:00 up 1 day, 22:30, 3 users, load average: 4.08, 3.67, 3.76

Nov 12 '05 #21

P: n/a
Many thanks to those who took the time to help. We have found the problem:
the tablespaces created by DB2, the 4kB tablespaces, had the transfer rate
set to 46000, whereas 0.9 is the normal value. Strangely enough, these seem
to have been automatically assigned initially when DB2 was installed. This
was giving the optimizer incorrect information on how to optimize the
queries correctly. The timerons now needed for table scan SQLs are now
almost identical on Linux and Windows and we have another happy customer.

Regards

Rudolf Bargholz
"Rudolf Bargholz" <ba******@spamcop.net> schrieb im Newsbeitrag
news:10***************@fuchs.cyberlink.ch...
Hi,

I have a ralatively simple SQL:

select FK from TABLE where upper(A) like 'B%' and upper(C) like 'D%'

We have DB2 UDB v7.1 FP 12 installed on Linux and on Windows 2003

On Linux using optimization level 5 as well as 9 and 0 the SQL uses
3'100'000'000 timerons !
On Windows 2003 the SQL needs 26'000 timerons

We have tested with SUSE Linux 9.1 as well as Redhat 7.2 , both with the
same dramtic results. And no, the number of zeros is correct.

The Table TABLE has 140'000 rows. The result set of the SQL returns 200
rows.

Any idea what could be causing this difference. The access plans are
identical (TABLE -> TBSACAN -> RESULT) but one is acceptable, the other not.
Runstats have been executed on both tables.

Another problem we have seen is, when we add an index on column A, the
access plan becomes totally different. DB2 will perform an index scan on
TABLE, then performs a FETCH and joins the result of the index scan with
TABLE (!), then does a TBSCAN and then returns the RESULT. The FETCH in this case takes 3'000'000'000 timerons.

As I mentioned above, we tested using optimization levels 0, 5 and 9.
Comparing the optimized SQL on Windows and Linux showed, that no
optimization was necessary, neither on Windows, nor on Linux.

Any ideas?

Regards

Rudolf Bargholz

Nov 12 '05 #22

P: n/a
Rudolf Bargholz wrote:
Many thanks to those who took the time to help. We have found the problem:
the tablespaces created by DB2, the 4kB tablespaces, had the transfer rate
set to 46000, whereas 0.9 is the normal value. Strangely enough, these seem
to have been automatically assigned initially when DB2 was installed. This
was giving the optimizer incorrect information on how to optimize the
queries correctly. The timerons now needed for table scan SQLs are now
almost identical on Linux and Windows and we have another happy customer.

I am surprised if it is true that DB2 put values like that in by default.
I have run DB2 V6.1.* and now DB2 V1.8.6 on Linux and have not had
performance problems as serious as yours were. But I do not know what the
defaults are, since I measured mine with hdparm(8) and used those values.
I am not all that sure how accurate hdparm() is, but it is a place to
start. So mine are set to:

CREATE TABLESPACE INDICES [on 10,000rpm SCSI drives]
MANAGED BY DATABASE
USING (DEVICE '/dev/raw/raw4' 3976087
)
EXTENTSIZE 64 PREFETCHSIZE 64
BUFFERPOOL BP_INDICES
OVERHEAD 7.5 TRANSFERRATE 0.12;

CREATE TABLESPACE DATA_SMS [on 7,200rpm EIDE drives]
MANAGED BY SYSTEM
USING ('/dataB/stock/user'
)
EXTENTSIZE 16 PREFETCHSIZE 16
BUFFERPOOL BP_DATA_SMS
OVERHEAD 13.5 TRANSFERRATE 0.095;

I am not sure I believe the transfer rate on the (100MHz) EIDE drives is
that much faster than the SCSI drives on an Ultra/320 LVD controller.

46 seconds to read a page seems a pretty slow transfer rate, and probably
a floppy disk is much faster than that. In the bad old days, I had a
punched paper tape reader that could read 12K bytes in about 45 seconds. ;-)

--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 10:15:00 up 2 days, 1:50, 3 users, load average: 4.03, 4.08, 4.12

Nov 12 '05 #23

P: n/a
Hi Rudolf,

I am new to this thread...but I did not see were anyone considered
that maybe the Windows 2003 server internally uses a different block
size to write to disk than Linux does. If so, couldn't this account
for the overflows listed below.

Also, I know you do not want to move to v8 becaus of dual support
issues. I will add to this by saying that I support v7.2 and v8.1. We
have to run a special build on v8.1 because v7 clients connecting will
cause trace files and a v8 client connecting to a v7.2 database can
cause the database to crash.

Chet West
"Fabrizio Napolitano" <fn*********@belgacom.net> wrote in message news:<c9*************************************@myga te.mailgate.org>...
Hi Rudolf,

At database creation time are you using
the defult settings for the tablespace creation?

If yes are you sure that they are the same on Windows and Linux?
Isn't it by chance that you have different pagesizes fro your
tablespaces?

One more question how come the two table have different cardinality
(even if slightly)?

Hope this help

Fabrizio

Tabname Card Npages Fpages Overflow

Windows:
TEILNEHMER 139352 6503 6503 0

Linux:
TEILNEHMER 141454 7162 7162 50

Nov 12 '05 #24

This discussion thread is closed

Replies have been disabled for this discussion.