SQL Server provides an effective method for adding users in SQL Server and for managing data and

information so that it can easily be stored and retrieved from the underlying files in order to provide the functionality it is designed for. Once the database is designed, configured and implemented, it is critical that you start adding users in SQL Server so that people needing access to the data or specific bits of data be granted access to what they need to be able to access. This is increasingly important as the need for more secure practices, guidelines and policies becomes a greater force in the workplace. Security has become more prevalent in the dayto-day operations of practically every organization in the world. So how can SQL Server and its built in security allow for a more secure organization and help to protect the data that we are trying to guard? Working with SQL Server and the security it has within it is a critical component of database administration. Adding users in SQL Server is an important task. When adding users in SQL Server, it provides three methods of authenticating users within the database that can be implemented in order to control how users are granted access to the database. These three methods are windows authentication, SQL Server authentication and mixedmode authentication. Windows authentication performs a check of the user credentials with a network validation to ensure that the user has access to the resource. SQL Server authentication requires a valid SQL Server login name and password combination to validate the user access against the database before granting access to the resources on the server. Mixed mode security will allow the user to connect to the database via a valid Windows account or through a valid SQL Server login. The type of security you implement depends on the type of security architecture you decide is best for your specific needs on the server and the network. In order to configure security in SQL Server, the administrator may have to use not only tools within SQL Server but must also work with network accounts in order to grant access and adding users in SQL Server correctly. In order to view the logins that are used and defined within SQL Server using Enterprise Manager, select the Security node within Enterprise Manager. The Logins node within Security will allow you to view the logins defined within that database. The illustration below shows the screen and the information that it will provide anyone who looks at it.

The first column is the name of the login as it is known by the database. The type column is next and depicts what type of login it happens to be within the database. The following column tells whether or not the login has access to the server. This is the Server Access column. The next two columns deal with default settings for the user within the server. These settings deal with the database that serves as the default database for that login and the default language that is associated with that account.

In order to edit a login in SQL Server double-click on the login or right click and select Properties. Doing so will bring up the following dialog:

The General tab deals with the type of authentication to use for the login as well as setting the default database and language for that login. If Windows authentication is chosen, a domain must be selected and then the security access should be either granted or denied to the login. If SQL Server authentication is chosen, the password should be entered. Click OK to save any changes. The dialog also contains a tab to allow the administrator to define the server roles for the login (Server Roles). The following illustration shows this tab:

The server roles can be selected and then click OK to save the changes. Each role has specific rights within the server and in order to understand what the login should be associated with, the roles should be understood by those assigning them. The final tab on the dialog is the Database Access tab. The following illustration shows this tab:

This tab will allow the administrator to select each database within the SQL Server and specify the database roles within that database. These roles can grant and/or deny various capabilities within the databases for that particular login. Some examples of these roles include a data writer role, which will allow the user to update and insert data into the database and a data reader roles that allows the user to query the database in order to view the data. Users can also be added to individual databases by expanding the database in question and then selecting the Users node. The following illustration shows this screen:

In order to access the properties for a particular user, double click that user or right click and select Properties from the popup menu. This will bring up the following dialog in order to manage the permissions assigned to that particular user account.

The Permissions button will bring up the dialog to allow the administrator to grant or allow access to specific objects within the database. The following dialog shows this portion of the process:

By selecting and deselecting specific options within this dialog, the administrator can assign and deny access to certain objects within the database. Different object types will have different operations that can be executed against them as can be seen in the illustration above. For example, tables and views can have Select, Insert, Update, Delete and others while stored procedures do not have these operations. The Columns button applies to views and tables and can be used to control what columns that user has access to within the database. This level of control can help to make a database extremely secure, but can cause issues for those who are not familiar with the security that has been architected for a particular database or a server. Once the changes have been made to the user, they can be saved by clicking the Apply button. Hopefully, you now have a better understanding of how to adding users in SQL Server and how to work with security within SQL Server, as well as setting up a secure database environment in order to protect your data and your information that can prove to be vital to the success of your business.

Moving Database
If you need moving the database to another location, the attach and detach functionality is indispensable. As many of you may or may not know, SQL Server is a database management system used to store data and objects needed to work with that data. It is one of many products on the market designed for this purpose. SQL Server works by allowing the user to specify a location on the physical drives accessible by the server and providing the engine needed to store, retrieve, organize and utilize the data and objects within the database. The database is stored in files on hard drives that are accessed in order to gain access to the contents of the database. The files associated with a database have a default location, but upon database creation, they can be configured to go to another location. This allows for data to be better configured and organized across hard drives that may have limited space available for data storage. What happens however, when a file needs to be incorporated into the database management system from an external source? This is where the concept of moving the database by attaching and detaching comes into play. When a database is used and managed by SQL Server, the data files on the hard drives associated with that database are locked to use by any other application. If you try to access that file, a message will alert you to the fact that the file is being used by another application and you cannot access it. This makes the possibility of moving a database from one location to another or copying the database for use by another agency out of the question. For example, if you were traveling to another location to work on an application and you had to work from a machine that did not have access to that database, you could take a copy of the database to use to work with. This is where the ability to attach and detach a database will come into play. You can detach a database in order to remove it from the control of SQL Server and enable the files to be accessed by external methods or applications. This is where the concept of detaching a database can be used. By detaching a database it can be copied and moved to another location without interference from the SQL Server managing that database. Detaching a database in Enterprise Manager can be accomplished by the following: 1. Right-click on the database in question. This will bring up menu options shown below:

