Logo 
Search:

Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

SPUtilSuite disturbing behavior

  Asked By: Dominique    Date: Dec 27    Category: Sharepoint    Views: 704

I'm running the SPSiteManager utility to re-partition sites into different
content databases. The actualy partitioning seems to work great, but I got a
call from a user complaining that their site no longer existed! This was a site
that I created the same day that I was working with this utility, so no data was
lost, but I was very concerned about utilizing this in the future. Even though
this site had nothing to do with the partitioning exercise, I could find no
indication of its existence in the config DB or content DB. Has anyone else
ever experienced this issue? As much as I love the ability of this tool, I will
never use it if it has the potential to damage production data.

Share: 

 

7 Answers Found

 
Answer #1    Answered By: Lesley Tate     Answered On: Dec 27

All SPSiteManger ever did when repartitioning sites  is simply a

1) site  Collection backup using one API call

2) Delete of the Site Collection from the existing location

a. Do some magic in between so that the target database is the
only database that can receive the new site so it goes where you want
it.

3) Restore of the site collection to the new database using one API
call.

a. Undo some magic.

If the site the user  is complaining of being missing is not the site you
were repartitioning, I'm going to say SPSiteManager had nothing to do
with it.

SPSiteManager never used anything that was not publicly available via
the completely supported SharePoint object model, and it will do no
damage other than the typical damage one could do to themselves using
STSADM -o backup/delete/restore

With that said, nothing is ever perfect, just like having a perfect
environment to run backups J SO you should always ensure you have a good
backup of your system before doing anything such as a batch of
repartitions.

Regardless, at the beginning of the SPSiteManager documentation, I list
how to do that same thing all manually from what you need to set in the
SharePoint Portal 2003/WSS Central Admin UI, and STSADM operations.

 
Answer #2    Answered By: Vinay Thakur     Answered On: Dec 27

I don't want you to think that we're "blaming"
this tool for our experienced behavior. I just found it very strange that this
would occur on an otherwise stable system at the same that this operation was
taking place.

As a follow-up question, does SPSiteManager support the partitioning of a site
from a database that is not an online content database? My thoughts were that I
would perform a backup of our production content DB to a "dummy" DB and then try
to partition the site  in that manner. That way the partitioning effort wouldn't
be touching our production content DB at all.

All SPSiteManger ever did when repartitioning sites  is simply a

1) Site Collection backup using one API call

2) Delete of the Site Collection from the existing location

a. Do some magic in between so that the target database is the
only database that can receive the new site so it goes where you want
it.

3) Restore of the site collection to the new database using one API
call.

a. Undo some magic.

If the site the user  is complaining of being missing is not the site you
were repartitioning, I'm going to say SPSiteManager had nothing to do
with it.

SPSiteManager never used anything that was not publicly available via
the completely supported SharePoint object model, and it will do no
damage other than the typical damage one could do to themselves using
STSADM -o backup/delete/restore

With that said, nothing is ever perfect, just like having a perfect
environment to run backups J SO you should always ensure you have a good
backup of your system before doing anything such as a batch of
repartitions.

Regardless, at the beginning of the SPSiteManager documentation, I list
how to do that same thing all manually from what you need to set in the
SharePoint Portal 2003/WSS Central Admin UI, and STSADM operations.

 
Answer #3    Answered By: Lynn Mann     Answered On: Dec 27

I didn't take it that way at all, no worries whatsoever.

You can't backup/restore/delete a site  that isn't in the database list
for a SharePoint virtual server. Not sure what you mean by Offline
though. Do you mean the "Offline" status in the manage databases  page
in SharePoint? If so, that's actually part of what SPSiteManager does
when it's doing it's magic to target a specific database for the
restore,

But...

You don't want to take a database from an existing server, rename to
something else, and add it back into that same farm. You'll have
conflicts when SharePoint adds that database into the farm, as that
would create duplicate SiteIDs in the configuration database, and that
just spells trouble.

What you can do, is take that database, put it on a test server
connected to a different farm database...Then do your work, when that's
complete restore back to production.

 
Answer #4    Answered By: Damini Dande     Answered On: Dec 27

It's late for me, so I'll describe my process and see if it matches up.

I would start by creating a new database called WSS_COPY. I would take a SQL
backup of our production database and restore it to WSS_COPY on the same server.
This wouldn't be a content database, per se, because I wouldn't attach it to any
particular IIS virtual server. It would, however, have all relevant site  GUID's
and listings for the sites  I intend to migrate. I would then create another
database called WSS_MIGRATE. This database will be the destination DB for the
SPSiteManager partition activity.

I'm hoping that SPSiteManager would work  with WSS_COPY just as it would
interact with an actual content database by following the process that you
defined in your original reply. Once the app has deleted the site listing from
our WSS_COPY, it would insert it into WSS_MIGRATE. I would then detach that
database and move it over to our new MOSS 2007 environment and attach it to the
corresponding SQL environment.

So, after all of that, now you can tell me it won't work.

 
Answer #5    Answered By: Irving Hurley     Answered On: Dec 27

It won't work  The database would have to be hooked up to SharePoint,
as SPSiteManager using the SharePoint API's to work with the data
Therefore it would need to be attached to a SharePoint extended virtual
server.

But, you can't attach it to a SharePoint virtual server in the same
SharePoint farm (ConfigDB)....That's the problem I was speaking of
earlier.

 
Answer #6    Answered By: Lalit Bhattacharya     Answered On: Dec 27

Understood. I'd have to temporarily remove the production content DB and then
add the wss_copy database to avoid the problem with duplicate GUIDs. Once the
partition is complete, it seems like I could then remove the temp database and
replace it with the production database.

 
Answer #7    Answered By: Gwendolyn Acosta     Answered On: Dec 27

When you remove a content database from the list of content databases
for the virtual server, SharePoint removes the entries from the Sites
table in the ConfigDB.

 
Didn't find what you were looking for? Find more on SPUtilSuite disturbing behavior Or get search suggestion and latest updates.