Re: Informix vs. Sybase vs. Oracle vs. (gasp) MS SQL Server

From: David Williams <djw_at_smooth1.demon.co.uk>
Date: 1997/04/18
Message-ID: <Mi+ETXAWw8VzEweE_at_smooth1.demon.co.uk>#1/1


In article <5j5tv5$14s_at_mew.corp.sgi.com>, Pablo Sanchez <news_reader_at_mew.corp.sgi.com> writes
>
>In article <frLQBCADmlVzEwN4_at_smooth1.demon.co.uk>, David Williams
><djw_at_smooth1.demon.co.uk> writes:
>> In article <5j39eg$2sj_at_mew.corp.sgi.com>, Pablo Sanchez
>> <pablo_at_mew.corp.sgi.com> writes
>> >
>> >In article <0v8awLAcPRVzEwpS_at_smooth1.demon.co.uk>, David Williams
>> ><djw_at_smooth1.demon.co.uk> writes:
>> >A big ++++ for Sybase that Informix currently does not have is
>> >that the buffer cache can be partitioned and tables/indexes... can
>> >be found to portions of the cache. Rather than treating the cache
>> >as an unknown, the DBA is allowed to micro manage it. They can
>> >change the wash section, I/O pool size (for reading/writing)....
>> >quite nifty.
>>
>> Surely this will reduce performance for unbound cache entries?
>
>Absolutely!
>
>Of course typical DBA action would be (atomically):
>
> 1) create the named partition (Sybase lingo)
> 2) create the I/O pools within the named partition
> 3) bind one or more objects to the pool.
> 4) run a bench and monitoring tool to ensure that it's being
> used.
>
>A neat idea (well, okay, IMHO) is that you can have a configuration
>for "normal" operation and a configuration for "crunching"
>operation. Cool eh?
>
  Cool.

>> I would have thought that binding objects into the cache only
>> helps in limits cicumstances??
>
>Most applications benefit from it because minimally you can create a
>named partition for your database log(s) and bind them to it. The
>high turnover rate of dirty buffers is now restricted to a small area
>in memory. Neat eh? And of course, if you have a mixed workload on
  But Online uses seperate buffers for logging - 3 logical log buffers and 2 physical log buffers. These are separate from the normal buffers which buffer database pages rather than log pages.

>your RDBMS, you can bind frequently scanned tables to a named cache
>so that they don't flush out the working set established in the
>"default cache."

  If you have frequently scannign tables you will be using a DSS application hence should be using PDQ and LIGHT SCANS (scans which do NOT utilise the normal buffers hence do not affect the working set in normal BUFFERS.

>
>> Informix has a logical log buffer - up to one logical log can
>> be buffered at a time - I'm not sure what the I/O size is that
>> is used for writing logical log buffers to disk...
>
>This is *my* weakness because we didn't go into this in class like I
>thought we would (no fault of the instructor... he had a lot to
>cover) and next thing ya know, the class was over! :-(... I really
>want to learn more about how connections send their transactions to
>the logical log and how the physical log relates to the logical log.
>
>Any reading you recommend? and/or websites with info?

   Online Admin Guide Version 7.1 Volume 1    Section v Logging and Log Administration.    

   Especially
   Pages 22-23 to 22-24 (overall logging description)

   Chapter 20 (What is Logging)
   Chapter 24 (Physical Logging) and
   Chapter 26 (What is Fast Recovery)

>--
>Pablo Sanchez | wk: 415.933.3812| pg: 800.930.5635 -or- pablo_p_at_pager.sgi.com
>--------------+-----------------+--------------------------------------------
>pablo_at_sgi.com ... when mailing me, place "not spam" in the Subject
 
-- 
David Williams
Received on Fri Apr 18 1997 - 00:00:00 CEST

Original text of this message