After brining up the menu options, go to the Detach Database option under the All Tasks menu option as illustrated below:

Select the Detach Database option to begin detaching the database from the database management system. After selecting the Detach Database option the following screen will appear to confirm the detach operation:

This screen informs the user of the number of active connections to the database. This can be helpful so that users of the database can be informed that the database they are using is getting ready to become unavailable so that they can save the work that they are working on help you determine a better schedule for the when the detachment operation can occur. The screen also shows whether or not the database is being used in replication and whether the database is ready to be detached. If you would like to update the statistics for the database prior to detaching it, the option can be selected. To proceed with the detachment of the database click the OK button. To cancel the operation, click the Cancel button. The detaching of the database is confirmed with the following dialog box:

The database can also be detached from the database management system using Query Analyzer and the Transact-SQL language. To do so, open a session in Query Analyzer and enter the sp_detach_db command. The syntax for the command is as follows: sp_detach_db 'dbname' ,'skipchecks' ] The dbname is the database name that is used by SQL Server to access the database. The skipchecks parameter is optional and instructs the server to either update the statistics for the database or not. For example, if we wanted to detach the Northwind database that comes with SQL Server the following statement would accomplish that feat: sp_detach_db 'Northwind Once the database is detached you can start moving the database to another location or transport it to the location where it is needed and can be attached to the server in order to access the database once again in SQL Server. To access the database once again via the database management system, it must be reattached to the database. In order to perform the attachment of a database via Enterprise Manager, right click on the databases tab in Enterprise Manager, select the All Tasks option and then the Attach Database option from the menu. The following illustration shows the options needed to perform the operation:

By selecting the Attach Database command the following dialog box is shown to continue the operation.

The first parameter that must be input is the mdf file for the database that needs to be attached. The command button shown to the left will bring up the file browser to allow the standard file selection methods to be employed. After the file is selected, it can be verified using the Verify command button. A name is given to attach the database as and also to specify the owner of the database. The OK command button will finalize the attach operation and shows the following dialog box to alert the user that the operation was successful.

Clicking the cancel button can be used to cancel the operation from continuing. The database can also be attached by opening up a Query Analyzer session and using Transact-SQL to perform the operation. The syntax of the attach command is as follows: sp_attach_db 'dbname' ,'filename_n' The dbname is the database name that is used by SQL Server to access the database. The filename_n indicates that there can be more than one file associated with the database.

There can be filename1 through filename16 files associated with the database. Once it is attached the database can be accessed by SQL Server again. For example, in order to attach the Northwind database we detached in the previous example, the following statement can be used: sp_attach_db 'Northwind' ,'c:\\\\\\\\\\\\\\\\somelocation\\\\\\\\\\\\\\\\northwind.mdf', c:\\\\\\\\\\\\\\\\location\\\\\\\\\\\\\\\\northwind.log Many people may be asking themselves why they may need this ability, but for those of us who have had to send a database somewhere else for it to be used, it is a blessing that it exists. I hope that moving the database from one location to another seems like a doable task after reading this.

Import and export in SQL Server

SQL Server: The Advantage of the Import and Export in SQL Server Tools While SQL Server can be used to house the data that your company maintains on a daily basis and offers a way to effectively and efficiently manage the objects and data within that database, there are often times when getting initial data into a database can be a hassle. However, not only does SQL Server manage the data and objects contained within the database, it has tools that can be used to get data into tables quickly from a variety of external sources. SQL Server provides to those who use it, the ability to import and export in SQL Server to many different formats. This can be extremely useful for someone wanting to quickly get data into the database or out of the database for any reason. For example, an agency that sells mailing lists could easily export the data from a SQL Server database to a format that could be burned onto a CD and delivered to the customer very quickly. On the other hand, the same company could buy a mailing list file from another agency or third party and import the data into their database and save the time of having to key the data into the database or an application. So how can the import and export in SQL Server data tools that are provided by SQL Server be used to get data into a database quickly?

In order to use the import and export in SQL Server Data functions, right click on the server in Enterprise Manager that you would like to use as a basis for the Import or Export. Then select the Import Data or Export Data menu option from the All Tasks selection as shown in the image below:

The interface for Import Data and Export Data is the same, each presents the user with different options for the destination and source for the data involved in the operation. Regardless of what operation you wish to conduct when transferring the data, an import or an export, each option will provide you with the functionality you need. For clarification, regardless of whether you want to import or export data, the options are provided that will allow an import or an export to occur once the operation is initiated. Once the selection is made, the following window appears:

Select the Next button to continue with the Import/Export Wizard. This will bring up the following screen:

