The Real MTCS SQL Server 2008 Exam 70/432 Prep Kit- P76 potx

ETLTechniques•Chapter8 357 Creating packages programmatically is way beyond the scope of this book, so we won’t be talking about that option at all. Just know that it is possible if you need it. We will look at the two wizards, however, and take a brief look at using BIDS to work with packages. Let’s start by looking at the Copy Database Wizard. Using the Copy Database Wizard The Copy Database Wizard gives SQL administrators an easy way to copy an entire database between two SQL Server instances. The obvious goal of the Copy Database Wizard is to make a copy of an entire database. Normally, this is going to be between two instances of SQL Server; however, you can use it to copy a database within a single instance. You can think of a database two different ways; physically or logically. Physically, a database is a collection of.mdf, .ndf, and .ldf files on disk. Logically, a database is made up of a bunch of objects (like tables, indices, views, procedures), data (the rows in the tables), and metadata (object definitions, permissions, and so on). Given those two possible views of a database, you then have two different models for copying a database. You could copy the.mdf, .ndf, and .ldf files that make up the physical database. Alternatively, you could create new, empty files on the destination server, and logically copy the database by running statements to create copies of every object in the target database, copying the data into those objects, and then copying all the metadata. The Copy Database Wizard supports both models. It performs physical copies through the “detach-and-attach” method. It performs logical copies via the “SQL Management Object” method. The “detach-and-attach” method is the most efficient method of copying an entire database. This method physically copies the entire database by detaching the database from the source instance; copying the .mdf, .ndf, and .ldf files to the desti- nation; and then attaching them to the destination SQL Server instance. It does have some constraints, though. First, the source database must be taken offline while the physical data files are being copied. Second, the SQL Server agent on the target server must have permissions to the file system on the source server via some share. If you can meet those requirements, you’ll probably find the “detach-and-attach” method to be the method of choice. The “SQL Management Objects” (SMO) method of transferring the database is slower, but it doesn’t require that the SQL Server Agent job run as an account with access to the file system on the source server. This method may help you accom- plish a copy between servers when you don’t have as much control over the source server’s Windows permissions. The SMO method is slower because it uses the SMO object model to programmatically re-create each source object in the destination database. It then copies the data over to the new objects as well as all the metadata. 358 Chapter8•ETLTechniques Configuring&Implementing… WorkingwithoutActiveDirectory If you are trying to practice for these exams on your own machines, you would benefit from configuring a test network complete with an Active Directory domain. You can certainly work without it, and for home, dev, and test purposes that is acceptable. However, many of the features in SQL Server, like the Copy Database Wizard, assume you are working in a multiserver environment. In a production environment that almost certainly means that there will be some centralized security mechanism. In Windows networks, that means Active Directory. To truly grasp the implementation of SQL Server as it would be used in a production environment, you need Active Directory. Working with multiple systems and without Active Directory can be a problem because computers won’t recognize each other’s user accounts. This can be a problem when you are trying to use tools that need to talk to both systems, like the Copy Database Wizard. You can attempt to create user accounts on all systems that have the same names and passwords, but as much as that seems as if it should work, it still doesn’t in some cases. If you are having problems using the Copy Database Wizard because of authentication problems, you can test it by just copying a database to the same instance. This won’t show you all the possible options in the wizard, but it will give you the overall sense of the process. The wizard is smart enough to recognize that the source and destination instances are the same, and it doesn’t prompt you to synchronize instance level objects like logins, SQL Server Agent Jobs, and so on. It also automatically names the database with a “_new” at the end, as well as renames the target data- base file names so that they won’t overwrite the original database files. Regardless of which method you choose to use, some things that exist outside of a given database, will still be required for the database to be functional on the target server. These include: Logins  User-defined error messages  ETLTechniques•Chapter8 359 Stored procedures created by in-house developers, but stored in master  (not very common) SQL Server Agent job definitions  SQL Server Integration Services Packages  Endpoints for things like the Service Broker, HTTP access, and so on  When you are copying a database between two instances, the Copy Database Wizard will prompt you for the aforementioned classes of objects you may want to copy and then allow you to specify exactly which of the objects you wish to have copied. That is a basic overview of what the Copy Database Wizard can help you do. Rather than showing you screen shots, we will do an exercise to get a feel for the Copy Database Wizard. To make sure that everybody can do it, we will test copying a database to the same instance. If you have multiple instances available to you, you can try it yourself by copying between two instances. EXERCISE 8.6 Us i n g t H E Co P y da t a B a s E Wi z a r d In this exercise, you will use create a database named CopyMe and load it with some data. You will then use the Copy Database Wizard to copy the database to the same SQL Server instance. Finally, you will verify that the copy worked by looking at the data in the copied database as well as viewing the SSIS package and SQL Server Agent job that the wizard creates. This exercise assumes that you have administrative privileges on the SQL Server you are working with. 1. In SQL Server Management Studio, open a new query window that is connected to your instance of SQL Server. 2. Run the following statement to create the database we will copy: CREATE DATABASE CopyMe; 3. Run the following statement to populate the database with some data. This way, you can make sure the copy worked by ensuring the same data is in the copied database: SELECT * INTO CopyMe.dbo.Product FROM AdventureWorks2008.Production.Product; 360 Chapter8•ETLTechniques 4. Connect to the SQL Server instance in the SSMS Object Explorer. 5. Expand the Databases node and right click on the CopyMe database. 6. From the pop-up menu select Tasks | Copy Database… 7. On the Copy Database Wizard first page click “Next.” 8. On the Select a Source Server page, in the Source Server field enter the name of your SQL Server Instance and select Windows Authentication. Click Next. 9. On the Select a Destination Server page, in the Destination Server field, leave the value at (local), and again select Windows Authentication. Click Next. 10. On the Select the Transfer Method page, select Use the detach and attach method. Leave the If a failure occurs, reattach the source database checkbox checked. Note: you can ignore the warning about the SQL Server Agent needing a proxy account. Because the source and destination servers are the same, the permissions should be valid. Click Next. 11. On the Select Databases page make sure the Copy checkbox is enabled for the CopyMe database. All other checkboxes should be cleared. (Note that in the Status column for the CopyMe database that it sees the database already exists. That’s all right; you’ll copy it to a new name). Click Next. 12. On the Configure Destination Database (1 of 1) page, review and leave everything at their default values. Notice that the wizard has automatically named the copy CopyMe_new to make sure the copy doesn’t overwrite the original database. Review the paths of the data files as well. Select Stop the transfer if a database or file with the same name exists at the destination. Click Next. 13. On the Configure the Package page, leave the package name unchanged, but remember it so that you can look it up later. Turn on the Save transfer logs? checkbox. Select Text file from the drop down menu, and leave the log path at the default (record the path so that you can look at the log after the copy). Click Next. 14. On the Schedule the Package page, leave the option set to Run immediately. Even though you are running it immediately, it will still create a SQL Server Agent Job to run the copy for you. Leave the Integration Services Proxy Account set to SQL Server Agent Service Account. Click Next. ETLTechniques•Chapter8 361 15. On the Complete the Wizard page, review the list of actions and then click Finish. 16. On the Performing operation page, watch as the package is created and run. If all is well, each item in the list should complete with Success. 17. Back in the SSMS Object explorer, right click the Databases node and choose Refresh. You should now see a CopyMe_new data- base in the list. 18. Expand the CopyMe_new database and then expand Tables. You should see the dbo.Product table in the list of tables. Right-click the dbo.Product table and select Select Top 1000 Rows. Review the data in the query window that opens. Close the query window when you are done. 19. In Object Explorer under your SQL Server instance, Expand SQL Server Agent and then expand Jobs. You should see a job listed with the same name as the package (you were supposed to have remembered that name back in step 13). This is the SQL Server Agent Job that got created to run the package. Open the job and review its details, but don’t change anything. 20. In the Object Explorer, from the Connect menu, select Integration Services…. Enter the name of your SQL Server Instance for the Server name: and click Connect. 21. Expand Stored Packages | MSDB | <YOUR INSTANCE NAME> | DTS Packages | Copy Database Wizard Packages. You should see a package there with the name you recorded in step 13. This is the actual package. It has been saved into the MSDB database on your local instance. Later, you’ll open the package up in BIDS to see what is inside it. Using the Import and Export Wizard While the Copy Database Wizard copies an entire database, the Import and Export Wizard provides you with a more granular copy mechanism. The Copy Database Wizard was also limited to using only SQL Server as both the source and destination. The Import and Export Wizard, however, can connect to most any database engine as either the source or the destination. The Import and Export Wizard allows you to export data from the source database by either selecting the specific tables and views you want to export, or by . “Next.” 8. On the Select a Source Server page, in the Source Server field enter the name of your SQL Server Instance and select Windows Authentication. Click Next. 9. On the Select a Destination Server. First, the source database must be taken offline while the physical data files are being copied. Second, the SQL Server agent on the target server must have permissions to the file system on the. data. You will then use the Copy Database Wizard to copy the database to the same SQL Server instance. Finally, you will verify that the copy worked by looking at the data in the copied database