I am still a DBA at heart, but this BI stuff is getting to be a lot of fun and if you aren’t getting into it you are missing out.  Even for the hard-core DBA’s there are a lot things you can do with BI to make your DBA life much easier.

Today I found a tremendous white paper to help move from a single server to what I will “normal” or a “typical” SharePoint multi-server deployment.  The white paper, from the SQL CAT team, can be found here.

It is worth noting that if you are now going to deploy PowerPivot to more than a handful of users it is my opinion that you should start with a multi-server deployment.  To ensure you get there if possible I would follow the instructions for a single server deployment and then confirm it is working as expected.  Then I would follow the instructions for moving that to a multi-server deployment.

PROPS to the SQL CAT team!!

Ron Pihlgren managed to save the day!  Turns out you need to have the Shared Features installed so that you get the VSTO runtime installed so powerpivot will run.  His full post is here.

If you are moving to new hardware and don’t have to keep the same hostname or instance name it can be as simple as backup, copy, restore (detach, copy, re-attach).  Plus several other things to think about like, users, user-defined data types, functions, etc to ensure your new system works properly. 

If you do need to perform and in place upgrade Cindy a some very useful steps I have included below.

You want to upgrade this instance from SQL Server 2000 32bit to SQL Server 2005 x64 on the same box. You would like to keep the same instance name. However, we do not support an in-place upgrade from any 32bit SQL Server to any 64bit SQL Server. Additionally, you cannot restore system databases (master, model, tempdb, msdb) to a different version, not even a different service pack or hotfix level.

· Version and Edition Upgrades "Upgrading a 32-bit instance of SQL Server 2000 from the 32-bit subsystem (WOW64) of a 64-bit server to SQL Server 2005 (64-bit) on the X64 platform is not supported. However, you can upgrade a 32-bit instance of SQL Server to SQL Server 2005 on the WOW64 of a 64-bit server as noted in the table above. You can also backup or detach databases from a 32-bit instance of SQL Server 2000, and restore or attach them to an instance of SQL Server 2005 (64-bit) if the databases are not published in replication. In this case, you must also recreate any logins and other user objects in master, msdb, and model system databases."

· You cannot restore system database backups to a different build of SQL Server "You cannot restore a backup of a system database (master, model, or msdb) on a server build that is different from the build on which the backup was originally performed."

· If the SQL Server versions are the same, even system databases can be restored between different platforms (x86/x64). However, you do sometimes have to make one update to the msdb database when you do this (because often the SQL Server install path has changed, such as using "program files (x86)" on an x64 system). For non-system databases the version you restore to doesn't have to be identical, generally you can restore a user database to a higher version and the platform (x86/x64) is irrelevant. Error message when you restore or attach an msdb database or when you change the syssubsystems table in SQL Server 2005: "Subsystem % could not be loaded"

So in this case you have two basic options if you must keep the same server and instance name:

1. Upgrade, reinstall, attach

a. Make sure all users, applications, and services are totally off the system for the entire duration of the downtime

b. Upgrade SQL 2000 SP4 32bit to SQL 2005 (or 2008) 32bit (NOT x64! - that is not a viable upgrade path)

c. Backup all databases

d. Detach the user databases (the detach does a checkpoint to ensure consistency)

e. Make copies of the mdf/ldf files for user and system dbs

f. Uninstall SQL Server 2005 32bit (to make the instance name available)

g. Install SQL Server 2005 x64 to the same instance name and at the EXACT same version as what was just uninstalled

h. Restore master, model, msdb

i. Attach the user databases

j. If needed, run the update from Error message when you restore or attach an msdb database or when you change the syssubsystems table in SQL Server 2005: "Subsystem % could not be loaded"

k. Apply the appropriate Service Pack and/or Cumulative Update

l. Take full backups

m. Allow users back in the system

2. Reinstall, attach, copy system db info

a. Make sure all users, applications, and services are totally off the system for the entire duration of the downtime

b. Backup all databases

c. Extract all relevant information to allow re-creation of system database information. This includes logins/passwords, configuration settings, replication settings, linked servers (including login mappings), custom error messages, extended stored procedures, MSDB jobs, DTS/SSIS packages stored in MSDB, proxies, any objects manually created in any system database. If you go this route let me know and I'll double check that this list is complete.

d. Detach the user databases (the detach does a checkpoint to ensure consistency)

e. Make copies of the mdf/ldf files for user and system dbs

f. Uninstall SQL Server 2000 32bit (to make the instance name available)