This screen will allow the user to select the data source, which is a drop down list of all the types of data that can be used with the import/export. These include many different formats, not just SQL Server data. The source type can be SQL Server, Access, Oracle or any other data store that can be accessed via ODBC as well. After the data source type is selected, the user is then presented with the specifications needed to specify the location of the source data. Each option comes with different parameters needed to locate, connect and open the data source. Once the data source is configured, click next which will allow the selection of the destination for the data. In most instances you will be required to input information that will allow the database to verify who you are and securely control access to that particular repository of data. Each type of data has differing parameters and must be experimented with in order to learn the full functionality of the import/export capabilities of SQL Server and the tools it offers. The following graphic illustrates this screen:

This screen is used the same way as the previous one used to input the source of the information for the import and export in SQL Server. It functions the exact same way the source screen works except that it represents the connection used to access the destination database. If the user wants to go back to the source screen, click the back button. Clicking next will bring up the next screen.

This will allow the user to select the type of objects that they want to move.

The user can select to move tables, use a query to specify the data or move data and objects between databases. Selecting the copy tables option will allow the user to select tables to move in their entirety to the destination. The use of the query option will allow the user to enter a query to specify the data that needs be moved. This can be used to limit the fields or the amount of data being moved. The transfer objects option will allow the selection of objects to be moved between SQL Server databases. All of these options are very important when trying to determine how to import and export data in SQL Server. After the choice is made, the user can click next to move on to the next screen, which is shown below.

To continue with the import and export in SQL Server operation, this screen will allow the selection of the source and destination objects and the data transformations that need to occur in order to move the data to the correct location. These transformations can be a straight copy or they can be the result of data manipulation via scripts in order to make the data fit the format you need or transform the data into other elements. Once this is complete, click the Next button, which will bring up the following screen. After this information is input, our import/export operation is almost ready to run on the server to complete the movement of the data.

This will allow the user to run the import/export now or save the configured import/export as a DTS package to be run later or saved on the server to be run as needed. You may be asking yourself why this utility to import and export in SQL Server is so advantageous, imagine if you had to use data entry tasks in order to manually enter a list of thousands of records of data. How much time could be saved if the data could be loaded via a file in the import/export data utility? Experience has proven to me that this tool can prove to be invaluable if the developer or database administrator becomes familiar with the power that it provides. It has saved me numerous hours on projects and has been used exclusively for data transformation tasks that would not have been possible without a tool such as this. Moving data using the import and export in SQL Server can prove very useful along with the rest of the DTS features in SQL Server.

SQL Server indexes - Boosting performance in the database

SQL Server indexes: A couple of years ago your IT department made the investment to purchase SQL Server in order to manage and maintain your data and information. This was an investment in our future and the future of our organization. We had evaluated the database options available to us, and decided to go with SQL Server. After a while, we were wondering why the database that promised such robust performance for our dollar was not working properly and was taking way too long to return the records that we needed from it. Every operation you do involving the databases that you have seem to take longer and longer with each passing day. You know all of the data is there and you need to access it, however, with the delays you experience you become frustrated and give up. Why not evaluate the normalization of your database design, gather statistics on your databases and have a look at what indexes are present on your databases and what SQL Server indexes may need to be added in order to get the performance that you require and deserve? SQL Server indexes are used for many reasons.Some of those reasons are listed below:

To ensure data integrity To ensure data accuracy To speed up data storage and retrieval To help the database engine manage the data that it is responsible for

Indexes are a good practice to use when working with databases because they can definitely have an impact on the performance of some operations that take place in the database. For example, I have seen a query take over twenty-five minutes until proper indexes were added to the table based on usage and needs. After the indexes were added the same query took under 10 seconds to run and return the data from the database.

While indexes are a good thing to utilize in a database architecture and design, they can be overdone just like any good thing. Each index added will require some additional resources to be used by the server when an operation involving the table or tables in question takes place. Therefore, the more indexes you add to a table, the more checks and balances the database engine has to maintain before the operation can be completed and the results returned to the user. How many indexes are enough? That is up to the designer and relies on the situation at hand. If a table already has a couple of indexes associated with it and another needs to be added, the index may or may not make performance any better. Adding more indexes to a table can increase performance and reduce the time it takes to perform an operation, however, they should be used with discretion. SQL Server allows the user to view statistics and the performance plan associated with statements that are going to be executed against the database. These aids can help diagnose problems that may be helped with the addition of new indexes or the subtraction of existing ones. After the decision has been made to work with the SQL Server indexes used with a particular table in a database, Enterprise Manager can be used to manage the indexes of that table. In order to work with the indexes assigned to a table, expand the database that contains the table you want to work with, expand the tables in that database and right click on the table in question. Select the All Tasks menu option, which will bring up the submenu options desired. The following illustration shows the menu options described above.

After these menu options become available, select the Manage Indexes menu option in order to work with the indexes associated with that table. The index management is accomplished using the following interface:

The first option shows the database that you are currently working with and can be changed from within the interface to switch to another database. The next option shown is the selection of the table that you want to manage the indexes for. The lower half of the screen shows the existing SQL Server indexes that the table selected has. There are also command buttons on the bottom portion of the screen that allow you add an index, edit an existing index or delete an existing index. In order to add a new index, click the New button and the following dialog will be presented to the user.

The first step that is needed when creating a new SQL Server index is to assign the index a unique name within the database so that it can be distinguished from other indexes. The next portion of the index creation screen is a table that allows the selection of the fields that make up the index. There can be more than one field used to make up an index. For example, if you were to have fields called firstname, middlename and lastname, they could be indexed as one field to allow the searching for the full name to perform better on the server. The order of the columns in the index can be sorted based on how the index needs to be arranged within the database with the Up and Down command buttons on the screen. After the fields that make up an index are selected, the options associated with that index must be selected in order to help describe the way that index will function within the database management system. Some of these options can be set whether or not the index will contain unique values, whether the index will ignore duplicate values or whether or not the statistics will be recomputed based on the index.

Unique values dictate whether or not the index can contain duplicate values. Ignoring duplicate values will instruct the database engine to allow duplicate values in the SQL Server indexes selected. A very important option is the computation of statistics. Statistics allow the database to compile information about the SQL Server indexes and data in the database to speed up performance when the database is used. Once the index is complete, click the OK button to save the changes.

SQL Server jobs

SQL Server jobs: In the day-to-day operations of running a business, employees can get caught up in more than one project, as is often the case. We may be IT professionals but there is a limit to the amount of work that we can handle in one day and still stay on track. With the amount of multitasking that employers feel their employees should be able to handle increasing with each passing day, the need to find a way to help themselves get the job done becomes increasingly more important. Finding help and ways to get solutions into production even faster can make the day less stressful thereby making it more productive in the long run. In the daily routine of a database administrator or a database developer, SQL Server has some functionality that can make life simpler and more dependable in the long run: SQL Server jobs. How can the ability to create a job to handle routine tasks make the life of a database administrator or developer and how are SQL Server jobs created? A SQL Server job is a collection of steps executed by the database engine by SQL Server Agent. The job can perform many different functions within it that can save time and effort on the part of employees. For example, a job can be created to import a daily update file internally or externally via an FTP server. Another job can be configured to handle routine maintenance tasks as well as handling onetime production updates that may be needed in the future.

A job has many different options that can be configured during its creation in order to perform the duties that is needed of it. In order to manage the jobs within a SQL Server database, use Enterprise Manager, and expand the Management node in Enterprise Manager. Under the Management node is a node entitled SQL Server Agent. Expand this node and you will see the Jobs item that is used to represent the jobs within the system. To see the jobs currently in the system, select Jobs. See the following illustration for an example of the steps described above:

The window on the left will show the jobs currently in the system. This window displays a lot of information about the SQL Server jobs currently in the system that can prove valuable. The first column lists the name of the job that was entered when it was created. The second column lists the category of the job that was assigned at the time of the job's creation. This helps to clarify the jobs and organize the jobs in the system. The next column tells whether or not the job is enabled in the system. If you wish to disable or enable a job in SQL Server, right click on the job and select on the Disable Job or Enable Job option from the popup menu. The next column tells whether or not the job is runnable in the system. After that there is a column, which tells whether or not the job is scheduled to run in the system. The status column alerts the user to what is currently going on with the job. If the job is running it alerts the user to what step it is in currently.

The last run status column tells the status of the jobs last run and when that occurrence took place. The final column shown tells when the next scheduled run is to take place. To see the properties of a job in the window, right click on the job and select Properties from the popup menu or double click on the job. Either of these actions will bring up the following screen in order to set and/or view options contained in that job.

The first tab (General) of this dialog shows the name of the job, when the job was created, whether or not the job is enabled, the category the job falls into, who owns the job within the database and a description of the job. To disable a SQL Server job, uncheck the Enabled checkbox and the job will no longer run in the database if it was scheduled to do so. The Steps tab of this dialog brings up the following screen:

Each step within the job will be identified within this screen. These steps can include executing data transformation packages, executing queries, executing stored procedures, etc. Within this interface you can move the order of the steps around so that they occur in a specific order, as well as, add new steps or edit existing steps. If you select a step and select the Edit button, the following screen appears:

This screen is used to set the command that is to be executed during the current step. You can also specify the name of the step, the type of command to execute and the exit code of the process if successful. The tab also has a Schedule tab that can be used to manage the schedule of the SQL Server jobs. This will allow the job to be set to occur once a daily, multiple times per day, weekly, monthly or just a one time. The job can be set to run at a certain times per day on a recurring basis as well, such as every hour or at a certain time per day. The following screen shows the scheduling tab:

To work with the schedule, click the New Schedule or the Edit button. The New Schedule button will allow a new schedule to be input for the job. The Edit button will allow the edit of the current schedule. There is also a Notifications tab that can be used to handle notifications from the SQL Server in the event that something unusual occurs with the job while it is running. The following screen shows the notification dialog which allows the selection of notifications options:

Notifications can be sent in multiple methods. For the notification to work, there must be operators set up within SQL Server to receive them. The notification can be an email, a page or a net send. Each notification can be used to alert the operator that something has occurred on the server and the actions are controlled by SQL Server Agent. Once the SQL Server job is configured, the changes can be saved and the job can now be used to perform routine tasks on a regular basis which can free up resources within your organization.

Creating a SQL Server Maintenance Plan

SQL Server Maintenance Plan: SQL Server is a very capable database in terms of storage capacity and performance. It can be used successfully to manage large stores of data and provide a database management system for anyone who needs it and can work with it properly. In order to properly manage the database and keep the database performing at an optimal level, routine tasks must be taken care of on the database. These routine tasks include SQL Server maintenance jobs that will not only keep the data and the engine performing at satisfactory levels, but will also keep the data backed up in order to aid in the occurrence of a disaster.

The only way to be ready for a disaster is to plan ahead and ensure that the SQL Server maintenance plan a nd disaster recovery measures you have in place will work. A good SQL Server maintenance plan can do wonders if planned correctly, implemented successfully and managed appropriately and properly. SQL Server provides a maintenance plan that help to implement appropriate measures to ensure that your database is safe and properly maintained. So what is a database maintenance plan and how can you configure a good SQL Server maintenance plan? A maintenance plan is a set of measures taken to ensure that a database is properly maintained and that routine backups are scheduled and handled. Within SQL Server, a database maintenance plan can include tasks such as backups of the database, backups of the transaction log, recomputing statistics on the database, managing indexes and taking care of internal data storage issues. A nice feature of SQL Server is that the maintenance plan can be configured by a wizard, which can help alleviate some of the burden of creating the plan. It can also ensure that the common features of the maintenance plan are taken care of. The Database Maintenance Plan Wizard relies on a graphical user interface to give the user the ability to visually create and implement one or more jobs within SQL Server that will run under SQL Server Agent. These jobs can automatically check the database integrity, get rid of unused space within the database, which will increase performance, reorganize your indexes, create the backups of the database and transaction logs. For most administrators and instances, the wizard will suffice in creating the backup plan unless you want to create a custom maintenance plan yourself. In order to use the wizard to create the maintenance plan in Enterprise Manager, select the Tools menu option and navigate to the Database Maintenance Planner option. This will bring up the following screen:

Click the Next button to continue with the wizard. This will bring up the following screen:

This screen allows you to specify the database(s) that will be involved with the maintenance plan that you are creating. The available options are

All databases All system databases (master, model, and msdb) All user databases (all other than master, model, and msdb)

These databases which allows a selection from a list of one or more databases to include Depending on which databases you would like to include in the SQL Server maintenance plan, make the selection from this screen and continue with the wizard. Clicking the Next button will allow you to continue with the creation of the database maintenance plan. The Next button will open the following screen:

The first option in this dialog will instruct the plan to reorganize the data and index pages in the database. If this option is selected, the statistics are recreated automatically when this step runs. Updating the statistics will increase the performance and reliability of the database(s) in question. If you select the option to reorganize then you cannot select the update statistics box because the statistics will automatically get recreated. You can however, just select the update statistics box without the reorganization. You can also specify that you would like to remove unused space from the database files. During the course of normal operations, database files will become filled with unused space, which will lead to decreased performance. After these options are selected, click the Next button to continue with the wizard and the following screen is shown:

This screen allows you to check the integrity of the database. The integrity check can be configured to include indexes and attempt to repair any problems that it finds. The checks can also be setup to be performed before doing a backup. This option can have negative side effects either way. The integrity check may take up precious time on the server, but it can fix problems. On the other hand, the check may not be able to fix all the problems that it encounters. The check can also be scheduled by clicking the Change button to set up the schedule. Selecting the Next button will bring up the following screen:

This screen allows the creation and schedule of the backup and to specify the location of the backup file, as well as, to verify the integrity of the backup when the operation is complete. If you select the disk option on this screen you will be taken to the screen to configure the file location and select options to remove older backup files that may be in that location already. This screen is shown in the following illustration:

Clicking Next will allow you to specify information relating to the transaction log backup as shown in the following image:

This screen functions the same way as the screen for configuring the database backup. It allows the selection of the file location, the verification of the integrity and the scheduling of the backup. After clicking Next, if disk was selected as the location of the backup file, the user will be presented with the following screen:

This screen allows the selection of the directory location for the backup file, as well as the ability to instruct SQL Server to create a subdirectory for each database being backed up while the operation is running. You can also specify the removal of old backup files and assign an extension to the backup files. Clicking on the Next button will bring up the following screen:

This allows you to specify whether or not to generate a report for the SQL Server maintenance plan and store that in a specific location. You may also delete report files older than a specified timeframe. Operator email notifications can also be configured on this page as well. Selecting Next will bring up the following screen for input:

This screen deals with options relating to whether or not the SQL Server maintenance plan history will be stored in a SQL Server database somewhere for easy retrieval and historical purposes. Selecting Next will finalize the maintenance plan and bring up the confirmation screen as seen in the following illustration:

This will allow the naming of the SQL Server maintenance plan and clicking finish will generate the necessary jobs that are needed to perform the database plan. The objects generated by these steps can be seen by looking at the SQL Server maintenance plan for the database or looking at the individual jobs created and scheduled on the server.

SQL Server Backup

SQL Server Backup: When using SQL Server to maintain and manage a database, the integrity, accuracy and availability of that data if often critical to the success of a business. If data becomes unavailable or the database becomes inaccessible to the users of a system, a business can be in a lot of trouble.

SQL Server has the ability to make backups of databases so that the data can be restored in case something tragic happens to the database. A SQL Server backup will play a critical part to any disaster recovery plan in case an emergency does occur. They are crucial to the success of any information technology department. How do you perform a SQL Server backup in order to ensure that the database will be available in the event that something does happen sometime down the road and your database must be restored from a backup device? In order to backup a SQL Server database using Enterprise Manager, right click on the database that you want to back up. The following illustration shows the menu options needed to navigate to the necessary option.

After the appropriate menu is available, from the All Tasks menu item select the Backup Database submenu item. This will initiate the SQL Server Backup Database operation so that the parameters needed to perform the backup can be entered into the database. This will bring up the following screen to begin the entry of the information needed to perform the backup of the database:

The first option in the screen is to specify the database that is to be backed up and the name of the backup as well as a description of the backup. A name and description are necessary in order to help identify saved SQL Server backup plans in the database. After this information is entered into the window, the backup type must be selected in order to specify what type of backup is to be performed. There are four backup operations that can occur within the database. This can be a complete database backup, a differential database backup, a transaction log or file/filegroup backup.

A complete database backup will back the entire database structure up to the device specified. It is a complete copy of the database selected and will include everything in the database including the data and the objects. A differential backup is another option. It deals with only backing up the database and its changes since the last full database backup was performed. A transaction log backup will backup the current transaction log so it can be restored at a later date. The transaction log is a log of the transactions that have taken place in the database. A file or filegroup backup deals with making a SQL Server backup of a specific part of the files or filegroups involved with the make up of the database. Once the desired backup type is entered, a destination for the database backup must be input into the equation. This will inform the database where the backup is to be saved. The backup can be saved to a disk or to a tape backup device. To enter a backup device to save the backup to, click the Add button to open a dialog that will allow for the selection of the backup location and the device to hold the backup. After finalizing the selection of the backup destination, the choice must be made whether to append to the existing media or overwrite the existing media with the result of the backup. Once all of these options have been entered, the database backup can be scheduled in order to make this a process that occurs on a regular basis. Scheduling a backup procedure in SQL Server puts the workload on the server to execute the backup on routine basis and does not force a database administrator to perform the backups. The only job that someone has concerning the SQL Server backups are to either routinely check them for success or configure the server to send alerts to users when specific actions occur on the server. To schedule the backup of the database, select the checkbox and then click the command button to bring up the scheduling dialog window. The following screen shows this operation:

The options on this screen deal with the timing of the SQL Server backup and the conditions that need to be met before the server is to run the database backup. The schedule can be given a name to help distinguish it within the database. It can also be enabled or disabled using the Enabled checkbox option. There are four different scheduling options that can be used within the system to determine when to run a job within SQL Server. These four options are to start when agent starts, start when the CPU is idle, a one time or to create a recurring job. The first option will start the job whenever SQL Server Agent starts. SQL Server Agent is a service that runs specific tasks within the database management system. The second option is to start the job when the CPU becomes idle. The third option is to create a job that occurs once at a specific date and time. The final option is to create a SQL Server backup job that occurs on a routine basis that can be scheduled to occur as often and whenever it is necessary. The following screen shows the job scheduling options available to handling recurring jobs:

Once the job schedule is created, clicking OK will accept the changes and create a job within the database. This job is responsible for the backup and is run by SQL Server Agent whenever the scheduled time occurs. When the scheduled time occurs on the server, SQL Server Agent takes over and runs the job and the steps associated with it. While running the job, the status of the SQL Server backup is updated to alert the user of the database what is occurring with the job. Each step and operation is logged in the database and updated in the job history tables stored in the database.

SQL Server Restore Database

SQL Server Backup: SQL Server Restore Database: The database jobs are working efficiently and your data is now being backed up on a routine basis so that in case something happens you have a way to restore your database.

Then one day it finally happens, your server crashes and your mission-critical database is now corrupt and cannot be accessed by SQL Server's engine. Now comes the time to put the database backups to use that you have created in order to get your database working again. A database can be restored in SQL Server using either Enterprise Manager or with Query Analyzer. Most people are more comfortable using Enterprise Manager and its windows-like graphical user interface to accomplish the database restoration. However, some people prefer to use Query Analyzer and the Transact-SQL language to accomplish the SQL Server database restore. The graphical user interface of Enterprise Manager makes the job of restoring a database easier for those who do not know Transact-SQL and do not want to take the time to learn it. To restore a database from backup using Query Analyzer, open a session of Query Analyzer and enter the restore command. The syntax for the most basic command to restore a database is as follows: RESTORE DATABASE databasename FROM backupdevice The databasename parameter is the name of the database that is to be restored. The backupdevice parameter is the name of the backup device to use for the source of the backup. For example, the following command will restore the Northwind database from the backup device Nwind1. RESTORE DATABASE Northwind FROM Nwind1 This gives a brief description of how to perform a SQL Server restore database from database backup using Query Analyzer and the Transact-SQL commands to perform the operation. While some people prefer this method, most people prefer to use Enterprise Manager in order to handle a restoration of a database backup. To restore a database from a backup set using Enterprise Manager, right click on the database that you want to restore and select the All Tasks menu item in order to get to the Restore Database option item. The following illustration shows the menu options needed in order to execute the SQL Server Restore Database option:

