THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Tibor Karaszi

  • We are now recommended to install cumulative updates

    Microsoft just released a couple of CUs for SQL Server 2012. What is exiting is how Microsoft phrases their recommendations whether we should install them or not. Below is from the KB of one of those recently released CUs:

    • Microsoft recommends ongoing, proactive installation of CUs as they become available:
    • SQL Server CUs are certified to the same levels as service packs and should be installed at the same level of confidence.
    • Historical data shows that a significant number of support cases involve an issue that has already been addressed in a released CU.
    • CUs may contain added value over and above hotfixes. This includes supportability, manageability, and reliability updates.

    Now, that is a pretty significant change from what they used to say. In addition, requiring the CU is much easier. You just go to MS Download, select whether you want 32 or 64 bit and then download the bits immediately.

    Check it out yourself, go to for instance

    Or check out how the KB for a new SQL Server CU: (see the "Notes for the update" section).

  • Managing the errorlog file

    I frequently see recommendations to regularly run sp_cycle_errorlog, so that the errorlog doesn't become huge. My main concern with that is that the errorlog contains valuable information.

    When I do a health check on a SQL Server machine, I want a few months worth of errorlog information available. I typically use my own scripts for this, available here. Almost every time I go through the errorlog, I find valuable information. Some things you address, like find whatever it is that is attempting to login every minute. Other things you might not have control over, but the information is valuable to have.

    So, if you run sp_cycle_errorlog every day or week, you end up with only a week worth, or a few weeks worth of errorlog file information.

    Suggestion 1: Increase the number of errorlog files.

    You probably want more than 6 history errorlog files. For instance, a client of mine told me that he was about to patch a server a few days before I was to visit that client. That patch procedure resulted in enough re-start of SQL Server so we ended up with only 4 days worth of errorlog files. Yes, this client had the default of 6 historic errorlog files. I typically increase this to 15. You can do this by right-clicking the "SQL Server Logs" folder under "Management" in SSMS. If you want to use T-SQL, you can use xp_instance_regwrite, as in:

    EXEC xp_instance_regwrite
    ,N'NumErrorLogs', REG_DWORD, 15; 

    Suggestion 2: Set a limit for the size of the errorlog file.

    But what about the size? Say that we have crash dumps, for instance. Or other things that start to happen very frequently. The good news is that as of SQL Server 2012, we can set a max size for the errorlog file. There is no GUI for this, so we have to manipulate the registry directly. Again, we can use xp_instance_regwrite. Below will limit the size to 30 MB:

    EXEC xp_instance_regwrite
    ,N'ErrorLogSizeInKb', REG_DWORD, 30720;

    With 15 files, you can patch of your SQL Server machine without aging out all old errorlog files. And with a max size of 30 MB, you keep each file manageable in size. And you keep the total size of errorlog files for that instance to 450 MB. Not enough to fill your disks. But enough to have historical information for when you are about to perform a health check on your SQL Server instance.

    References: this by Jan Kåre and this by Paul Randal.

  • Can you restore from your backups? Are you sure?

    A few days ago, we were doing restore practice drills with a client. I had tested the stuff before this, so the practice was more for the client's DBAs to test various restore scenarios, with me being able to point to the right direction (when needed), supplement the run-book and stuff like that. Always fun, I like these drills!

    Anyhow, This client does regular SQL Server backups to disk (full, and for some databases also log) at 19:00. They also snap the machines every night at 04:00. We don't want to have dependencies on the machine snap, but it is nice to have in case a machine it totaled and we now can restore from such a snapshot. The issue is that this machine snapshot is seen as a full backup by SQL Server. We all know that a full backup do not affect the log backup chain, but the restore GUI doesn't care about that!

    So the restore GUI suggest that you restore from 04:00 full backup (which isn't a restoreable backup as it was a snapshot) and then the subsequent log backups. What we need to do is to restore from earlier 19:00 full backup, and then all log backups - ignoring the 04:00 snapshot backup.

    Fortunately, my client by themselves (without my intervention) did the restore using T-SQL commands, knowing what backup exists, and figuring out what to restore. But I also wanted them to test the GUI, just so they know how that look like. Of course, you can do a restore from 19:00 to 03:55, and script that to a query window. Then then from 04:00 to current time (or whatever) and script that too,. And then stitch these together. But just typing (with some copy-paste) the commands are much easier.

    My point? Test your restores. Do not expect anything. A production situation is not the right time to try to figure these things and trying to cope with it.

    About this snapshot software: The next version is expected to have an option to produce the snapshot as a COPY_ONLY backup. Isn't that great? Now we expect the restore GUI to skip this COPY_ONLY backup, right? No, that was not that I saw. Having an option to produce the backup as COPY_ONLY finally allow us to implement differential backups, but it (from my tests) won't help with the restore GUI issues. Btw, here is a related post.

    Here's a query that might be helpful if you want to see what type of backups are produced. (I appreciate feedback from anybody if you can see if a snapshot backup sets 1 in the is_snapshot column - I don't have environment to test at the moment...)


    SELECT TOP(100)
    ,CASE bs.TYPE
    'D' THEN 'Full'
    WHEN 'I' THEN 'Differential'
    WHEN 'L' THEN 'Log'
    WHEN 'F' THEN 'File or filegroup'
    WHEN 'G' THEN 'Differential file '
    WHEN 'P' THEN 'Partial'
    WHEN 'Q' THEN 'Differential partial'
    END AS backup_type
    ,DATEDIFF(SECOND, bs.backup_start_date, bs.backup_finish_date) AS backup_time_sec
    FROM msdb.dbo.backupset AS bs
    INNER JOIN msdb.dbo.backupmediafamily AS mf ON bs.media_set_id = mf.media_set_id  
    ORDER BY backup_finish_date DESC;



  • Ola Hallengrens Maintenance Solution now supports mirrored backup

    You probably know that you can mirror a backup to several destinations, assuming you are on a supported edition (Enterprise or Developer). This is not the same as striping; you can compare striping to RAID 0, and mirroring to RAID 1.

    Ola now supports mirroring in his maintenance solution, found here. A couple of examples:

    EXECUTE dbo.DatabaseBackup
    @Databases = 'USER_DATABASES',
    @Directory = 'C:\Backup',
    @MirrorDirectory = 'D:\Backup',
    @BackupType = 'FULL',
    @CleanupTime = 24,
    @MirrorCleanupTime = 48

    EXECUTE dbo.DatabaseBackup
    @Databases = 'USER_DATABASES',
    @Directory = 'C:\Backup,D:\Backup',
    @MirrorDirectory = 'E:\Backup,F:\Backup',
    @BackupType = 'FULL',
    @CleanupTime = 24,
    @MirrorCleanupTime = 48

    Note that if any of the destinations are unanavilable, then the backup fails for all destinations. SQL Server do not produce the backup to the ones that are available. This has nothing to do with Ola's solution, it is just how MS decided to implement backup mirroring.


  • Updated sp_indexinfo

    It was time to give sp_indexinfo some love. The procedure is meant to be the "ultimate" index information procedure, providing lots of information about all indexes in a database or all indexes for a certain table. Here is what I did in this update:

    • Changed the second query that retrieves missing index information so it generates the index name (based on schema name, table name and column named - limited to 128 characters).
    • Re-arranged and shortened column names to make output more compact and more commonly used column moved to the right.
    • Uncommented some columns that were previously commented. (At least one, filter, has to be commented if you want to run this on 2005.)
    • Added support for columnstore indexes.
    • Decoded the type for columnstore indexes to col-store.

    You find the procedure here. 

  • Does your 3:rd party backup software ruin your SQL Server backup plan?

    Sounds scary, huh? And it surely can be! Here’s an example of one such case:


    A client of mine had implemented a 3:rd party backup solution in their VM Ware environment. This shouldn't affect the SQL Server backups. Or that was the plan. I won’t mention what backup software this is, since I’m sure that there are other software also doing strange things. And in the end, it is up to you to verify that your backup and restore strategy is solid. So let us just call this software “BACK”.


    BACK performs a snapshot backup of the virtual machine. The client had scheduled this so it happened at about 4 am each day.


    Our SQL Server backups were implements so that 7 pm we did a full backup and every hour we did a log backup.


    Nothing strange here and these should be independent of each other, right? Wrong!


    When looking at the backup history, I realized that SQL Server would see the snapshot backup as a full backup. OK, that will possibly affect out plan to go for differential backups, but it shouldn't affect our transaction log backups. We all know that a database backup doesn't break or affect the log backup chain.


    But what I did find was that BACKUP performed a log backup immediately after the snapshot database backup. And the log backup was taken to the file name “nul”. Yes, the binary wasteland.


    The end result of this was that the log backups that we performed were usable between 7 pm and 4 am. After that, the log backups are useless. No option to restore anything for the work performed during the working day. It would have been more honest if BACK would set the recovery model to simple instead. That would at least give us a more fair chance to catch the problem (sooner then we did).


    Now, we did find an option in BACK to not truncate the log (or whatever they called the checkbox), but by default it did perform this disastrous log backup to nul.


    The next step was to consider implementation of the differential backup plan. But time was running out for my assignment so we only managed a quick check. And from what we found out, it seemed that BACK doesn't have an option to produce its snapshot backup to be seen as a COPY_ONLY backup. This means that it prohibits us to implements SQL Server differential backup and saving some 500 GB backup storage produced each week (for only one of the servers). Now, let me leave a disclaimer here since I didn't have time to investigate this much as all, but this is what it looks like at the moment. I will dig deeper into the differential backup strategy next time I’m with this client.


    The moral of the story? You already know that. Test your restore strategy. You might just be (unpleasantly) surprised!

  • Using whoami to check for instant file initialization

    Read this if you want to read more about instant file initialization (IFI). In an earlier blog post, I posted a script that uses trace flags, created a dummy-database and then sp_readerrorlog to check for IFI.

    Another option is to use the OS command whoami, as documented here. Below script uses whoami to check for IFI, or more precisely SQL Server having the "Perform Volume Maintenance Tasks" policy. It uses xp_cmdshell, meaning you have to be sysadmin in order to use it.

    IF OBJECT_ID('tempdb..#res') IS NOT NULL DROP TABLE #res

    @was_xp_cmd_on tinyint
    ,@was_show_adv_on tinyint
    ,@is_ifi_enabled tinyint

    --Exit if we aren't sysadmin
    IF IS_SRVROLEMEMBER('sysadmin') <> 1
    ('You must be sysadmin to execute this script', 16, 1)

    --Save state for show advanced options
    SET @was_show_adv_on =
    SELECT CAST(value_in_use AS tinyint)
    FROM sys.configurations
    WHERE name = 'show advanced options'

    --Turn on show advanced options, if neccesary
    IF @was_show_adv_on = 0
    sp_configure 'show advanced options', 1

    --Save state for xp_cmdshell
    SET @was_xp_cmd_on =
    SELECT CAST(value_in_use AS tinyint)
    FROM sys.configurations
    WHERE name = 'xp_cmdshell'

    --Turn on xp_cmdshell, if neccesary
    IF @was_xp_cmd_on = 0
    sp_configure 'xp_cmdshell', 1

    #res (col VARCHAR(255))

    INSERT INTO #res(col)
    EXEC xp_cmdshell 'whoami /priv /nh'

    SET @is_ifi_enabled =
    SELECT CASE WHEN PATINDEX('%Enabled%', col) > 0 THEN 1 ELSE 0 END
    WHERE col LIKE '%SeManageVolumePrivilege%'

    IF @is_ifi_enabled = 1
    SELECT 'Instant file initialization is enabled'
    'Instant file initialization is NOT enabled'

    --Reset state for xp_cmdshell
    IF @was_xp_cmd_on = 0
    sp_configure 'xp_cmdshell', 0

    --Reset state for show advanced options
    IF @was_show_adv_on = 0
    sp_configure 'show advanced options', 0
  • How often do you rebuild your heaps?

    Never? You are not alone. None of the maintenance solutions I use includes functionality to rebuild a heap, and that includes Maintanance Plans and Ola Hallengren's maintenance solution.

    "So why would you want to rebuild a heap, when it isn't sorted in the first place?", you ask. The answer is to get rid of Forwarding Pointers, and these can really hurt performance by adding lots more logical and physical reads, and random I/O. See for instance this from Kalen Delaney, this from Hugo Kornelis and this from the SQLCAT team.

    SQL Server 2008 added the ALTER TABLE command, with the REBUILD clause. And this is what I'm using in my procedure rebuild_heaps which rebuilds all fragmented heaps on a SQL Server.

    You find the procedure here:

  • Setting max server memory

    If there is one server setting that is close to universal to configure, then it is probably the "max server memory" setting. The setting is documented here. There are plenty of articles out there on this subject. The purpose for this article is for me to have somewhere to point when I get the question: "What value should I set this to?". I usually refer to Jonathan Kehayias' blog post when I get this question: For starters you want a simple formula to begin with, and then some hints on what to monitor if you want to fine-tune the value. Jonathan's articles provide both. The simple formula for how much to reserve for the OS is:

    1 GB
    Plus 1 GB for every 4 GB in the machine, between 4 and 16 GB
    Plus 1 GB for every 8 GB in the machine, above 16 GB

    And here's a TSQL script if you don't want to do the math yourself. Note that you need to specify how much memory you have in the machine.


    --Based on Jonathan Kehayias' blog post:

    IF OBJECT_ID('tempdb..#mem') IS NOT NULL DROP TABLE #mem

    @memInMachine DECIMAL(9,2)
    @memOsBase DECIMAL(9,2)
    @memOs4_16GB DECIMAL(9,2)
    @memOsOver_16GB DECIMAL(9,2)
    @memOsTot DECIMAL(9,2)
    @memForSql DECIMAL(9,2)
    @CurrentMem DECIMAL(9,2)
    @sql VARCHAR(1000)

    CREATE TABLE #mem(mem DECIMAL(9,2))

    --Get current mem setting----------------------------------------------------------------------------------------------
    SET @CurrentMem = (SELECT CAST(value AS INT)/1024. FROM sys.configurations WHERE name = 'max server memory (MB)')

    --Get memory in machine------------------------------------------------------------------------------------------------
    SET @sql = 'SELECT physical_memory_in_bytes/(1024*1024*1024.) FROM sys.dm_os_sys_info'
    CAST(LEFT(CAST(SERVERPROPERTY('ResourceVersion') AS VARCHAR(20)), 2) AS INT) >= 11
    SET @sql = 'SELECT physical_memory_kb/(1024*1024.) FROM sys.dm_os_sys_info'
    @sql = 'SELECT physical_memory_in_bytes/(1024*1024*1024.) FROM sys.dm_os_sys_info'

    SET @sql = 'DECLARE @mem decimal(9,2) SET @mem = (' + @sql + ') INSERT INTO #mem(mem) VALUES(@mem)'
    PRINT @sql
    SET @memInMachine = (SELECT MAX(mem) FROM #mem)

    --Calculate recommended memory setting---------------------------------------------------------------------------------
    SET @memOsBase = 1

    SET @memOs4_16GB =
    WHEN @memInMachine <= 4 THEN 0
    WHEN @memInMachine > 4 AND @memInMachine <= 16 THEN (@memInMachine - 4) / 4
    WHEN @memInMachine >= 16 THEN 3

    @memOsOver_16GB =
    WHEN @memInMachine <= 16 THEN 0
    ELSE (@memInMachine - 16) / 8

    @memOsTot = @memOsBase + @memOs4_16GB + @memOsOver_16GB
    SET @memForSql = @memInMachine - @memOsTot

    --Output findings------------------------------------------------------------------------------------------------------
    @CurrentMem AS CurrentMemConfig
    , @memInMachine AS MemInMachine
    , @memOsTot AS MemForOS
    , @memForSql AS memForSql
    ,'EXEC sp_configure ''max server memory'', ' + CAST(CAST(@memForSql * 1024 AS INT) AS VARCHAR(10)) + ' RECONFIGURE' AS CommandToExecute
    ,'Assumes dedicated instance. Only use the value after you verify it is reasonable.' AS Comment



    Edit 1 2014-03-06: Got the memory in the machine from sys.dm_os_sys_info, suggested by Ola Hallengren.

    Edit 2 2014-03-20: Adjusted script to work on 2008R2 and lower, as suggested by Shanky. Also added current mem config to output. Changed output from PRINT to SELECT (to facilitate multi-server query window).

    Edit 3 2014-03-22: Adjusted script to support 2005, as suggested by Steve Meder. Also changed to only one resultset.

    Edit 4 2014-05-30: Fixed some bugs for 2005, reported by Lee Linares.


  • Do you clean up your Database Mail log tables?

    Database Mail has a couple of log tables in the msdb database. These can become large over time. I've seen MSDB databases over 1 GB in size, where normal size is less than 50 MB (heavy usage of old SSIS deployment model excluded).

    Unfortunately Maintenance Plans do not have built-in functionality for this, nor does Ola Hallengren's excellent maintenance solution ( ). All you have to do is to schedule an agent job to be executed, say, every week, having one T-SQL jobstep containing: 



    EXECUTE msdb.dbo.sysmail_delete_mailitems_sp @sent_before = @DeleteOlder

    EXECUTE msdb.dbo.sysmail_delete_log_sp @logged_before = @DeleteOlder

    Above removes mail history older than one month. Adjust to your liking, using the values in the DATEADD function.

    As always, remember to comment your job and to specify appropriate database for the T-SQL jobstep (for documentation purposes, msdb in this case). 

  • Do you want improved performance?

    Can you survive a few lost transactions if your server does a "hard shutdown"? If so, check out SQL Server 2014 and "Delayed Durability".

    A cornerstone in SQL Server's transaction handling has up until 2014 been "durability" for a committed transaction. Durability is by the way the "D" in the ACID acronym: Atomicity, Consistency, Isolation and Durability.

    Durability means that SQL Server has do perform a synchronous write to the LDF file for each transaction. This so that SQL Server can re-construct all committed transactions up until the point of a (potentially hard) shutdown. 

    In SQL Server 2014, MS has planned for a database setting called "Delayed Durability". Setting this means that SQL Server can bath writes to the ldf file, meaning a potentially significant improved performance for applications where you have many small transactions.

    I did a quick test, using a bench from an earlier blog post of mine ( to test what difference I would see for that workload. Roughly (for 50000 rows, on a PC with single spinning disk HD):

    All inserts in one transaction averaged about 0.3 seconds.

    One transaction per row with Delayed Durability set to OFF approx 12 seconds. 

    One transaction per row with delayed durability set to Forced approx 1.2 seconds. 

     As you can see, for this workload we got about a tenfold performance improvement by letting SQL Server batch the write operations to the ldf file. The question is how much improvement you get for your workload and if you can tolerate to lose some modifications in case of a hard shutdown? 

  • Check for Instant File Initialization

    Instant File initialization, IFI, is generally a good thing to have. Check out this earlier blog post of mine f you don't know what IFI is and why it is a good thing: blog. The purpose of this blog post is to provide a simple script you can use to check if you have IFI turned on.

    Note that the script below uses undocumented commands, and might take a while if you have a large errorlog file...


    -- *** WARNING: Undocumented commands used in this script !!! *** --

    --Exit if a database named DummyTestDB exists
    IF DB_ID('DummyTestDB') IS NOT NULL
    ('A database named DummyTestDB already exists, exiting script', 20, 1) WITH LOG

    --Temptable to hold output from sp_readerrorlog
    IF OBJECT_ID('tempdb..#SqlLogs') IS NOT NULL DROP TABLE #SqlLogs
    CREATE TABLE #SqlLogs(LogDate datetime2(0), ProcessInfo VARCHAR(20), TEXT VARCHAR(MAX))

    --Turn on trace flags 3004 and 3605

    --Create a dummy database to see the output in the SQL Server Errorlog

    --Turn off trace flags 3004 and 3605

    --Remove the DummyDB

    --Now go check the output in the SQL Server Error Log File
    --This can take a while if you have a large errorlog file
    INSERT INTO #SqlLogs(LogDate, ProcessInfo, TEXT)
    EXEC sp_readerrorlog 0, 1, 'Zeroing'

    SELECT * FROM #SqlLogs
    WHERE TEXT LIKE 'Zeroing completed%'
    AND TEXT LIKE '%DummyTestDB.mdf%'
    AND LogDate > DATEADD(HOUR, -1, LogDate)
    'We do NOT have instant file initialization.'
    PRINT 'Grant the SQL Server services account the ''Perform Volume Maintenance Tasks'' security policy.'
    'We have instant file initialization.'

  • Wait random number of minutes

    Why on earth would you want to do that? you ask. Say you have a job that is scheduled to start at the same time over a number of servers. This might be because you have an SQL Server Master/Target server environment (MSX/TSX) or you quite simply script a job and execute that script on several servers. You probably want to spread the load on your SAN and virtual machine host a bit. This is the exact reason I use this procedure. I frequently use MSX servers and I usually add a job step (executing this procedure) to wait a random number of minutes between 0 and 30.

    You find the procedure here.   

  • Resynchronizing a target server (MSX - TSX)

    I often use SQL Server Agent master / target servers (MSX/TSX). I find it so convenient to create the job once and then just add whatever targetservers (TSX) should have this job. Especially when you later modify the job. Again, just modify it once. The usage of MSX in general, and how I use it, can easily become a series of blog posts in itself. But that is not the point here.

    Sometimes a TSX goes out-of-sync with its master. I've never understood exactly under what circumstances, but it feels like it happened when you do things "too quickly". Like change a job, push it out, and before the push has finished, you change it again. Or something like that. A TSX going out-of-sync doesn't happen frequently. I've had it a handful of times. And every time, I have spent time searching etc. on how to fix it.

    A couple of days ago, a client of mine had this case, and he had himself tracked down a possible way to fix this. We decided to go ahead with this, and it worked just fine. So, the purpose here is to document the (very easy) fix, for whenever this happens again. And for all of you out there who might benefit, of course. The error you see is something like:

    [291] An unresolved problem exists with the download instructions (sysdownloadlist) for target server 'Y' at MSX 'X'

    X here is obviously the master and Y the target. And the solution was quite simply (in the msdb database):

    EXEC dbo.sp_resync_targetserver, N'Y'

    Are you using MSX/TSX? Have you had sync issues? How did you handle them?

  • Express Edition revisited, focus on SSMS

     (Note: I have re-written parts of this post in the light of the comments that SP1 of 2012 include Complete tools.)

     I have decided to revisit the topic of whats included in Express Edition, with focus on the tools. I have a couple of reasons for this:

    • In my 2011 post, I never tried to connect from Express SSMS to a non-Express database engine.
    • I want to check if there are any significant differences in SQL Server 2012 Express Edition, compared to SQL Server 2008R2 Express Edition.

    It isn't uncommon that people want to have SQL Server Management Studio (SSMS) on their machines; and instead of searching for the install files for the full product, they download the freely available Express Edition and install SSMS from there. This was the main reason for this update post, and the reason I focus on SSMS and the tools in this post.

    It turns out that both 2008R2 and 2012 RTM Express editions of SSMS includes a lot, but not quite everyting that the full version of SSMS has. And they don't have Profiler or Database Engine Tuning Advisor. 2012 SP1 Express download does indeed have the Complete tool package.

    Basic and Complete
    The full SSMS (etc.) is referred to as "Management Tools - Complete". This is only available with the Product you pay for and with 2012 SP1 Express. The only one available with the various free Express downloads (prior to 2012 SP1), is called "Management Tools - Basic". You can explicitly request to install Basic from an install media that includes Complete, but you have to explicitly request that in the setup program. You don't want to do that.

    One difference between 2008R2 and 2012 is when you install from a pay-media and select that you want to install Express. For 2008R2, you then only have SSMS Basic available. For 2012, you have Complete. In other words, if you use a 2012 pay-media and select Express to install SSMS, you have the option to have the full-blown SSMS - Complete (including other tools, like Profiler).

    The downloads
    For SQL Server 2008R2, you have "Express Edition" and "Express Edition with Advanced Services". The former is basically only the database engine, where the later has some Tools (SSMS Basic, primarily). See my earlier blog post for more details about 2008R2.

    For 2012, there are bunch of downloads available. Note that if you want Complete tools, you need to download SP1 of the installers. You find SP1 here (and RTM, which you don't want to use, here). SP1 includes Complete tools, and you will see that those downloads are significantly larger compared to RTM. It isn't obvious what each exe files stand for, but scroll down and you will find pretty good explanations. I tried several of these (SSMS only, Express with Tools, Express with Advanced Services). They all have in common that for RTM the tool included is Basic, where for SP1 we have Complete.

    So what is the difference between Basic and Complete?

    In the table below, my focus was on what isn't in Basic. In general, I don't bother to list functionality which is available in both Basic and Complete. So, if the functionality isn't in the table below, it is likely available in Basic. I might have missed something, of course! And my main focus was on SSMS and the database engine.


    Component/Functionality 2008R2 2012 RTM 2012 SP1
    Functionality in SSMS
    Node for Agent Y Y Y
    Graphical Execution Plans Y Y Y
    Projects and Solutions N Y Y
    Maint Plans, Wizard Y Y Y
    Maint Plans, New, designer N (1) N (2) Y
    Maint Plans, Modify N (1) N (2) Y
    Node for SSIS Catalog N/A Y Y
    Tools menu, Profiler N N Y
    Tools menu, Tuning Advisor N N Y
    Connect Object Explorer to:
    Analysis Services N N Y
    Reporting Services N N Y
    Integration Services N N Y
    Profiler N N Y
    Database Engine Tuning Advisor N N Y

    (1): The selections are there, but they were dead - nothing happened when you select them.
    (2): The selections are there, but I got an error message when selecting any of them.

More Posts Next page »

This Blog


Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement