Category Archives: SQL Server

Database Mirroring Operating Modes

Leave a reply

Database Mirroring Operating Modes

Database Mirroring is configured for three different operating modes. These modes are high availability, high performance and high protection. Each offers a different set of functionality and must be understood in order to select the appropriate configurations.

  • High Availability Operating Mode
    • The High Availability Operating Mode provides durable, synchronous transfer of data between the principal and mirror instances including automatic failure detection and failover. With this functionality comes a performance hit. This is because a transaction is not considered committed until SQL Server has successfully committed it to the transaction log on both the principal and the mirror database. As the distance between the principal and the mirror increases, the performance impact also increases.
    • In addition, there is an continuous ping process between all three nodes (if a witness is used) to detect failover. If witness server is not visible from the mirror, you must either reconfigure the operating mode for the database mirroring session or turn off the witness. Alternatively, you can manually fail over a database mirroring session at the mirror in High Availability Mode by issuing the ALTER DATABASE SET PARTNER FAILOVER command at the principal. The same command can also be issued if you have to take principal down for maintenance.
  • High Performance Operating Mode
    • With the High Performance Operating Mode the overall architecture acts as a warm standby and does not support automatic failure detection or failover. The data transfer between the principal and mirror instances is asynchronous. As such, this mode provides better performance and permits geographic separate between the principal and mirror SQL Server instances. Unfortunately, this mode increases latency and can lead to greater data loss in the event of primary database failure if it is not managed properly.
  • High Protection Operating Mode
    • The High Protection Operating Mode operates very similar to the High Availability Mode except the failover and promotion (mirror to principal) process is manual. With this mode the data transfer is synchronous. This mode is typically not recommended except in the event of replacing the existing witness SQL Server. After replacing or recovering the witness SQL Server, the operating mode should be changed back to High Availability Operating Mode

SQL Server 2005 Editions

Leave a reply

SQL Server 2005 Editions

<!–[if !supportLists]–>ü <!–[endif]–>SQL Server Express

<!–[if !supportLists]–>ü <!–[endif]–>SQL Server Workgroup

<!–[if !supportLists]–>ü <!–[endif]–>SQL Server Developer

<!–[if !supportLists]–>ü <!–[endif]–>SQL Server Standard

<!–[if !supportLists]–>ü <!–[endif]–>SQL Server Enterprise

<!–[if !supportLists]–>ü <!–[endif]–>SQL Server Compact

System Databases in SQL Server 2005

4 Replies