g. Install SQL Server 2005 x64 to the same instance name.

h. Attach the user databases

i. Apply all the system information you extracted above including sync'ing users to the new logins.

j. If needed, run the update from Error message when you restore or attach an msdb database or when you change the syssubsystems table in SQL Server 2005: "Subsystem % could not be loaded"

k. Apply the appropriate Service Pack and/or Cumulative Update

l. Take full backups

m. Allow users back in the system

Happy upgrading!

A comparison of the feature differences of the various versions of SQL found here.

In short it comes down to performance improvements, high availability improvements, cost savings with compression, improvements in database maintenance for mission critical systems, and  taking advantage of all the BI features and being able to scale those features to large user bases. 

Bob Duffy wrote an excellent overview and I recommend reading his full post can be found here.  I have summarized some of his information below.

Quick list of reasons for choosing Enterprise Edition for your deployment

• More than a two node cluster (such as 3+ nodes)
• Utilize more than 4 cpu sockets
• Database Mirroring enchancements (multithreaded mirroring)
• Database compression
• Web Farm for Reporting Services
• Partitioning, table or cubes.
• Advanced BI features
• The list goes on..

SP1 includes some great fixes that we available in the previous CU releases.

Report Builder 2.0

Service Pack Uninstall without removing the instance

Check out the release notes https://download.microsoft.com/download/1/6/3/163A851B-D956-42E9-B426-F5C0EBE6B654/ReleaseNotes.htm

Happy installing!!

Quick blurb on New Year's resolutions - More frequent blog posts that contain useful and helpful information as I have not posted for several weeks now.

I have been setting up a lab environment for my use over the past few days.  While setting up SQL 2005 SSRS on windows server 2008 I ran into a few snag that wanted to make sure that I put out there for people to be aware of.  Based on my searching a few people have been running into this as well.  If you want to skip the details the information to fix the issue , or issues, can be found at https://social.msdn.microsoft.com/forums/en-US/sqlreportingservices/thread/48a1e733-1a47-4c79-b01e-d84fafa779b4/

After I installed SSRS (did not configure during install) and then configured it with the configuration tool I would get the following error when trying to connect "An error occurred while parsing the configuration file.  The ReportServerVirtualDirectory element is missing."

To fix this error I opened my RSWebApplication.config file and I noticed something interesting about 4th line down <ReportServerVirtualDirectory></ReportServerVirtualDirectory>

There was nothing between the tags.  Simple fix for me was to simply put in "ReportServer" between the tags (See below).   

If you take time to read the entire set of posts on the link above you will see that this corrects only one potentially 3-4 issues with the setup. 

Be sure to take a look at https://support.microsoft.com/kb/938245/ (How to install and how to configure SQL Server 2005 Reporting Services on a computer that is running Windows Server 2008).

-k

Be sure to check out licensing SQL Server in a virtualized environment by going to https://www.microsoft.com/sqlserver/2008/en/us/licensing.aspx 

Performance

·         Database Mirroring Improvements – Automatic page repair, over the wire log compression for reduced latency between primary and mirror instances

·         Performance improvements in SQL Server 2008 to handle the most demanding workload and HUGE database sizes (10’s of terabytes).  Just check out https://tpc.org for more info details.

Manageability

·         Resource Governor – ensure that response times are predictable, by defining workload groups and implementing limits on CPU and Memory

·         Policy Based Administration – Develop one set of policies and roll it out to every server.  Best Practice policies included with SQL Server.

·         Clustering Improvements – SQL 2008 has numerous improvements in clustering capabilities, simpler setup and management to add additional nodes to an existing cluster

·         PowerShell -  Extensible and scriptable to do just about anything you can think of inside your SQL Server setup. 

Cost Savings

·         Native SQL Server backup compression – Reduce the size of your backups by 40-50%.  Backup and Restore time is also similarly reduced. 

·         Reporting Services in SharePoint – New report builder  (which ROCKs by the way)  is much easier to use and will result in spending less time developing rich reports

Security

·         Transparent Data Encryption (TDE) – Ensure your databases are protected by enabling TDE without having to make any changes to your application or code.

·         New Auditing capabilities – Allow you to answer the who, what, and when concerning accessing your data without the need to running SQL Profiler.  Significantly less overhead in running audit.

Want or need more information about these features?  Check out SQL 2008 Books Online on MSDN here.  This list is far from complete, but I wanted to put something out there to get you thinking about the reasons to use SQL Server 2008.