This option initiates the request to perform the database restoration process. In essence, this wizard is creating the same Transact-SQL statements that can be used Query Analyzer to perform the restore operation on the database in question. The restore database wizard screens will submit this statement to the SQL Server engine to perform the operation. After selecting the restore database menu option, the following screen appears:

The first parameter that should be entered is the name of the database that is to be restored. If the database exists already, the database will be overwritten by what is contained in the backup set. The next option that needs to be entered is the selection of the backup type that is to be restored. The type of restore option used is determined by the type of backup set that you are performing the restoration from. The possible options are database, filegroups or files or from device. The user can also use the dropdowns on the screen to show the backups that have taken place for the database in question. This can be helpful if the user is unsure of which backup to do the restore operation from. There is also a dropdown that allows the user to select which backup set to restore first. In some cases restoring a database can require more than one backup set to get the database

completely restored to the state that is needed for proper operation while minimizing the loss of data. The key factor that needs to be considered when a backup strategy is being devised and implemented is the amount of data and time that can be afforded to be lost in the case of a disaster. For this reason, many companies decide to create different types of backups throughout the day and week in order to ensure that the least amount of data and effort is wasted if a disaster occurs. In the SQL Server restore database wizard there is also an Options tab that helps to further define the restoration operation that needs to be performed. The Options tab is shown in the following image:

This window will allow the user to further specify options that are to be used during the processing of the SQL Server restore database operation. The user can specify whether or not to eject each tape during each step of the restoration process if tapes are being used for the restore operation. There is also an option to prompt for confirmation before restoring each backup that is being used. The option may also be checked to overwrite an existing database with media used in the process of restoring the database. After these options are specified, there are choices that can be selected by the user to specify how to leave the database after the recovery operation has been completed. The first option is to leave the database operational. This selection restores the database and makes it operational for use, however, it also places a restriction on the database so that no additional transaction logs can be restored. The second option is to leave the database nonoperational after the SQL Server restore database operation but allow the user to restore more transaction logs which can help recover even more data and make the database even more current with what was lost. The final option is to leave the database in read-only mode and allow the restoration of additional transaction logs. Once the options are selected, click OK and the restoration of the database will proceed with the options that have specified and will alert the user when the operation is complete or fails.

SQL Server Profiler - Analyzing the database

What is Microsoft SQL Server and what is SQL Server Profiler? What does it have to offer? Microsoft SQL Server is a powerful database management system, as many of us know. Those of us who have worked with SQL Server know that this product, as many other products of this type, make our lives as information technology professionals so much easier than it would be without it. Without the power it offers us, how would we manage to do the work that it performs in the background in as much time? However, in order to tap into the power of SQL Server, the interaction with the database must be done correctly and the objects residing in the database must be correct as well. Any component used by an application on the server must be correct and accessed correctly. What happens when the tools we are using to access the database and

something in the database are not exactly working as we expected? How do we go about determining where the problem is? SQL Server Profiler is one tool that can be used to provide a wealth of information that can be used in order to diagnose a problem or error in our application. What is Profiler? Profiler is a utility that runs on the server that monitors and logs specified activities on the server in order to produce a listing of all the activity occurring on the server. SQL Server Profiler is configured by the user to capture the events that they want to monitor. This allows the user to create a customizable view each time that they have an issue they want to watch. This is done by the use of a trace running on the server that is configured to capture the data deemed necessary by the developer or administrator in order to determine where the problem may be. To run Profiler from Enterprise Manager, select the SQL Server Profiler option from the Tools menu as shown in the image below:

Once the SQL Server Profiler option is selected, the following screen will open for the user to interact with the utility and configure the trace that may be needed at the time. This screen has many options available that can be used to configure the trace running on the server. This article will focus on setting up a trace in order to diagnose a problem on the server or to monitor an event that might be returning questionable results.

In order to configure a new trace select File | New | Trace from the menu options available on the screen. See the following image for an illustration of the menu options needed to open a new trace.

Once this option is selected, the interface will open a screen that will allow the user to connect to the server in question. Once successfully connected to the server, it is time to configure the trace that will run on the server. The configuration screen is shown in the following graphic:

The configuration screen consists of four tabs, the General tab is illustrated above. This tab is used to give the trace a name and select the SQL Server that the trace will run against. If a trace template exists that has already been configured, it can be selected in the Use the following trace template section. The option exists to save the trace results to file or to a table. Either of these options will instruct the server where to save the results of the trace so they can be retrieved later. Each option allows the user to regulate the amount of rows that Profiler will capture during the trace. If the user would like the trace to stop automatically, a date and time can be selected for the server to stop the trace automatically. This can be advantageous if you have many windows open and do not want a lot of activity logged from a very busy server by not letting the trace run for a long time. The next tab is the Events tab. This tab is shown below:

This tab allows the addition or removal of events that occur on the server that are to be traced by the server. There are numerous events available that can be used depending on the information needing to be traced by the user. Each of these events will be logged by SQL Server Profiler as a different type of event so that the results can be searched easily by the type of event that occurred. The next tab is the Data Columns tab. This tab is shown in the following graphic:

