March 2008 - Posts

• How much disk space is consumed in gradual migration?

  The standard answer is 3 times the size of your database. To be more exact, how much disk space is consumed when doing gradual migration for a site collection? When running test migrations, the following pattern is observed (assuming each site collection sits in its own content database): Temp database data file = 2.5 times the size of site collection Target database data file =  1.2 times the size of site collection Temp database log file = 1.2 to 1.5 times the size of target database Target database log file = 1.2 to 1.5 times the size of target database For example, if the site collection is 10 GB, the temp database will be 25 GB and the final target database will be around 12 GB. The log files might take up to 36 GB for both temp and target database.   Posted Mar 19 2008, 04:08 PM by jleung with 1 comment(s) Filed under: Migration, Database

• Database restore and file cache in SharePoint

  I never aware there is file cache for SharePoint configuration.   But there is.   It is located at the %ALLUSERSPROFILE% \Application Data\Microsoft\SharePoint\Config\<GUID> folder. It contains infomation with timer jobs and farm data such as content databases for a web application, site collection count.   So in a system restore scenario in the same farm (same server names), all the sharepoint databases are restored including the configuration database. Note that there may be new activities between the time the config database is backed up and restored on the server. Those new activities are cached in the physical file on the server and they are out of sync with the config db. So when you access the Central Administration website, you start to experience errors in modifying the farm settings!   This is what happened over the past weekend at the client site: null object reference when accessing a content database information inside Central Administration after a config db restore. What makes it even worse, a 404 came back when browsing to the portal site.   After serveral hours of digging and helpless attempt to fix the situation, we discovered that the config db data gets modified minutes after the db was restored.   Central Administration web application is referring data from the config file cache, which is now showing inconsistent data with the restored configuration database, and OWSTIMER.exe is what controlled the file cache. An really really easy way to clear the cache is:   stop the OWSTIMER.exe navigate to the file cache location delete or move all the files inside start the OWSTIMER.exe file cache will be populated with the correct information from the config db repeat above steps on all the servers in the farm with OWSTIMER.exe After re-creating the config cache, Central Administration web application is showing correct values again ...... Knowing the importance of the OWSTIMER cache, I did some google quickly and find some resources about the SharePoint cache: JOPX on SharePoint 2007 - Clearing the SharePoint Configuration Cache Office Online - Configure Object Cache Settings Posted Mar 18 2008, 10:13 AM by jleung with 1 comment(s) Filed under: Configuration, OWSTIMER, Database Restore

• New target database for gradual migration

  In migrating a site collection (not the portal root) of 40GB, the reverts never worked. The reverts timed out and it's this 'hang in the middle situation' where you still see the site collection listed in MOSS 2007 central administration but you cannot see its associating information (such as which content database it resides in). Of course, you also cannot see the site collection among the ones ready to be migrated in the "Select site collection to migrate" page. This happened in one of the trial migration runs. Rebuilding the dev environment would be too time consuming because it involves migrating the portal first to get back to the state prior to migrate the specific site collection.  So...... This discovery was by accident: Before doing all these, you should check the "Database names" page for migration status, all the target databases are listed as read only Disassociate the PAIR database (which contains the migrated portal) from the sharepoint farm in CA --> Application Management --> Content Databases Re-associate the PAIR database to the sharepoint farm (that cleans up the 'bad' site collection associated with the web application) Goes back to the site collection upgrade status page in CA --> Operations Click "continue to upgrade" link next to the URL for migration Click "database names" inside the Actions menu area located on the bottom left hand corner of the page You can enter a new target database name for the orginal content database (change from read only to textbox for editing) Click "Save" and wait for the operation in progress page to finish (If you don't give it a new name for target content database, it will create a new database with guid attached to it) When you go back to the page that shows a list of site collection to be migrated, select the new target content database in the dropdown box and you see that all the un-migrated site collections are there (including the one that stucks in the revert process!) One thing to note: By associating to a new target database, there is no more options to revert those migrated site collections in the old target content database. But in my case, the reverts never worked anyway.   Posted Mar 10 2008, 01:26 PM by jleung with 1 comment(s) Filed under: Migration