SQL Server System Databases

  • Master
    • Purpose – Core system database to manage the SQL Server instance. In SQL Server 2005, the Master database is the logical repository for the system objects residing in the sys schema. In SQL Server 2000 and previous editions of SQL Server, the Master database physically stored all of the system objects.
    • Prominent Functionality
      • Per instance configurations
      • Databases residing on the instance
      • Files for each database
      • Logins
      • Linked\Remote servers
      • Endpoints
    • Additional Information
      • The first database in the SQL Server startup process
      • In SQL Server 2005, needs to reside in the same directory as the Resource database
  • Resource
    • Purpose – The Resource database is responsible for physically storing all of the SQL Server 2005 system objects. This database has been created to improve the upgrade and rollback of SQL Server system objects with the ability to overwrite only this database.
    • Prominent Functionality
      • System object definition
    • Additional Information
      • Introduced in SQL Server 2005 to help manage the upgrade and rollback of system objects
      • Prior to SQL Server 2005 the system related data was stored in the master database
      • Read-only database that is not accessible via the SQL Server 2005 tool set
      • The database ID for the Resource database is 32767
      • The Resource database does not have an entry in master.sys.databases
  • TempDB
    • Purpose – Temporary database to store temporary tables (#temptable or ##temptale), table variables, cursors, work tables, row versioning, create or rebuild indexes sorted in TempDB, etc. Each time the SQL Server instance is restarted all objects in this database are destroyed, so permanent objects cannot be created in this database.
    • Prominent Functionality
      • Manage temporary objects listed in the purpose above
    • Additional Information
      • Each time a SQL Server instance is rebooted, the TempDB database is reset to its original state
  • Model
    • Purpose – Template database for all user defined databases
    • Prominent Functionality
      • Objects
      • Columns
      • Users
    • Additional Information
      • User defined tables, stored procedures, user defined data types, etc can be created in the Model database and will exist in all future user defined databases
      • The database configurations such as the recovery model for the Model database are applied to future user defined databases
  • MSDB
    • Purpose – Primary database to manage the SQL Server Agent configurations
    • Prominent Functionality
      • SQL Server Agent Jobs, Operators and Alerts
      • DTS Package storage in SQL Server 7.0 and 2000
      • SSIS Package storage in SQL Server 2005
    • Additional Information
      • Provides some of the configurations for the SQL Server Agent service
      • For the SQL Server 2005 Express edition installations, even though the SQL Server Agent service does not exist, the instance still has the MSDB database
  • Distribution
    • Purpose – Primary data to support SQL Server replication
    • Prominent Functionality
      • Database responsible for the replication meta data
      • Supports the data for transaction replication between the publisher and subscriber(s)
  • ReportServer
    • Purpose – Primary database for Reporting Services to store the meta data and object definitions
    • Prominent Functionality
      • Reports security
      • Job schedules and running jobs
      • Report notifications
      • Report execution history
  • ReportServerTempDB
    • Purpose – Temporary storage for Reporting Services
    • Prominent Functionality
      • Session information
      • Cache

    • How to read transaction log data in SQL Server 2000/2005?

    3 Replies

     

    We can’t read the transaction logs directly from SQL Server. Some products do allow you to read the logs, such as:

    * Apex SQL Log (Works with MSSQL2000 and MSSQL2005)
    * Log Explorer
    * SQL Log Rescue (Only work with the SQL Server 2000)

    The below undocumented DBCC command is working in both SQL Server 2000 & SQL Server 2005

    DBCC LOG(<database name>[,{0|1|2|3|4}])
    0 – Basic Log Information (default)
    1 – Lengthy Info
    2 – Very Length Info
    3 – Detailed
    4 – Full Example
    Syntax:
    DBCC log (MY_DB, 4)

    Another undocumented command is DBCC LOGINFO

    Disk Space Alerts using SQL Server 2005

    Leave a reply

    Please visit http://sqldbpool.blogspot.com/

    Step 1: Create the database mail profile account using SQL Server Management Studio. Give the profile name to “FreeSpaceAlertMails”

    Step2: Create the below procedure in master database which will check the disk space.

    CREATE PROCEDURE sendAlertMails
    AS
    BEGIN
    SET NOCOUNT ON
    DECLARE @availableSpace AS FLOAT
    DECLARE @alertMessage AS Varchar(4000)

    CREATE TABLE #tbldiskSpace
    (
    driveName VARCHAR(3),
    freeSpace FLOAT
    )

    INSERT INTO #tbldiskSpace EXEC master..XP_FixedDrives
    SELECT @availableSpace = ROUND((freeSpace)/1024,1) FROM #tbldiskSpace WHERE driveName = ‘E’

    SET @alertMessage = ‘(host:jshah.sqldbpool.com)E:\ Disk Space Critical. Free Space Available on E:\ Drive is ‘ + CAST(@availableSpace AS VARCHAR) + ‘GB’

    IF @availableSpace < 10
    BEGIN
    EXEC msdb.dbo.sp_send_dbmail
    @profile_name = ‘FreeSpaceAlertMails’,
    @recipients = ‘jshah143@gmail.com’,
    @body = @alertMessage,
    @importance = ‘High’,
    @subject = ‘host:jshah.sqldbpool.com Disk Critical E Drive’ ;
    END

    DROP TABLE #tbldiskSpace

    END

    Step 3: Create the job which will execute the above procedure at every 2 hours interval.