This tab is used to instruct the server which data to capture in SQL Server Profiler. Some common elements are ApplicationName, which is the name of the application that called the event, the TextData, which is the instruction as seen by the server, the DatabaseName, which is the name of the database being accessed by the statement and Duration, which is the length of time needed to process the statement. This field can be particularly useful in diagnosing a long running statement in a stored procedure. The final tab is the Filters tab. This tab is shown in the following graphic:

This tab will allow the user to configure any filters that they would like to apply to the trace in SQL Server Profiler. This can restrict the amount of data going into the trace. For example, if a particular database is needed, set the DatabaseName field to the desired database name. Once all of the options are configured, click the Run button in order to run the trace. The trace screen is shown in the following image:

To stop the trace, select the red square button on the toolbar. If the results were saved to a table, the table can be accessed just like any other table in SQL Server. By analyzing the results of the trace, the user can see what activity is taking on the server and in what order when they are making calls to the database, which can be a powerful when trying to debug a problem that may be occurring or returning unexpected results.

The Purpose of the SQL Server Transaction Log

SQL Server Transaction Log: While working with SQL Server, there can be huge amounts of data in the database that is stored in the underlying files. SQL Server stores its data in files that are maintained by the database engine. These files rely on the underlying hardware and networking architecture in order to function correctly. Without the power it offers us, how would we manage to do the work that it performs in the background in as much time?

However, in order to tap into the power of SQL Server, the interaction with the database must be done correctly and the objects residing in the database must be correct as well. If something goes wrong with the database engine or the hardware it relies on there can be issues with the data and the information stored in the database. This is where we rely on backups and the SQL Server transaction log to help recover from any problems that may have occurred while the database was in operation. So what is the SQL Server transaction log and how can it be used to the advantage of the developers and administrators who interact with it? What is the transaction log in SQL Server? When SQL Server is functioning and operating, the database engine keeps track of almost every change that takes place within the database by making entries into the transaction log so that it can be used later if needed. The location of the SQL Server transaction log is configured at the same time the database is created. When creating a database, the location of the SQL Server transaction log is specified as well as other options associated with the transaction log. The following screen shows the SQL Server transaction log options that can be set during the creation of the database.

The options allow you to specify the location of the SQL Server transaction log files that are used by the database that you are creating. These transaction log files are stored just like the data files used in SQL Server. These files can also be configured just like the data files in SQL Server. The screen above shows the options available. For example, along with the file location you can specify a minimum size to start the SQL Server transaction log file out with. This size is just the minimum starting point because as the database is used the transaction log will grow. The growth must be planned for and the options must be configured to handle the growth accordingly or error messages can occur relating to the transaction log being full.

The rate at which the transaction log files grow can be specified by a size in megabytes or by a percentage. This setting tells SQL Server that when the transaction log reaches a specified point, automatically grow the file by the amount of growth specified in order to accommodate future transactions. The other option that can be set is the maximum size of the transaction log files. They can be set to have unrestricted file growth or they can be set to only occupy a specific amount of space in megabytes. One thing to keep in mind is that the transaction logs can be used in a backup situation so possibly putting them on a disk other than that occupied by the primary data files may be a good idea for future use. To elaborate on the idea of using the SQL Server transaction log as part of the backup and storing it on a separate drive, the transaction log can be backed up and used to recover transactions since your last backup. The last entries you have made will be stored in the transaction log and can be reenacted on the database to give a better database restoration by minimizing the amount of work lost since the last backup. So what exactly occurs during the logging of a transaction? When a transaction is logged in the database it can occur in different manners based on the statement that is being logged. In essence, however, all transactions log a copy of the old data and the new data in the transaction log. Some transactions will log of copy of the entire row and other transactions will log the bytes that have changed during the transaction. On many occasions it is not necessary to know exactly what is occurring in the transaction log as long as it is utilizing correctly when programming with it. How can the SQL Server transaction log be used when developing stored procedures, database objects or interactions with the database in order to ensure that proper recovery methods can be implemented during the development of these objects or segments of code? When using Transact-SQL to interact with the database engine to process the statements needed, effective use of certain statements within the code will allow for transactions and recovery options to be implemented in case something occurs in the code we create. These statements are the Begin Tran, Rollback Tran, Commit Tran and the Save Tran. The Begin Tran statement will instruct the database engine to being a transaction block within the database so that the work can be handled explicitly in the code. For example, if you wanted to insert a group of records into a specified table only if a certain condition was true, you could begin the transaction, insert the records and check the condition to see if it was met.

If the condition was met you could then issue the Commit Tran command to commit the block of transactions since the last Save Tran or Begin Tran was encountered. If the condition was not met you could, on the other hand, issue the Rollback Tran in order to stop the transaction and rollback all changes to the database since the last Save Tran or Begin Tran was issued. The Save Tran command is issued to save a point in the transaction handling that will allow a save point to be specified. For example, you could create a save point during a large operation every so often so that the rollback or commit trans is not having to handle as many records when it is performed. One thing to keep in mind with this is that it causes an impact on performance during execution of these statements as they are database operations just like statements you execute. We have examined the transaction log and how it may prove valuable to us when working with SQL Server and have found some good uses for the transaction log and the ways to interact with it.