A first look at Microsoft SQL Server 2008 R2

At TechEd North American 2009, Microsoft announced that its next release of SQL Server - codenamed Kilimanjaro - will now be dubbed SQL Server 2008 R2.

Although IT professionals and the general public are used to seeing R2 at the end of Microsoft product releases, many of them still want clarification on what it means for SQL Server.

Typically, Microsoft follows a cycle of alternating between major and minor releases of its products. Therefore, major product releases, like SQL Server, Windows and Exchange Server, usually don't undergo major changes for at least four years. Minor updates however, like with the R2 product line, are usually introduced every two years or so.

In this article I'll provide an overview of the benefits, new features and improvements to expect with SQL Server 2008 R2.

Improved scalability

By leveraging the new hardware enhancements associated with the Enterprise Edition of Windows Server 2008 R2, SQL Server 2008 R2 will be able to support up to 56 logical processors and 2 TB of RAM. These enhancements will allow organizations to handle significantly larger workloads as well as increase the number of servers, instances and databases that can be consolidated on a single platform.

Consolidation tools

Consolidation is a great way to reduce total cost of ownership associated with a SQL Server 2008 infrastructure. Unfortunately, the analysis that is affiliated with gathering existing data – including performance metrics - is rather time consuming and in many cases can cause a halt in the consolidation initiative.

SQL Server 2008 R2 will address this anomaly by offering a new set of tools designed to simplify the information gathering process and thereby decrease turnaround time when consolidating instances and databases.

Stronger management for multiple instances and databases

Another challenge DBAs are faced with when consolidating numerous instances on a single host with SQL Server 2008 is the need for a robust toolset to manage workloads between all instances within that host.

For example, although IT professionals can leverage the Resource Governor within an instance, it cannot manage workloads across multiple instances. By implementing new centralized management servers with SQL Server 2008 R2, IT professionals can rapidly add databases into a centralized server, view elements holistically through a centralized dashboard, and extend policies from the centralized server to manage workloads, databases and instances across the SQL Server infrastructure.

This new feature is sure to be met with excitement from DBAs.

Pervasive insight with business intelligence

Self-service analysis with project Gemini should allow for tight integration with SQL Server 2008 R2 and the upcoming release of Office Excel 2010. Through Excel 2010, end users can not only generate and integrate reports from multiple sources, but they can also perform various types of analysis including calculations on millions of records at expeditious speeds.

IT professional will also see a tight integration with SharePoint 2010, where reports are published for centralized viewing while various levels of security and versioning are applied.

The buzz behind self-service is heightened by the understanding that organizations will no longer require expensive consultants to manufacture BI reports as the knowledgeable worker should be able to leverage SQL Server, Excel and SharePoint to complete most tasks. Thus far, it seems that there will be many cost saving benefits with SQL Server 2008 R2.

Master Data Services

Most organizations have multiple copies of data or databases throughout their enterprises. For example, an organization's sales department may be using a customer database that is completely different than the one used by the marketing department.

The inaccuracies and inconsistencies of different databases can lead to wasted time, incorrect decisions, and, in some cases, revenue loss. By integrating Master Data Services with SQL Server 2008 R2, organizations can achieve data continuity and consistency throughout their enterprises by centralizing master data and, if necessary, tracking down versions of master data to a specific point in time.

Reporting server enhancements

One of the biggest additions to SQL Server 2008 was the ability to extend location based data through spatial data. SQL Server 2008 R2 Reporting Services goes even further by extending the capability of geospatial visualization through maps, routing and custom shapes. Moreover, reporting gets a facelift by providing developers and end users with powerful new tools to author, centralize and implement reports in a centralized manner.

SQL Server 2008 R2 is currently in development and is tentatively scheduled for release in the first half of 2010. Because of the tight integration with SharePoint 2010 and Office Excel 2010, the release date will be in conjunction with the next Office 2010 product release.

A Community Technology Preview (CTP) will most likely be offered this summer, and you can register for a SQL Server 2008 R2 CTP notification via Microsoft's website. Finally be aware that this article was written based on public information on SQL Server 2008 R2. Since the product is in beta, the features and functionality discussed are subject to change.

Configuring YUM on Linux

Yellow Dog Updater Modified (YUM)

