I backed up and restored 2 content databases to a different farm. The content databases were serving applications originally on ports 33333 and 44444. Executing -o addcontentdb on the new farm to the 44444 port, for either database, works fine. When i brought these backups back to the original farm, i cant restore the 44444 content database to anything other than the 44444 port, even though the 33333 was restorable to 44444 on the other farm.
The content database gets added by the -o addcontentdb command, but it reports 0 sites…
Perplexing.
So…
Tried to move a SharePoint database set from one SQL 2005 server to another. Steps I took were:
1. SQL Backup all the databases
2. SQL Restore all the databases to the new SQL server
3. stsadm.exe -o renameserver -oldservername oldserver -newservername newserver
3.1. Reboot
4. ???
5. Failure
Step three reported success… we rebooted, and looked at the site and its up. Wahoo we think. No. Still using the old database? Hrmmm… So we executed the command again. We got something like this…I didnt copy and paste it, though i might get the actual error later…
No reference to server oldserver in database.
( or something )
So now what… i guess ill try a full sharepoint farm back up and restore to the same farm.
This seemed to work a lot better. Full SharePoint backup. Full SharePoint restore…until search wasnt working anymore. Turns out the permissions the service account I restored the SSP services and so on with were not enough in the new database server. Ended up having to confirm all the permissions for the services accounts in the database, and go from there.
Anything to do with backup and restore you pretty much need SA on the database and local Admin on the WFE to avoid pain and suffering. sigh.
Our DBA team told us we needed to delete some databases off our development sharepoint 2007 farm, cause “they get too big”. Some subtle questioning pushed aside, and not being a big fan of ignorance, we took a look around the interwebs for an explanation….
Thanks “siteadmin”, you rock.
Database Log Size Blog Link
The gist is: learn to maintain sql 2005 databases you schmucks. You need to backup the database and logs BOTH or the logs dont get truncated. Non-truncated logs = freaking huge.