At 03:49 PM 11/29/2004, Vlad Horsun wrote:

> >
> > When you create it you don't know which table it is going to be attached
> > to. You may pass blob to view or stored procedure and don't know the
> > destination table at all. What tablespace should engine use to store
> > this blob?
>
> Can't say right now. I must to teach himself how blobs are handled

Blobs are created on database pages in the cache. The page is
allocated by change the state of a bit on a space management page
(aka page information page or PIP). A precedence relationship is
established between the PIP and the soon-to-be blob page so the
PIP will be written before the blob.

When blobs were imagined, a system with a whole megabyte of physical
memory was huge, so it often happened that portions of the blob had
to be written to disk before the whole blob was materialized. Since
we've got more memory and since the problem with large caches has
been solved, there's no reason that any but the largest blob would
ever be written before being materialized. (Materializing a blob
is what happens when a temporary blob id is stored in a record.)

So, the answer to handling blobs is to allocate the pages as if they
were coming from the main file, then, if they're actually going to
a temporary table in a temporary file, readjust the mapping and
release the space reserved in the main file by setting the bits on
the PIP back to zero.

Fixing the problem with temporary blobs in read-only tables
could be done in a similar manner - faking the changes to the
PIP in some manner. There could be a problem is a temporary
blob associated with a read-only database were larger than the
cache, but perhaps that could be handled as an error?


Regards,


Ann