For any yum newbie's, a quick definition and a look at history. YUM is a package manager (an installer and remover) for RPM systems. It is tailor made to update groups of machines without having to update each specific RPM. The software locates and obtains the correct RPM packages from repositories, freeing you from having to manually find and install new applications and/or updates. The beauty of YUM is in its simplicity. You can use a single command to update all system software. Way back when, RHEL4 used to use up2date as its package manager – RHEL5 uses YUM, based on version 3. Upd2date is actually used as a wrapper around YUM in RHEL5. The product was developed by Seth Vidal (who now works for Red Hat) and a group of volunteer programmers and coded in Python. It is now up to version 3.2.22.

yum.conf

The file itself is made up of two sections. The first is the main section and the second is the repository section. You have a choice to put your repositories in this file or in separate files named file.repo. You can have more than one repository in one configuration file but there can be only one main section. Here is an example of a yum config file.

main]
cachedir=/var/cache/yum
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
pkgpolicy=newest
distroverpkg=redhat-release
tolerant=1
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
metadata_expire=1800
timeout=10

[myexamplerepo]
name=RHEL 5 $releasever - $basearch
baseurl=http://local/path/to/myyum/repository/
enabled=1

Let's describe some important fields:

Cachedir: The directory where yum stores its cache and database files.

Keepcache: There are two choices here, 0 and 1. 1 informs yum to keep the cache of headers and packages after a successful install. The default is 1.

Tolerant: There are two choices here, 0 and 1. Setting this as 1 allows yum to be tolerant of errors on the command line. The default is 0.

Grpcheck: There are two choices here, 0 and 1. 1 enables GPG checking, which provides for GPG signature checking on packages on all repositories. This includes local package installation.

Metadata_expire: This is the time in seconds – after which the metadata will expire.

Timeout: This is the number of seconds that one would wait for a connection prior to timing out.

Exactarch: There are two choices here, 0 and 1. 1 tells YUM to update only the architectures of installed packages. For example, if you have this enabled you won't be able to install an i386 package to update an i686 package.

Obsoletes: This effects updates only and enables the processing logic of YUM. It's particularly useful when doing distribution level upgrades.

The repository section has the information required to find packages during package installation, updating and dependency installations. The mandatory field descriptions are as follows:

ID: a unique single word string which is the identifier of the repository.

Name: The string that describes the repository.

Baseurl: The url where the actual repository is housed.

Some optional fields include; gpgcheck, gpgkey, exclude and include. The exclude and include fields are similar to the ones used in the main section of the file, but apply only to a specific repository.

If you are shy about manually editing config files, than I would be extremely careful before doing so. Better to use some GUI software to help you configure YUM, than mess up a currently running YUM-based system. If you are going to edit these files manually, make sure you first play around with them in a test environment and/or have good backups. It just takes five seconds to issue the following command:

# cp /etc/yum.conf  /etc/yum.conf.old

Please use this command prior to manually editing this file.

yummy commands

YUM has dozens of commands that are part of its system. Try to learn some of the key commands that you'll be using routinely. In this section we'll discuss some of these commands.

# yum list

This lists out all packages in all repositories which are installed on the system. There are a variety of options with this command. One option is:

# yum list installed 

This is similar to running an rpm –qa, which breaks down a list of all installed packages. By default yum list without any options will list all packages in all the repositories, and all the packages installed on your system. (Note: "yum list all" and "yum list" give the same output.)

# yum info

Displays information about any package – either installed or available.

# yum search

Allows you to search for information from metadata available, about packages.

# yum clean

The yum clean command allows you to clean up the cached files of metadata and packages which YUM uses during its normal operations. This will clear up a lot of disk space.

# yum groupinfo groupname

This provides you with detailed information for each group including description, mandatory, default and optional packages.

We've focused on using YUM on RHEL, but it should also be noted that SLES10.1 has added support for YUM repositories in YaST. Many other distributions also provide YUM support – though some do not, so if YUM is really important to you, you should check your documentation carefully. Finally, as those of you who have already worked with YUM realize, it has a command line utility only. If you like GUI software there are also several GUI utilities which interface with YUM, including pup, pirut (the default Fedora GUI as of version 5), and Yum Extender. YUM may not be rocket science to use, but you will need to take some time to learn it properly. Like any other new software, the more time you spend learning it and playing with it in a sandbox the less time you will spend in having to fix it later.