Fix the orphans before running the upgrade perhaps?

I had no problem upgrading a 4 GB content database - the key thing is to
make sure that what you have before the upgrade is in pristine condition.

How about a 20 GB content database that has a 130GB log file. Looks like we may
have to hand create MOSS Portal to look as much like the existing 2003
production portal and then manually copy documents and receate list items.

Why not shrink down the log file? Typically we run our maintenance plans on
SQL server to discard them quickly after they've been committed. The only
reason I can see to keep them around to accumulate to 130 GB would be if
you're doing log shipping.

From my experience, database size hasn't been too much of an issue. I performed
a gradual upgrade of a 43GB content database and it worked fine. I iniitially
had issues  with orphaned objects, and after a call to PSS, the fix actually
turned out to run the SPS backup/restore utility. It seems that the API for
this application has some kind of brute-force mechanism in place to "deal with"
orphaned objects.

Yup, there was a SharePoint update that came out last summer which adds the
ability to get rid of the orphans rather than performing a WSS split.

We are doing Gradual Migration.For some sites we migrated successfully.
but for some sites we are facing challenges..

We got the update from Microsoft for repairing database and repairing orphan
sites..
We repaired the database and then we got one orphan site and we deleted the
orphan sites

now we are getting the orphan sites count is 0.

Then we run prescan.exe.
We got the following error in the log file.
05/30/2007 12:05:59 Restoring quota and locks on SPSite
97eb08dc-8acd-4fc8-9d54-6acfcc1a63db
05/30/2007 12:05:59 Checking if
Server="I-SHARE1";Database="more2_SITE";Trusted_Connection=yes;App="
prescan.exe" is a WSS V2 SP2 database.
05/30/2007 12:05:59 Checking if any site has not yet been scanned in
Server="I-SHARE1";Database="more2_SITE";Trusted_Connection=yes;App="
prescan.exe".
05/30/2007 12:05:59 Error: The following site has not been scanned. Id =
97eb08dc-8acd-4fc8-9d54-6acfcc1a63db and Url = /sites/ps
05/30/2007 12:05:59 Checking if any list has not yet been scrubbed in
Server="I-SHARE1";Database="more2_SITE";Trusted_Connection=yes;App="
prescan.exe".
05/30/2007 12:05:59 Error: Prescan has encountered sites or lists that were
not updated because they cannot be accessed using the SharePoint Products
and Technologies object model. The most likely reasons for Prescan to skip a
list are covered in the Knowledge Base article at:
go.microsoft.com/fwlink/?linkid=69958&clcid=0x409.

You can also set your database recovery mode to "Simple" and it will truncate
the transaction logs automatically once they're committed. Since we don't offer
point in time recoveries we do this for most of our DBs.

but how do you set the DB recovery mode to Simple?
I am asking because we have a log file that is up to 9.9 GB and all
attempts to shrink it are now working.

You can go into SQL Enterprise Manager, or SQL Management Studio if you're
running SQL 2005. From there, navigate to the properties of the database, and
there should be a tab labeled Options. You can switch the recovery model from
Full to Simple from there.

Now working or Not working?

The setting will only truncate the transaction logs, it will not shrink them.
However, if your logs stay small because of the constant trucation, they
shouldn't grow to be too large.

Yes, and by truncating them, they'll be in essence shrinking the amount of
disk space. You're right, transactions are transactions they're not going
to change in size, but the amount of disk space that they consume will
shrink.

I'm a personal fan of just having a maintenance plan run every 15 minutes on
the active node of the SQL cluster to flush out the transaction logs that
are old.

Truncating logs does not reduce disk space they consume. You must also
shrink the log file.

From http://support.microsoft.com/kb/873235, "The backup operation or
the Truncate method does not reduce the log file size. To reduce the
size of the transaction log file, you must shrink the transaction log
file. To shrink a transaction log file to the requested size and to
remove the unused pages, you must use the DBCC SHRINKFILE operation."

See also http://support.microsoft.com/kb/907511 for how to use DBCC
SHRINKFILE.

I don't know if this will help, but you might try checking and deleting items
from your
Recycle bin. Sometimes when you create and delete a lot of items in SPS the
Recycle bin dosn't delete them for a month.