Chapter 1.

Database File Structures

SQL Architecture Basics Joes 2 Pros

Beginning Architecture Concepts for Microsoft SQL Server 2008
(SQL Exam Prep Series 70-433 Volume 3 of 5)
By Rick A. Morelan
MCDBA, MCTS, MCITP, MCAD, MOE, MCSE, MCSE+I

RickA.Morelan AllRightsReserved2010
ISBN: 1451579462 EAN-13: 978-145-157-9468 Rick A. Morelan [email protected]

1
www.Joes2Pros.com

Chapter 1. Database File Structures

Table of Contents
About the Author ................................................................................................ 9 Acknowledgements ............................................................................................. 9 Introduction ....................................................................................................... 10 Skills Needed for this Book .............................................................................. 10 About this Book ................................................................................................ 11 How to Use the Downloadable Companion Files ............................................. 12 What This Book is Not ..................................................................................... 13

Chapter 1. Database File Structures ............................................ 14

Database File Structures ................................................................................... 15 DataFiles and LogFiles ................................................................................. 18 Impact of the Database Backup Process ....................................................... 23 Creating Databases............................................................................................ 25 Lab 1.1: Database File Structures ..................................................................... 27 Database File Structures - Points to Ponder...................................................... 28 DataFile Planning and Implementation ............................................................ 29 Using Filegroups ............................................................................................... 32 Primary and Secondary Filegroups ............................................................... 32 Lab 1.2: Using Filegroups................................................................................. 39 Using Filegroups - Points to Ponder ................................................................. 42 Altering Database Filegroups ........................................................................... 44 Lab 1.3: Altering Database Filegroups ............................................................. 51 Altering Database Filegroups - Points to Ponder .............................................. 52 Chapter Glossary ............................................................................................... 53 Chapter One - Review Quiz .............................................................................. 54 Answer Key .................................................................................................. 55 Bug Catcher Game ............................................................................................ 55

Chapter 2. Database Schemas, Snapshots & Properties ............ 56

Schemas ............................................................................................................ 57 Creating Schemas With Code ....................................................................... 60 Creating Schemas with Management Studio ................................................ 62 Qualified Names Using Schemas.................................................................. 64 Lab 2.1 Schemas ............................................................................................... 65 Schemas - Points to Ponder............................................................................... 66 Database Snapshots ........................................................................................... 68 Snapshot Basics ............................................................................................ 68 Creating Database Snapshots ........................................................................ 68 Querying Source and Snapshot Database Data ............................................. 70

2
www.Joes2Pros.com

Chapter 1. Database File Structures Lab 2.2 Database Snapshots ............................................................................. 73 Database Snapshots - Points to Ponder ............................................................. 74 Setting Database Properties .............................................................................. 75 Altering Databases Using Management Studio ............................................ 77 Altering Databases Using T-SQL Code ........................................................ 78 Database Code Generators ................................................................................ 80 Lab 2.3: Setting Database Properties ................................................................ 85 Setting Database Properties - Points to Ponder................................................. 86 Chapter Glossary ............................................................................................... 87 Chapter Two - Review Quiz ............................................................................. 88 Answer Key .................................................................................................. 88 Bug Catcher Game ............................................................................................ 89

Chapter 3. Data Type Usage.......................................................... 90

Data Row Space Usage ..................................................................................... 91 Units of Measurement ................................................................................... 91 Row Header .................................................................................................. 91 Common Data Types .................................................................................... 92 Unicode Data ................................................................................................ 93 Fixed Data ..................................................................................................... 93 Variable Block .............................................................................................. 93 Variable Data ................................................................................................ 93 Lab 3.1 Data Row Space Usage ........................................................................ 99 Data Row Space Usage - Points to Ponder ..................................................... 100 Null Data ......................................................................................................... 101 Null Block ................................................................................................... 101 Null Block Storage Allocation .................................................................... 102 Lab 3.2: Null Data........................................................................................... 106 Null Data - Points to Ponder ........................................................................... 107 Large Values ................................................................................................... 108 Memory Page .............................................................................................. 108 Large Object Types ..................................................................................... 110 Large-Value Data Types ............................................................................. 115 Lab 3.3: Large Values ..................................................................................... 120 Large Values - Points to Ponder ..................................................................... 123 Chapter Glossary ............................................................................................. 124 Chapter Three - Review Quiz ......................................................................... 125 Answer Key ................................................................................................ 126 Bug Catcher Game .......................................................................................... 126

Chapter 4. Special Data Type Options ....................................... 127

Sparse Data ..................................................................................................... 128 Analyzing Space Used ................................................................................ 130

3
www.Joes2Pros.com

Chapter 1. Database File Structures Using the Sparse Data Option ..................................................................... 133 Lab 4.1: Sparse Data Option ........................................................................... 137 Sparse Data Option - Points to Ponder ........................................................... 139 Custom Data Types ......................................................................................... 140 Creating Custom Types............................................................................... 143 Using Custom Types ................................................................................... 145 Dropping Custom Types ............................................................................. 147 Lab 4.2: Custom Data Types .......................................................................... 149 Custom Data Types - Points to Ponder ........................................................... 150 System and Time Data Types ......................................................................... 151 Recap of DateTime Functions .................................................................... 151 Standard Date and Time Data Types .......................................................... 153 Date and Time Zone Types ......................................................................... 156 Lab 4.3: System and Time Data Types ........................................................... 161 System and Time Data Types - Points to Ponder ........................................... 162 Chapter Glossary ............................................................................................. 163 Chapter Four - Review Quiz ........................................................................... 164 Answer Key ................................................................................................ 166 Bug Catcher Game .......................................................................................... 166

Chapter 5. Spatial Data Types .................................................... 167

Geography Data Type ..................................................................................... 168 Storing Latitude and Longitude .................................................................. 169 Creating Geography as a Field in a Table ................................................... 171 Populating a Geography Data Type ............................................................ 171 Geography Functions .................................................................................. 173 Geography Polygon .................................................................................... 175 Lab 5.1: Geography Data Type ....................................................................... 183 Geography Data Type - Points to Ponder ....................................................... 186 Geometry Data Type ....................................................................................... 187 Polygons...................................................................................................... 188 Creating Geometry as a Field in a Table .................................................... 189 Populating a Geometry Data Type .............................................................. 190 Geometry Functions .................................................................................... 192 Lab 5.2: Geometry Data Type ........................................................................ 198 Geometry Data Type - Points to Ponder ......................................................... 200 Chapter Glossary ............................................................................................. 201 Chapter Five - Review Quiz ........................................................................... 202 Answer Key ................................................................................................ 203 Bug Catcher Game .......................................................................................... 203

Chapter 6. Partitioned Tables ..................................................... 204

Giant Tables .................................................................................................... 205

4
www.Joes2Pros.com

Chapter 1. Database File Structures Creating Separate Tables ................................................................................ 206 Overview of Partitioned Tables ...................................................................... 207 Partitioning .................................................................................................. 209 Partition Functions ...................................................................................... 210 Partition Schemes........................................................................................ 211 Data Storage Areas ..................................................................................... 212 Creating Partitioned Tables............................................................................. 213 Creating Filegroups ..................................................................................... 213 Creating Datafiles for the Filegroups .......................................................... 216 Creating Partitioned Functions ................................................................... 218 Creating Partitioned Schemes ..................................................................... 219 Viewing Partitioned Table Information ...................................................... 221 Lab 6.1: Creating Partitioned Tables .............................................................. 224 Creating Partitioned Tables - Points to Ponder ............................................... 227 Chapter Glossary ............................................................................................. 227 Chapter Six - Review Quiz ............................................................................. 228 Answer Key ................................................................................................ 229 Bug Catcher Game .......................................................................................... 229

Chapter 7. Altering Partitioned Tables ...................................... 230

Preparing for New Data .................................................................................. 231 Splitting New Partitions .............................................................................. 231 Retiring (Switching Out) Partitions ............................................................ 239 Lab 7.1: Altering Partitioned Tables ............................................................... 243 Altering Partitioned Tables - Points to Ponder ............................................... 245 Removing Partitioned Tables.......................................................................... 246 Dependencies .............................................................................................. 246 Steps to Remove Partitions From Objects .................................................. 246 Lab 7.2: Removing Partitioned Tables ........................................................... 251 Removing Partitioned Tables - Points to Ponder ............................................ 252 Chapter Glossary ............................................................................................. 252 Chapter Seven - Review Quiz ......................................................................... 253 Answer Key ................................................................................................ 253 Bug Catcher Game .......................................................................................... 253

Chapter 8. Creating Indexes ....................................................... 254

The Clustered Index ........................................................................................ 255 Data Storage Terms..................................................................................... 255 Records ....................................................................................................... 256 Memory Pages ............................................................................................ 256 Clustered Index Data in Memory ................................................................ 258 Page Splits....................................................................................................... 260 Fill Factor .................................................................................................... 263

5
www.Joes2Pros.com

Chapter 1. Database File Structures Identity Fields ............................................................................................. 265 Lab 8.1: Clustered Indexes ............................................................................. 267 Clustered Indexes - Points to Ponder .............................................................. 268 Nonclustered Indexes ...................................................................................... 270 Index Scan ................................................................................................... 270 Index Seek ................................................................................................... 270 Clustered Indexes Recap ................................................................................. 271 Creating Nonclustered Indexes ....................................................................... 276 Unique Nonclustered Indexes ..................................................................... 277 Lab 8.2: Nonclustered Indexes ....................................................................... 281 Nonclustered Indexes - Points to Ponder ........................................................ 282 Chapter Glossary ............................................................................................. 283 Chapter Eight - Review Quiz .......................................................................... 284 Answer Key ................................................................................................ 284 Bug Catcher Game .......................................................................................... 285

Chapter 9. Creating Indexes with Code ..................................... 286

Coding Indexes ............................................................................................... 287 Nonunique Option....................................................................................... 288 Unique Option ............................................................................................. 289 Lab 9.1: Coding Indexes ................................................................................. 291 Coding Indexes - Points to Ponder.................................................................. 292 Index Options .................................................................................................. 293 Composite Indexes ...................................................................................... 293 Coding Unique Composite Indexes ............................................................ 296 Indexes With Included Columns ................................................................. 297 ONLINE Option with Indexes .................................................................... 301 Covered Query vs. Covering Index ............................................................ 302 Filtered Indexes........................................................................................... 303 Lab 9.2: Index Options ................................................................................... 306 Index Options - Points to Ponder .................................................................... 309 Chapter Glossary ............................................................................................. 310 Chapter Nine - Review Quiz ........................................................................... 311 Answer Key ................................................................................................ 315 Bug Catcher Game .......................................................................................... 316

Chapter 10.

Index Analysis ........................................................ 317

Query Execution Plans .................................................................................... 318 Covering Indexes ........................................................................................ 318 How Nonclustered Indexes Work ............................................................... 321 When a Query Needs a Covering Index ......................................................... 322 Selectivity ................................................................................................... 323 Selective Predicate Operations ................................................................... 325

6
www.Joes2Pros.com

Chapter 1. Database File Structures Optimization Hints .......................................................................................... 327 Index Hints .................................................................................................. 327 Query Hints ................................................................................................. 328 Lab 10.1: Query Execution Plans ................................................................... 335 Query Execution Plans - Points to Ponder ...................................................... 337 Analyzing Indexes .......................................................................................... 338 Seek vs. Scan Recap ................................................................................... 338 Historical Index Metadata ........................................................................... 339 Lab 10.2: Analyzing Indexes .......................................................................... 342 Analyzing Indexes - Points to Ponder............................................................. 343 Database Tuning ............................................................................................. 344 Workload Files ............................................................................................ 345 Database Engine Tuning Advisor DTA ...................................................... 346 Analyzing Session Definitions .................................................................... 355 Analyzing and Saving Session Results ....................................................... 357 Lab 10.3: Data Tuning Advisor ...................................................................... 360 Database Tuning - Points to Ponder................................................................ 363 Chapter Glossary ............................................................................................. 364 Chapter Ten - Review Quiz ............................................................................ 365 Answer Key ................................................................................................ 367 Bug Catcher Game .......................................................................................... 368

Chapter 11.

Index Maintenance................................................. 369

Fragmentation Basics ...................................................................................... 370 Detecting Fragmentation ................................................................................. 371 Detecting Fragmentation with Management Studio ................................... 372 Detecting Fragmentation with Dynamic Management Views .................... 373 Lab 11.1: Detecting Fragmentation ................................................................ 375 Detecting Fragmentation - Points to Ponder ................................................... 376 Fragmentation Reports .................................................................................... 377 Fragmentation Recap .................................................................................. 377 Combining Fragmentation Metadata .......................................................... 377 Index Defragmentation ................................................................................... 380 Rebuilding Indexes ..................................................................................... 380 Reorganizing Indexes.................................................................................. 381 Lab 11.2: Index Defragmentation ................................................................... 383 Index Defragmentation - Points to Ponder...................................................... 384 Index Metadata................................................................................................ 385 Actual Execution Plans ............................................................................... 385 Missing Indexes .......................................................................................... 387 Object Property Metadata ........................................................................... 390 Index Functions ............................................................................................... 391

7
www.Joes2Pros.com

Chapter 1. Database File Structures Lab 11.3: Index Metadata ............................................................................... 395 Index Metadata - Points to Ponder .................................................................. 397 Chapter Glossary ............................................................................................. 398 Chapter Eleven - Review Quiz ....................................................................... 399 Answer Key ................................................................................................ 400 Bug Catcher Game .......................................................................................... 401

Chapter 12.

Special Index Types ............................................... 402

SQL Statistics.................................................................................................. 403 Statistics Metadata ...................................................................................... 405 Histogram.................................................................................................... 406 Creating Statistics ....................................................................................... 406 Updating Statistics ...................................................................................... 408 Lab 12.1: Index Statistics ................................................................................ 409 Index Statistics - Points to Ponder .................................................................. 410 Partitioned Table Indexing .............................................................................. 412 Creating Partitioned Tables Recap.............................................................. 412 Partitioned Tables as Heaps ........................................................................ 416 Creating Indexes on Partitioned Tables ...................................................... 417 Query Partitioned Tables ............................................................................ 418 Lab 12.2: Partitioned Table Indexing ............................................................. 419 Partition Table Indexing - Points to Ponder .................................................... 420 Chapter Glossary ............................................................................................. 420 Chapter Twelve - Review Quiz....................................................................... 421 Answer Key ................................................................................................ 422 Bug Catcher Game .......................................................................................... 422

Chapter 13.

Full Text Indexing .................................................. 423

Full Text Indexing........................................................................................... 424 Full Text Catalogs ....................................................................................... 425 Full Text Indexes ........................................................................................ 426 Lab 13.1: Full Text Indexing .......................................................................... 429 Full Text Indexing - Points to Ponder ............................................................. 429 Stop Words...................................................................................................... 430 Dropping Stop Words ................................................................................. 434 Adding Stop Words..................................................................................... 436 Lab 13.2: Stop Words ..................................................................................... 438 Stop Words - Points to Ponder ........................................................................ 439 Chapter Glossary ............................................................................................. 439 Chapter Thirteen - Review Quiz ..................................................................... 440 Answer Key ................................................................................................ 441 Bug Catcher Game .......................................................................................... 441 Index ............................................................................................................... 442

8
www.Joes2Pros.com

Chapter 1. Database File Structures

About the Author

In 1994, you could find Rick Morelan braving the frigid waters of the Bering Sea as an Alaska commercial fisherman. His computer skills were non-existent at the time, so you might figure such beginnings seemed unlikely to lead him down the path to SQL Server expertise at Microsoft. However, every computer expert in the world today woke up at some point in their life knowing nothing about computers. They say luck is what happens when preparation meets opportunity. In the case of Rick Morelan, people were a big part of his good luck. Making the change from fisherman seemed scary and took daily schooling at Catapult Software Training Institute. Rick got his lucky break in August 1995, working his first database job at Microsoft. Since that time, Rick has worked more than 10 years at Microsoft and has attained over 30 Microsoft technical certifications in applications, networking, databases and .NET development.

Acknowledgements
As a book with a supporting web site, illustrations, media content and software scripts, it takes more than the usual author, illustrator and editor to put everything together into a great learning experience. Since my publisher has the more traditional contributor list available, Id like to recognize the core team members: Editor: Jessica Brown, Joel Heidal Cover Illustration: Jungim Jang Technical Review: Tom Ekberg, Joel Heidal Software Design Testing: Irina Berger Index: Denise Driscoll User Acceptance Testing: Michael McLean Website & Digital Marketing:Gaurav Singhal Thank you to all the teachers at Catapult Software Training Institute in the mid1990s. What a great start to open my eyes. It landed me my first job at Microsoft by August of that year. A giant second wind came from Koenig-Solutions, which gives twice the training and attention for half the price of most other schools. Mr. Rohit Aggarwal is the visionary founder of this company based in New Delhi, India. Rohits business model sits students down one-on-one with experts. Each expert dedicates weeks to help each new IT student succeed. The numerous twelve-hour flights I took to India to attend those classes were pivotal to my success. Whenever a new

9
www.Joes2Pros.com

Chapter 1. Database File Structures generation of software was released, I got years ahead of the learning curve by spending one or two months at Koenig. Dr. James D. McCaffrey at Volt Technical Resources in Bellevue, Wash., taught me how to improve my own learning by teaching others. Youll frequently see me in his classroom because he makes learning fun. McCaffreys unique style boosts the self-confidence of his students, and his tutelage has been essential to my own professional development. His philosophy inspires the Joes 2 Pros curriculum.

Introduction
Sure I wrote great queries and was always able to deliver precisely the data that everyone wanted. But a wake up call occasion on December 26, 2006 forced me to get better acquainted with the internals of SQL Server. That challenge was a turning point for me and my knowledge of SQL Server performance and architecture. Almost everyone from the workplace was out of town or taking time off for the holidays, and I was in the office for what I expected would be a very quiet day. I received a call that a query which had been working fine for years was suddenly crippling the system. The request was not for me to write one of my brilliant queries but to troubleshoot the existing query and get it back to running well. Until that moment, I hadnt spent any time tuning SQL Server that was always done by another team member. To me, tuning seemed like a black box feat accomplished by unknown formulas that I would never understand. On my own on that Boxing Day, I learned the mysteries behind tuning SQL Server. In truth, its really just like driving a car. By simply turning the key and becoming acquainted with a few levers and buttons, you can drive anywhere you want. With SQL Server, there are just a few key rules and tools which will put you in control of how things run on your system.

Skills Needed for this Book

If you have no SQL coding knowledge, then I recommend you first get into the groove of the Beginning SQL 2008 Joes 2 Pros book (ISBN 978-1-4392-5317-5). If you already have basic SQL skills and want to get really good at writing queries, then I recommend SQL Queries Joes 2 Pros (ISBN 978-1-4392-5318-2) as your best starting point before tackling the architecture and programming topics.

10
www.Joes2Pros.com

Chapter 1. Database File Structures

About this Book

As companies grow and do more business, the data they store in databases similarly grows. If you want to be a go-to person on the inner workings of SQL Server, then this book will be your partner in achieving that goal. If you have completed the SQL Queries Joes 2 Pros book, you already have written some advanced queries. This book builds on that knowledge and will show you more about the parts of SQL Server at work behind the scenes when you are running queries and creating new database objects. Most importantly, you will learn how to make the essential queries for your business run most efficiently and at the fastest speed possible. It is time for books and schools to compete on quality and effectiveness and not a mass marketing push. The more this book succeeds, the more we will get their attention and what people really need and are demanding. To put it simply, there is a recipe for success you are empowered to choose your own ingredients. Just learn the lesson, do the lab, study the Points to Ponder, and play the review game at the end of each chapter. Most of the exercises in this book are designed around proper database practices in the workplace. The workplace also offers common challenges and process changes over time. For example, it is good practice to use numeric data for IDs. If you have ever seen a Canadian postal code (zip code), you see the need for character data in relational information. You will occasionally see an off-thebeaten-path strategy demonstrated so you know how to approach a topic in a job interview or workplace assignment. Im often asked about the Points to Ponder feature, which is popular with both beginners and experienced developers. Some have asked why I dont simply call it a Summary Page. While its true that the Points to Ponder page generally captures key points from each section, I frequently include options or technical insights not contained in the chapter. Often these are points which I or my students have found helpful and which I believe will enhance your understanding of SQL Server. The Joes 2 Pros series began in the summer of 2006. The project started as a few easy-to-view labs to transform the old, dry text reading into easier and fun lessons for the classroom. The labs grew into stories. The stories grew into chapters. In 2008, many people whose lives and careers had been improved through my classes convinced me to write a book to reach out to more people. In 2009 the first book began in full gear until its completion (Beginning SQL Joes 2 Pros, ISBN 978-1-4392-5317-5).

11
www.Joes2Pros.com

Chapter 1. Database File Structures

How to Use the Downloadable Companion Files

Clear content and high-resolution multimedia videos coupled with code samples will take you on this journey. To give you all this and save printing costs, all supporting files are available with a free download from www.Joes2Pros.com. The breakdown of the offerings from these supporting files is listed below:
Training videos: To get you started, the first three chapters are in video format for

free downloading. Videos show labs, demonstrate concepts, and review Points to Ponder along with tips from the appendix. Ranging from 3-15 minutes in length, they use special effects to highlight key points. There is even a Setup video that shows you how to download and use all other files. You can go at your own pace and pause or replay within lessons as needed.
Answer Keys: The downloadable files also include an Answer Key for you to

verify your completed work. Another helpful use for independent students is that these coding answers are available for peeking if you get really stuck.
Resource files: Located in the resources sub-folder from the download site are

your practice lab resource files. These files hold the few non-SQL script files needed for some labs. You will be prompted by the text each time you need to download and utilize a resource file.
Lab setup files: SQL Server is a database engine and we need to practice on a

database. The Joes 2 Pros Practice Company database is a fictitious travel booking company whose name is shortened to the database name of JProCo. The scripts to set up the JProCo database can be found here.
Chapter review files: Ready to take your new skills out for a test drive? We have

the ever popular Bug Catcher game located here.

AdventureWorks: The JProCo database will be used more often but this is the first

Joes 2 Pros book which requires that you have AdventureWorks installed in order to do some of the lessons. Be aware there are many versions of AdventureWorks, and the file you need to locate and download is the AdventureworksDBCI.msi. AdventureworksDBCI.msi. Once you download and run this file, you may find that it is installed but not visible in Management Studio. You first need to attach the database. In Management Studios Object Explorer, simply right-click the Databases folder, click Attach, then click Add, and then navigate to locate the filepath for this mdf file (listed at the top of page 13). You will find it in your Program Files folder:

12
www.Joes2Pros.com

Chapter 1. Database File Structures \Microsoft SQLServer\MSSQL.1\MSSQL\Data\AdventureWorks_Data.mdf. Once you attach the file, you may need to right-click and refresh the Databases folder in order to see the AdventureWorks database in Object Explorer.

What This Book is Not

This is not a memorization book. Rather, this is a skills book to make preparing for the certification test a familiarization process. This book prepares you to apply what youve learned to answer SQL questions in the job setting. The highest hopes are that your progress and level of SQL knowledge will soon have business managers seeking your expertise to provide the reporting and information vital to their decision making. Its a good feeling to achieve and to help at the same time. Many students comment that the training method used in Joes 2 Pros was what finally helped them achieve their goal of certification. When you go through the Joes 2 Pros series and really know this material, you deserve a fair shot at SQL certification. Use only authentic testing engines drawing on your skill. Show you know it for real. At the time of this writing, MeasureUp at http://www.measureup.com provides a good test preparation simulator. The companys test pass guarantee makes it a very appealing option.

13
www.Joes2Pros.com

Chapter 1. Database File Structures

Chapter 1.

Database File Structures

In Beginning SQL Joes 2 Pros, we compared data to cargo and database objects to containers for our mission-critical data. The curriculum for that book included the core keywords for each of the four components of the SQL language: DML, DDL, DCL, and TCL. To put it plainly, this book is about what is under the hood of SQL Server: the engine and parts which process all your data. This book will utilize a great deal of DDL (Data Definition Language), since we will be addressing the design and programming of database objects those vital containers of our business data. However, we will see a fair amount of DML working hand-in-glove with DDL in this book. In the first two books, we built stored procedures using DDL statements which encapsulated the DML statements needed to handle our data tasks. When we build objects like views and functions in this book, we similarly will see statements which define the objects executed simultaneously with the data-centric statements needed to carry out the objects purpose. This is the principal reason it is better for students to gain extensive exposure to queries before launching into the Architecture class.

Figure 1.1 This book will emphasize DDL statements, as well as DDL combined with DML.

Each chapter will include instructions for the setup scripts you need to run in order to follow along with the chapter examples. The setup scripts give you the freedom to practice any code you like, including changing or deleting data or even dropping entire tables or databases. Afterwards you can rerun the setup script (or run the setup script when you reach the next section) and all needed objects and data will be restored. This process is also good practice these are typical tasks done frequently when working with SQL Server, particularly in a software development and testing environment.
READER NOTE: In order to follow along with the examples in the first section of Chapter 1, please install SQL Server and run the first setup script SQLArchChapter1.0Setup.sql. The setup scripts for this book are posted at Joes2Pros.com.

14
www.Joes2Pros.com

Chapter 1. Database File Structures

Database File Structures

In the first two Joes 2 Pros books, we used the default settings provided by SQL Server whenever we created a database. Our first topic examines database file structures and how we can customize those available structures and settings to best fit our data traffic and system performance needs. SQL Server databases consist of files which are stored on a hard drive. Actually, I should qualify that at least 80% of readers are probably like me and the server which their instance of SQL Server runs on is their local hard drive. (There may be a few developers who have a network set up and who are already running SQL Server on a separate machine or disk drive.) I have several machines, but I have one dedicated laptop I use for my Joes 2 Pros work. Lets begin with a database we are familiar with, JProCo. Ill begin by dropping this database to see what my server (i.e., my hard drive) looks like without the JProCo database. Before and after I re-create this database, we will look at my hard drive to see the net impact of the JProCo database on my system.

Figure 1.2 Upper figure: The JProCo database before I remove it from SQL Server shown alongside the code I will run to drop it. Lower figure: I have removed JProCo and double-checked the Object Explorer to confirm that it is gone.

15
www.Joes2Pros.com

Chapter 1. Database File Structures Now that JProCo has been removed, lets look at my hard drive and its current capacity. To find capacity details on your own machine, open Windows Explorer (Start+E) > right-click the C drive > Properties. It appears that I have 499 MB free on my hard drive without the JProCo database (see Figure 1.3). Ill now rerun the first setup script for this chapter in order to bring back the JProCo database. The setup script (SQLArchChapter1.0Setup.sql) will load the JProCo database onto my system fully populated (Figure 1.4, Panel A). Once the script has executed successfully, Ill go to SQL Servers Object Explorer > right-click the Databases folder > and choose Refresh (Figure 1.4, Panel B). After the refresh, the JProCo folder becomes visible in my Object Explorer (Figure 1.4, Panel C).
Figure 1.3 I have 499 MB free without the JProCo db.

Figure 1.4 Panel A the setup script has run successfully. Panel B the Databases folder is refreshed. Panel C the JProCo database becomes visible in Object Explorer.

Be aware that the Object Explorer tree does not dynamically update a database object after it is added or dropped. Expect to run this same refresh process each time you check Object Explorer and wish to see your updated changes in the list.

16
www.Joes2Pros.com

Chapter 1. Database File Structures Now I'll return to my hard drive. Recall it showed 499 MB of free space prior to reloading the JProCo database onto my system. With JProCo now reloaded on my system, my hard drive shows just 305 MB of free space (see Figure 1.5). So it appears JProCo is occupying roughly 200 MB someplace on my local drive. SQL Server chooses a default location to store databases whenever an alternate location is not specified. The filepath shown here (and in Figure 1.6) is the default location for SQL Server 2008:

Figure 1.5 Just 305 MB of space is now free.

C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA

This is the default location for SQL Server 2005:

C:\Program Files\Microsoft SQL Server\MSSQL9.MSSQLSERVER\MSSQL\DATA

This screen capture of my MSSQL\DATA folder shows the two files which comprise the JProCo database. When I ran the setup script, SQL Server loaded these two files onto my system. Notice that one file is roughly 152 MB in size (JProCo.mdf). The other file is roughly 45 MB (JProCo_log.ldf). Together they total Figure 1.6 My MSSQL\DATA folder shows two JProCo files. roughly 200 MB the same amount which we estimated JProCo occupies on my hard drive. These two files stored on the hard drive contain all of the data and all of the logging activity for the JProCo database.

17
www.Joes2Pros.com

Chapter 1. Database File Structures

DataFiles and LogFiles

In my experience, many students do not find the concept of datafile and logfile activity an intuitive one. So we will ease into it with an example that Ive found helps students grasp this topic more quickly. But first we need a little explanation as to why SQL Server uses logfiles. We know that SQL Server stores its data much like other applications in files which are saved to a persistent drive. But a distinguishing feature of SQL Server is its robust ability to keep track of things. The security and safety of your data and reliability of your system are SQL Servers top priorities. Therefore, you can imagine that logging activity which tracks every transaction made in your database is a pretty big deal. Examples where logging saves the day generally involve some type of database restore or recovery need. Once a database backs itself up, youre generally assured a reliable mechanism you can use to restore the system in case something unfavorable happens. Suppose you notice bad data has come into your system through one of your periodic feeds. In fact, this data is so problematic that your team decides you must restore the database back to the point a week ago before the bad data began entering the system. Your periodic database backup is built using information provided by the logfile. Logfiles keep track of your database transactions and help ensure data and system integrity, in case a system recovery is ever necessary. Ok, now were ready to tackle datafiles and logfiles. A datafile is fairly straightforward it contains all your current data. Suppose youve been making changes to JProCos Employee table. If you could peek into the datafile, you would find data identical with the result of SELECT * FROM Employee. However, it wouldnt tell you that an hour ago, you deleted an employee record, or that today at 9:45 a.m. your manager added a new employee record to the table. I sometimes compare the datafile to getting information from my ATM. Usually Im happy with the data my ATM shows me (i.e., my current balance), and it always provides my data rapidly. But if I need to look back and see deposit or withdrawal information, the ATM cant help me. To see the transaction detail which has led to my current account balance, I need to look elsewhere. Logfiles are just like the transaction history shown in my bank statements, where I can find a separate transaction entry for every purchase, deposit, or withdrawal made. The two identically structured WordPad files shown here (Figure 1.7 and 1.8) are going to help us visualize the transaction Figure 1.7 Two identically structured files. activity retained by the logfile.

18
www.Joes2Pros.com

Chapter 1. Database File Structures These are pretty small files, just 1 KB each. In the lesson video for this section (Lab1.1_DatabaseFileStructures.wmv), you will see me make some significant edits to Document A, which I wont make to Document B. Not only will the documents differ visually, but when we see that the changes cause Document As size to expand to 6 KB, its clear that Document A and Document B are no longer identical files. Where my classes tend to find the ah-ha moment is when we actually see the changes in Document A being removed one by one as I use Edit > Undo to backtrack and see the edits disappear. Similarly, if I delete a few words one by one, the Undo operation will backtrack and make each word reappear one by one. What the application is doing is traversing through the log of changes and accessing memory to find all of those changes. If the changes werent logged, they wouldnt be available.
Figure 1.8 Documents A & B begin as identical files.

Figure 1.9 Our demonstration with two WordPad files helps conceptualize logfile activity.

At the end of the video demonstration, Document A has been returned to its beginning state it contains the identical information as Document B and Ive saved the file in order to clear the logged changes from memory. Thus, Document A and B each are 1 KB in size at the end. But just prior to saving Document A, we make another interesting ah-ha observation. On the surface, both documents appear identical (as shown in Figure 1.10). However, when we compare the size of the two files, Document A is many times larger than Document B. In my classroom demos,

19
www.Joes2Pros.com

Chapter 1. Database File Structures the file grows to 250 KB with relatively few clicks. The log tracks changes made to the document from the last time it was saved up until the current moment.

Figure 1.10 The log tracks all the changes from the last document backup (save) until now.

At this point, an expert database admin (DBA) would understandably be bored silly with this demo. However, over the years Ive found this the fastest way to ramp up students new to the abstract concept of the work done by logfiles. When the document save operation clears out the log, we also get a nice reference point to regular server backups, which truncate (empty) the logfile. Document As condition at the beginning and end of the demo (i.e., 1 KB and reflecting the data This File is Small.) serves as a comparison to the datafile. Because the file was saved at the beginning of the demo and then again at the end, the document showed just the current state of the data nothing to do with tracking data which was added or deleted along the way. The datafiles purpose is to reflect the current state of your database. For student readers still trying to get their heads around this idea of datafiles and logfiles, have no fear the video demonstrations contain many examples, as well as a practice or challenge at the end of the video to give you plenty of practice with datafiles and logfiles. And the next four pages include a step by step tutorial following data through the datafile and logfile as it enters a new database.

20
www.Joes2Pros.com

Chapter 1. Database File Structures Step 1. Pretend you have a brand new database with one table (Employee) which contains zero records. There are no records in your JProCo database, so there are no records in your datafile. And since you havent made any changes to the database, there are zero records in your logfile.

Intro to SQL Data\Log files

Where does the data go?
Pretend you have a new database with one table called dbo.Employee and no records.

No records are in JProCo, so no records are in your datafile.

You have not made any changes in JProCo, so no records are in your logfile.

JProCo

Figure 1.11 The brand new database contains zero records.

Step 2. Now data starts coming into the JProCo database. You add one new record for Alex Adams to the Employee table. So now you have one record in your datafile and one record in your logfile.

Intro to SQL Data\Log files

Data Coming in!
You add one new record to the Employee table.

One record is in JProCo, so one record is in your JProCo datafile.

You have made one change in JProCo, so one record is in your logfile.

Figure 1.12 One record now appears in the database.

21
www.Joes2Pros.com

Chapter 1. Database File Structures Step 3. You then add another record (Barry Brown). Two records are now in JProCo, so two records are in the datafile and two records in the logfile. So you have two pieces of data and two entries in the logfile reflecting those changes.

Intro to SQL Data\Log files

More data coming in!
You add another new record to the Employee table.

Two records are in JProCo, so two records are in your JProCo datafile.

You have made two changes since the last time you backed up your database, so two records are in your logfile.

Figure 1.13 A total of two records are now in the database.

Step 4. Your next step updates an existing record. Employee 2 is coming back from leave, so youre going to change his status from On Leave to Active. There will still be two records in the database, so the datafile will contain two records. But there will be three records in your logfile, since you made three changes since the last time you backed up your database.

Intro to SQL Data\Log files

Updates to Existing Records!
Employee 2 is coming back from leave.

JProCo Two records are in JProCo, so two records are in your datafile.
2009 by Rick A. Morelan

You have made three changes since the last time you backed up your database so three records are in your logfile.

Figure 1.14 An existing record is updated; 2 records in the database but 3 records in the LDF.

22
www.Joes2Pros.com

Chapter 1. Database File Structures

Impact of the Database Backup Process

Step 5. The database is backed up nightly at midnight. After the three earlier changes happen, suppose its after midnight and the database backup has just finished running. At 12:05AM, there would still be two records in the JProCo database, so you would have two records in your datafile. During most backup processes, the changes contained in the logfile are sent to the backup file. The logfile is truncated as part of the backup process, so zero records remain in the logfile immediately after each backup.

Intro to SQL Data\Log files

Backup Time!
Your database is backed up every night at midnight. Its after midnight and your database is backed up. What happened to your Datafile and Logfile during the backup?

12:05 AM. You still have two records in JProCo, so two records are in your datafile.

All your changes were sent to the backup, so zero records are in your logfile. Your logfile has been truncated during the backup process.

JProCo

Figure 1.15 The database backup runs. The logfile is truncated, so it contains no records.

Step 6. On Day 2, you insert Lee Osakos record (the third record added to Employee). At this point you have three records in your datafile. The logfile has been empty since the backup, and this change now adds one record to the logfile.

Intro to SQL Data\Log files

Data Coming in Day 2!
The next morning you add another new record to the Employee table.

Three records are in JProCo, so three records are in your JProCo datafile.

You have made one change in JProCo since the last backup, so one record is in your logfile.

Figure 1.16 The third record is added to the db. Three records in MDF, one record in LDF.

23
www.Joes2Pros.com

Chapter 1. Database File Structures Step 7. On the same day (Day 2), you delete Barry Brown from the table. Removing one record leaves two records in the datafile. The logfile now contains two records, one for the INSERT (Lee) and one for the DELETE (Barry).

Intro to SQL Data\Log files

Deleting data day 2!
The next morning you delete Barry Brown.

Two records are in JProCo, so two records are in your JProCo datafile.

You have made two changes in JProCo since the last backup, so two records are in your logfile.

Figure 1.17 On Day 2 one record is deleted. Two records remain in MDF, two in LDF.

Recall Figure 1.6 where we saw the default data and log files which SQL Server originated when we created the JProCo database. It named the datafile JProCo.MDF and the logfile JProCo_log.LDF.

Intro to SQL Data\Log files

Data and Log file names and extensions!
Your logfile is probably called JProCo_Log.LDF (Log Data File).

Your datafile is probably called JProCo.MDF (Main Data File).

JProCo

Figure 1.18 It is highly recommended that you follow the naming convention shown here.

This convention for naming files and the extensions reflect best practice recommendations (see Figure 1.18). SQL Server does not enforce the .mdf/.ldf extensions, but following this standard is highly recommended.

24
www.Joes2Pros.com

Chapter 1. Database File Structures

Creating Databases
If you were to execute this statement, you would create a database called TSQLTestDB, and all the defaults for name, size, and location of the datafile and logfile would be chosen for you. Up until now, we have accepted SQL Servers defaults for these items each time we have created a database.

Figure 1.19 This code would create a db using defaults for name-size-location of MDF & LDF.

But you can actually choose your own options. For our examples in this chapter, we wont store any of our files in the default location (MSSQL10.MSSQLSERVER\ DATA folder). Create a folder titled SQL on your hard drive (C:\SQL). The MDF and LDF files for our new test database will be stored there. In addition to specifying the location, we will also choose the name and size for TSQLTestDBs datafile and logfile. As a rule of thumb, its generally a good idea to make the size of your LDF 25% of the MDF. Now run all of this code together.

Figure 1.20 You can choose the name, size, and location for your datafiles.

25
www.Joes2Pros.com

Chapter 1. Database File Structures Lets check the C:\SQL folder and confirm we can see the newly created files TSQLTestDB.mdf (20 MB) and TSQLTestDB.ldf (5 MB).

Figure 1.21 We specified the name, size, and location for TSQLTestDB, its MDF, and its LDF.

Now lets see how to locate metadata for this test database using SQL Servers Object Explorer. Remember to first refresh the Databases folder in the Object Explorer, since we know that SQL Server does not change its contents automatically (Object Explorer > right-click Databases > Refresh, as shown earlier in Figure 1.4). Navigate to TSQLTestDB (Object Explorer > Databases > TSQLTestDB). Then open the Database Properties dialog by right-clicking the TSQLTestDB folder > Properties. In the left-hand Select a page nav menu, click the Files page. This will show you the name for the database, the MDF, and the LDF. You can see the custom specifications we included in our CREATE DATABASE statement (see prior page, Figure 1.19) for the logical and physical name, size, and location (C:\SQL) for each file.

Figure 1.22 TSQLTestDB >

Properties.

Figure 1.23 The Database Properties dialog shows metadata for the database TSQLTestDB.

26
www.Joes2Pros.com

Chapter 1. Database File Structures

Lab 1.1: Database File Structures

Lab Prep: Each lab has one or more Skill Checks. Start with Skill Check 1 and proceed until you reach the Points to Ponder section. Before you can begin the lab, you must have SQL Server installed and have run the current setup script (SQLArchChapter1.1Setup.sql). Since this is your first lab, please make sure you have viewed the video on how to set up a typical lab called SQLArchSetupLabSteps.wmv. This video shows you the steps involved in setting up all the labs in this book. View the lab video instructions for this specific lab named Lab1.1_DatabaseFileStructures.wmv. Skill Check 1: Create a database named after your fictitious company, RatisCo. Using what youve learned, create RatisCo with the following properties. a. 50MB file named RatisCo_Data.mdf. b. A 20MB log file name RatisCo_Log.ldf. c. The file should be located at C:\SQL\RatisCo_Data.mdf d. The logfile location should be C:\SQL\RatisCo_Log.ldf When complete, your result should resemble the figure below (Figure 1.24).

Figure 1.24 In Skill Check 1, you will create the RatisCo database with the specified properties.

Answer Code: The T-SQL code to this lab can be found in the downloadable files in a file named Lab1.1_DatabaseFileStructures.sql.

27
www.Joes2Pros.com

Chapter 1. Database File Structures

Database File Structures - Points to Ponder

1. Transact-SQL (T-SQL) statements are a common way to interact with SQL Server, view and modify data, or change the configuration of the server. 2. A new database can be built through the graphical UI (user interface) in SQL Server Management Studio or by using a CREATE DATABASE script. 3. Even when a graphical management tool is used to create or modify a database, the actions are translated into T-SQL statements and then executed. 4. SQL Server stores data in one or more datafiles. 5. A file is the physical allocation of space on disk. Each database has two or more files. 6. Datafiles hold the actual database objects and the data. 7. If only one datafile exists, it will have an .MDF extension by default. 8. Regardless of how a database is created, T-SQL can be used to perform the following tasks: Create and modify tables and indexes in a database. Query objects by using the SELECT statement. Insert and delete rows in a table. Modify existing data in a table. Repair a database. Create a database. Manage and connect to other databases.

28
www.Joes2Pros.com

Chapter 1. Database File Structures

DataFile Planning and Implementation

From the last section, we know that SQL Server stores all the objects and data for a database in a datafile. Think back to our analogy of database objects as containers for data. If the containers of our mission-critical data are important, then the file responsible for physically housing all of the objects and all of the data on your disk drive merits special attention. Its wise to take extra care with design and capacity considerations for your datafiles, which is what the remainder of this chapter covers. When you create a database, you must create at least one datafile. If SQL Server needs data, we know it looks to datafiles for all of its objects. At a minimum, each database must have at least one datafile multiple datafiles are also possible. Every datafile must have a storage location (e.g., C:\SQL\JProCo.mdf) whether you define the filepath or have SQL Server choose the default location behind the scenes. Below is the default filepath.
C:\Program Files\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\DATA (SQL 2008) C:\Program Files\Microsoft SQL Server\MSSQL9.MSSQLSERVER\MSSQL\DATA (SQL 2005)

Make the datafile large enough to hold all of your expected data. Its a good idea to make sure the MDF is adequately large, even when your database starts out empty. If you estimate your data will likely grow to 5 GB of data, then create your MDF from the outset to be at least 5 GB. Your datafile size is only limited by the size of your hard drive. The minimum size for a datafile is 3 MB and 1 MB for a logfile. These are also the default file sizes when you create a database without specifying the size. The upper limit for your datafiles size is essentially the amount of available space on your available hard drives. If your datafile fills up, then SQL Server cant process additional data. One solution is you can adjust the size property of your datafile. When you increase the size property, the datafile will procure more space on the drive. You can also adjust the filegrowth property to allow the datafile to grow. You can specify the incremental rate at which you want your datafile to grow once the current size specification has been reached. This rate is known as filegrowth and is controlled by the MDFs filegrowth property. For example, assume your hard drive has 100 MB available and your MDF is approaching 30 MB, which is the maximum size you specified when you created your database. You can set the MDF to grow and occupy additional hard drive space (up to roughly 70MB more). However, if your hard drive runs out of space, then you either need a larger drive or a separate drive. Thats where Alternate Datafile Placement can be the solution. You have the option of placing your datafile on a separate drive, or even

29
www.Joes2Pros.com

Chapter 1. Database File Structures on its own dedicated drive. (e.g., if you have the D drive available, you could dedicate it just to your data D:\SQL\JProCo.mdf). Your data activity may overwhelm the throughput of one drive. In your SQL Server work, you will occasionally encounter scenarios where your business moves so quickly that the throughput of your data traffic exceeds the throughput capacity of the drive. For example, since the C drive can become very busy with operating system (OS) activity and several services running on it, you might want to reserve the throughput of the C drive for the day to day operations. Also, the main use of the database is one giant data table which receives billions of hits per hour. The activity of that table could overwhelm the throughput of any single drive. You can use Multiple Datafiles Placement to spread the entire database workload evenly across several datafiles (see Figure 1.24). In addition to your MDF (main datafile), you can create secondary datafiles and split where the storage takes place. (Note: SQL Server allows just one file per database to use the .MDF extension. Any additional datafile(s) must use the .NDF extension (for secoNdary DataFile, e.g., E:\SQL\JProCo.ndf).) A table (or any single database object) may be assigned to just one filegroup. However, you can associate a filegroup with as many datafiles as you need. Thus, when you wish to spread a giant tables workload across many drives, you will use multiple datafiles but place them all in the same filegroup. SOLUTION #1: Adjust the Size of Your Datafile You can adjust the size property of your datafile. When you increase the size property, the datafile will procure more space on the drive. You can also adjust the filegrowth property to allow the datafile to grow. If your datafile fills up, then SQL Server cant process additional data. You can specify the incremental rate at which you want your datafile to grow once the current size specification has been reached. This rate is known as filegrowth and is controlled by the MDFs filegrowth property. SOLUTION #2: Alternate Datafile Placement You may choose to place your datafile on its own dedicated drive. Since the C drive can become very busy with operating system (OS) activity and several services running on it, you might want to reserve the throughput of the C drive for the day to day operations. You have the option of placing your datafile on a separate drive, or even on its own dedicated drive. (e.g., if you have the D drive available, you could dedicate it just to your data D:\SQL\JProCo.mdf)

30
www.Joes2Pros.com

Chapter 1. Database File Structures SOLUTION #3: Multiple Datafiles for Data Placement Suppose you have already placed your datafile on a dedicated drive (e.g., the D drive, D:\SQL\JProCo.mdf), but you soon see that this drive will not be big enough for your growing database. Or perhaps its not fast enough. In addition to your MDF (main datafile), you can create a secondary datafile and split where the storage takes place. (Note: SQL Server allows just one file per database to use the .MDF extension. Any additional datafile(s) must use the .NDF extension (for secoNdary DataFile, e.g., E:\SQL\JProCo.ndf).) Suppose your database contains multiple tables and you figure out that your production tables comprise about half of the workload of your entire SQL Server database infrastructure. The other tables combined use the rest of the available workload. You can elect to have your secondary datafile dedicated to your production tables, and the remaining tables (e.g., reporting tables, lookup tables) can reside in your MDF on another drive. SOLUTION #4: Multiple Datafiles for Automatic Load Balancing Suppose the main use of your database is one giant data table which receives billions of hits per hour. The activity of that table could overwhelm the throughput of any single drive. You can spread the entire database workload evenly across several datafiles (see Figure 1.25). Note that a table (or any single database object) may be assigned to just one filegroup. However, you can associate a filegroup with as many datafiles as you need. Thus, when you wish to spread a giant tables workload across many drives, you will use multiple datafiles but place them all in the same filegroup.
Multiple Datafiles for Automatic Load Balancing
If the main use of your database is one giant data-table that gets millions of hits per hour, your data might be far too large and fast to be handled by one drive. You can spread the entire DB load evenly across many locations. C:\OperatingSystem
D:\SQL\JProCo.MDF E:\SQL\JProCo.NDF
One GIANT Table

JProCo

F:\SQL\JProCo.NDF G:\SQL\JProCo.NDF

Figure 1.25 A giant tables workload spread across many drives and datafiles, all in one filegroup.

31
www.Joes2Pros.com

Chapter 1. Database File Structures

Using Filegroups
There are many advantages to using filegroups to manage the database workload. A filegroup may contain many datafiles, and the properties of all the datafiles can be managed simultaneously with a filegroup (see Figure 1.26).

Filegroups
Managing many files at once.
If the first 4 datafiles (on the left) were for production and you wanted to change all the files properties at once, you would have to set each one individually. By putting several files into one filegroup you can manage all these files as a single item.
Filegroup1 Filegroup2

D:\SQL\JProCo.MDF E:\SQL\JProCo.NDF F:\SQL\JProCo.NDF G:\SQL\JProCo.NDF

H:\SQL\JProCo.NDF I:\SQL\JProCo.NDF J:\SQL\JProCo.NDF K:\SQL\JProCo.NDF

2009 by Rick A. Morelan

Figure 1.26 By putting several files into one filegroup, you can manage them as a single item.

Primary and Secondary Filegroups

A primary filegroup contains the primary datafile (MDF) and possibly secondary datafiles (NDF). All system tables are allocated to the primary filegroup. A secondary filegroup (also called a user-defined filegroup) contains secondary datafiles (NDF) and database objects. The default filegroup contains objects which were created without an assigned filegroup. The primary filegroup is the default filegroup unless another filegroup is specified. Logfiles are never part of a filegroup. We learned about log files at the beginning of the chapter. The log datafile tracks all the changes that have taken place since

32
www.Joes2Pros.com

Chapter 1. Database File Structures the last database backup. Whereas datafiles have the file extension .mdf or .ndf, log datafiles always have the .ldf extension.

Figure 1.27 The Log Data File (LDF) must exist but cant be part of a filegroup.

When we completed Lab 1.1, we created one datafile called RatisCo_Data.mdf in the SQL folder of the C drive (C:\SQL\RatisCo_Data.mdf). Since we didnt specify any filegroups, SQL Server automatically placed it in the primary filegroup for us. We also created a log file in the same location (C:\SQL\RatisCo_Log.ldf). That file was not placed inside a filegroup, since log files are never part of a filegroup.
Configuration of Previous Lab (Lab 1.1): One filegroup & one datafile

PRIMARY Filegroup

C:\SQL\RatisCo_Data.MDF
All Tables

Logfile C:\SQL\RatisCo_LOG.LDF (Doesnotusefilegroups)

Figure 1.28 Our previous lab created one filegroup with one datafile.

33
www.Joes2Pros.com

Chapter 1. Database File Structures Our next lab will create one datafile in the primary filegroup and two datafiles in the secondary filegroup (also known as the user-defined filegroup).

Figure 1.29 Our next lab will create one MDF in the primary filegroup, 2 NDFs in the secondary.

You will accomplish Part 1 of the Lab 1.2 by following along hands-on with the demonstration. Later you will accomplish Part 2 independently. As shown in Figure 1.29 (previous page), the goal of Part 1 will be the following: 1) Create one MDF (main datafile) in the primary filegroup; 2) Create two NDFs (secondary datafiles) in a user-defined filegroup called Order_Hist located on a separate drive; 3) Create the LDF (log datafile) on a separate drive. Note: For at least 80% of readers, its unlikely that the machine you are practicing on has several drives you can write to. Its important to practice sending datafiles to different drives upon database creation and writing our code as such. Thus, we will improvise by creating separate folders, which we will treat as drives in order to simulate workplace conditions. Lets create the following three folders on our hard drives to stand in for the C, D, and E drives, respectively: C:\C_SQL C:\D_SQL C:\E_SQL

34
www.Joes2Pros.com

Chapter 1. Database File Structures

Lets also make sure the RatisCo database has been dropped from our server: USE master GO DROP DATABASE RatisCo GO The CREATE DATABASE statement we will write for RatisCo will contain all the specifications for the datafiles and filegroups. The ON clause specifies which datafile(s) to store the database on and also accepts arguments to specify which filegroup the datafile(s) should belong to. The usual practice is to place the .MDF file in the PRIMARY filegroup. All other filegroups must be explicitly defined within the FILEGROUP argument.

Figure 1.30 Our next lab will create one MDF in the primary filegroup, 2 NDFs in the secondary.

Run the code in Figure 1.31 to create the RatisCo database.

Figure 1.31 Our code successfully executes and creates RatisCo per our specifications.

35
www.Joes2Pros.com

Chapter 1. Database File Structures

Below is the Files page from the Database Properties dialog for RatisCo (Figure 1.32, lower frame). We see RatisCo and all its files were created as we specified. The Filegroups page from the Database Properties dialog (Figure 1.32, upper frame) shows one primary filegroup containing one file and an Order_Hist filegroup containing two files.

Figure 1.32 Object Explorer>Databases>right-click RatisCo>Properties> Filegroups & Files.

Notice the default size and growth properties (Initial Size (MB) and Autogrowth) showing for RatisCo (Figure 1.32, previous page). SQL Server assigned the default settings for these properties, since we did not specify otherwise. Here we see each RatisCo file as it appears in Windows Explorer (Start+E). RatisCo and all its files appear as we created them in our code (see Figure 1.31 on the previous page for the syntax of the CREATE DATABASE statement).

36
www.Joes2Pros.com

Chapter 1. Database File Structures

Figure 1.33 We find the MDF, two NDFs, and the LDF have all been created as we specified.

In the second part of the lab, you will drop RatisCo and then create it with two files (the MDF and an NDF) in the primary filegroup, three NDF files in the Order_Hist filegroup, and one log datafile (LDF). In the final section of this chapter, we will make these types of file structure changes (add datafiles, add filegroups) to existing databases without having to first drop and re-create the database. The model for Lab 1.2 Part 2 is shown on the next page (Figure 1.34). The primary filegroup contains the current tables, and the historical tables are housed in the Order_Hist filegroup.

37
www.Joes2Pros.com

Chapter 1. Database File Structures

Figure 1.34 Next we will create two datafiles in the primary filegroup, 3 NDFs in the secondary.

Please note, in this chapter we frequently capitalize the extensions of datafiles in filenames (as .MDF, .NDF, .LDF) for illustrative purposes. As you can see, SQL Server gives you the freedom to capitalize filenames as you wish, including your file extensions. Where our code capitalized the datafile extensions, SQL Server created the file precisely as we specified. We saw the uppercase lettering reflected in both the Object Explorer and the Windows Explorer views of the files (Figures 1.31 through 1.33). Similarly, where we coded lowercase lettering for the file extensions, we saw that SQL Server again created the file precisely as we specified (Figures 1.20 through 1.23).
**NOTE: This book includes references and code samples for capabilities such as Autogrowth, Filegrowth, and Auto Shrink, which you need to be aware of as a SQL Pro. However, the rule of thumb for homes and buildings, its more expensive to remodel than to build it right the first time, also applies to constructing databases. Ideally, you want each database file to be physically located in one place and not fragmented in various locations on a drive. Each time you upsize your database in small increments, SQL Server grabs any available hard drive space. The additional space procured most likely wont be adjacent to the location on the hard drive where your datafile currently sits. More Input/Output (I/O) resources are needed when SQL Server must search for information which is scattered across a drive. Also, most SQL Pros would recommend you avoid the use of automatic settings (e.g., Autogrowth, Filegrowth, Auto Shrink, Auto Close). Not only does the frequent monitoring utilize additional CPU and system resources, but shrinking a datafile invariably results in file and index fragmentation. Instead, SQL Pros prefer to have SQL Server alert them when the database is nearing its maximum size. In cases where you do need to upsize or downsize a database, the best practice is generally to perform these tasks manually.

38
www.Joes2Pros.com

Chapter 1. Database File Structures

Lab 1.2: Using Filegroups

Lab Prep: Before you can begin the lab, you must have SQL Server installed and run the SQLArchChapter1.2Setup.sql script. View the lab video instructions in Lab1.2_UsingFilegroups.wmv. Skill Check 1 (Part 1): You should have already accomplished Part 1 of this Skill Check during the hands-on demonstration in the last section (Using Filegroups). See Figure 1.28 detailing the database file structures we created during the demonstration. Our code syntax appears in Figure 1.30, and screenshots of the created file structures appear in Figures 1.31-1.33. Skill Check 1 (Part 2): Drop the RatisCo database and re-create it with the datafiles and filegroups shown on the previous page (Figure 1.33). When complete, your Database Properties dialog (Filegroups page and Files page) should resemble the screenshots below in Figure 1.35). Object Explorer > Databases > right-click
RatisCo > Properties

Figure 1.35 Filegroups & Files pages from the Database Properties dialog for RatisCo.

Answer Code: The T-SQL code to this lab can be found in the downloadable files in a file named Lab1.2_UsingFileGroups.sql.

39
www.Joes2Pros.com

Chapter 1. Database File Structures Skill Check 2: Create the database GrowthCo using the name, size, filegrowth, and location specifications below: 1) One MDF (main datafile) in the primary filegroup and in the C:\SQL directory. 2) Initial db size is 50MB, db can grow up to 80MB max, increase by 15MB increments. 3) One LDF (log datafile) in the C:\SQL directory. 4) Initial log size is 20MB, log can grow up to 100MB max, increase by 25% increments. 5) Use the recommended naming convention. After creating this database, confirm your result matches the Database Properties dialog shown below (see Figure 1.36).
Object Explorer > Databases > GrowthCo > right-click Properties > Files (page)

Figure 1.36 The Database Properties dialog for GrowthCo confirms the properties you created.

40
www.Joes2Pros.com

Chapter 1. Database File Structures Skill Check 3: There will be times when you dont want to your database to grow automatically. You want SQL Server to notify you when the MDF or log file is full, so you can manage the upsizing process yourself. Create the database No_Growth using the name, size, filegrowth, and location specifications below: 1) One MDF (main datafile) in the primary filegroup and in the C:\SQL directory. 2) Initial db size is 40MB, db cannot grow. 3) One LDF (log datafile) in the C:\SQL directory. 4) Initial log size is 10MB, log cannot grow. Use the recommended naming convention. After creating the No_Growth database, confirm your result matches the Database Properties dialog shown below (see Figure 1.37).
Object Explorer > Databases > No_Growth > right-click Properties > Files (page)

Figure 1.37 The Database Properties dialog for No_Growth confirms the properties you created.

41
www.Joes2Pros.com

Chapter 1. Database File Structures

Using Filegroups - Points to Ponder

1. 2. 3. 4. 5. 6.
7.

A filegroup is a collection of datafiles which are managed as a single unit. SQL Server databases have a primary filegroup and may also have user defined secondary filegroups (like OrderHist). If no filegroups are defined when the database is created then the only filegroup that exists will be the PRIMARY filegroup, which is the default. The primary filegroup contains the MDF file and as many (to a maximum of 32,767) NDF files as specified. A secondary datafile is optional and will carry an .NDF extension. A database can contain a maximum of 32,767 secondary datafiles. By putting several files into one filegroup, all these files can be managed as a single item. A good use of files and filegroups is to separate files which are heavily queried (OLAP) from files which are heavily changed (OLTP). Example:
a. Products, Customers, and Sales are in one file b. Order History tables could be in another.

8. 9. 10. 11. 12. 13. 14. 15. 16.

The two main reasons for using filegroups are to improve performance and to control the physical placement of the data. Log files have a structure different from datafiles and cannot be placed into filegroups. When a database is created, at least one datafile (.MDF) must be created. Its a good idea to make the datafile large enough to hold all of the expected data. The datafile size is only limited by the size of the hard drive. A datafile can be placed on its own dedicated drive. Production tables might be so critical and have such a large workload that they need their own storage location. The FILEGROWTH property can be used to expand a datafile when it grows beyond its initial size. Setting a database datafile or logfile to no-growth is considered best for performance, but that increases the risk of a growing database running out of available SQL datafile space.

42
www.Joes2Pros.com

Chapter 1. Database File Structures 17. 18. If filegrowth is set to zero, then the datafile will never grow automatically. But the file can manually be resized at any time. If a filesize or filegrowth or any other database property is not specified then the database properties will be modeled after the model database.

43
www.Joes2Pros.com

Chapter 1. Database File Structures

Altering Database Filegroups

Our earlier examples created datafiles and filegroup(s) at the same time we created a database. It is also possible to add or change file structures within an existing database. To prepare for our demonstration, make sure the RatisCo database has been dropped from our server: USE master GO DROP DATABASE RatisCo GO We will now create a simplified version of RatisCo:

Figure 1.38 The code used to create the RatisCo database.

Suppose we had intended to create an NDF file (secondary datafile) on the D drive but forgot this step when we created the database. We can add this file without having to rebuild the database. We will do this by using an ALTER DATABASE statement. Find RatisCo in the Object Explorer, right-click it, and select Properties to open the Database Properties dialog. Then click Files in the left nav menu (Select a page) and notice the files we have created are present. The MDF has been created on our virtual C drive, and the LDF (log) is on our virtual E drive.

Figure 1.39 The Files page of the Database Properties dialog shows the files we just created.

44
www.Joes2Pros.com

Chapter 1. Database File Structures Now switch to the Filegroups page (left nav menu) and see we have just one filegroup, the Primary. Inside this filegroup we see one file, which is the MDF. We want to add a user-defined filegroup called RatisCo_OrderHist. We will then put two NDF files inside of that group.

Figure 1.40 The Filegroups page of the Database Properties dialog shows just the default filegroup.

First, add the secondary filegroup, RatisCo_OrderHist:

Figure 1.41 We can add a secondary filegroup (RatisCo_OrderHist) to an existing database.

Now lets re-check the Filegroups page of the Database Properties dialog to see the result of our code. If your dialog is still open (i.e., from Figure 1.40), then you must first close and re-open the dialog. We now see the new filegroup, RatisCo_OrderHist, which contains no files.

Figure 1.42 The secondary filegroup, RatisCo_OrderHist, is present and contains no files.

45
www.Joes2Pros.com

Chapter 1. Database File Structures Now lets create an NDF file, RatisCo_Hist1, and add it to the new filegroup.

Figure 1.43 Create the secondary datafile, RatisCo_Hist1, and add it to RatisCo_OrderHist.

Notice in Figure 1.43 we put the filegroup in square brackets even though it was not required. When you add to a filegroup like PRIMARY that is also a keyword, you may need to delimit in square brackets. Now lets re-open the Database Properties dialog and check the Filegroups page to see the changes. One file should show in RatisCo_OrderHist.

Figure 1.44 See one file now showing in the new secondary filegroup (RatisCo_OrderHist).

Now switch to the Files page and look at all the files. We can see the newly created NDF file showing on the D drive.

Figure 1.45 The new NDF file now shows in our secondary filegroup, RatisCo_OrderHist.

46
www.Joes2Pros.com

Chapter 1. Database File Structures Finally, we will add an additional NDF into the new filegroup, (RatisCo_OrderHist). We will name this file RatisCo_Hist2. However, we will use SQL Server Management Studios user interface (UI) to add this file, instead of running code which appears in Figure 1.46. First, lets look at the code statement which would accomplish this task. Do not run this code.

Figure 1.46 We will add the file RatisCo_Hist2 using the SSMS UI, not running code.

Step 1. From the Files page of the Database Properties dialog for RatisCo, click the Add button in the lower right corner of the dialog.

Figure 1.47 Step 1. Add the new NDF file by clicking Add button on the Files page.

Step 2. Notice that SQL Server has automatically populated five fields in the new row. These fields (File Type, Filegroup, Initial size (MB), Autogrowth, and Path) contain SQL Servers default values but can be customized to our specifications. The filepath shown on the next page (Figure 1.48, upper frame) is SQL Servers default location for storing data (as discussed in Figure 1.6). The default filegroup is Primary, and the initial size defaults to 3 MB and is allowed to grow by 1MB. Rows Data is the default value for File Type, but we can choose Log if we are adding a log datafile. The two fields which do not automatically populate are Logical Name and File Name. Now change the filegroup to the secondary filegroup, RatisCo_OrderHist.

47
www.Joes2Pros.com

Chapter 1. Database File Structures

Figure 1.48 Step 2. Notice the 4 default field values. Change the filegroup to RatisCo_OrderHist.

Step 3. Change the filepath to C:\D_SQL by clicking the white ellipsis button to launch the Locate Folder dialog, which opens to the MSSQL\DATA folder.

Figure 1.49 Step 3. Change the filepath to C:\D_SQL, which is serving as our makeshift D drive.

48
www.Joes2Pros.com

Chapter 1. Database File Structures Step 4. Manually enter the two file names in the two blank fields (Logical Name, File Name). The logical name for this secondary datafile (NDF) is RatisCo_Hist2. The full file name is RatisCo_Hist2.NDF

Figure 1.50 Step 4. Manually enter the Logical Name and the full File Name.

Step 5. Change the size to 1 MB (Initial Size (MB) property). Then click OK to save all the changes weve made to the new NDF file, RatisCo_Hist2. Be aware that, whenever we click OK in the Database Properties dialog, it snaps shut.

Figure 1.51 Step 5. Change the file size to 1MB instead of SQL Servers default 3MB. Click OK.

Recall the beginning of this section and our premise that we wanted to add a secondary filegroup and two NDF files to the existing RatisCo database. We altered the database with code to create the filegroup RatisCo_OrderHist (in Figure 1.42), added the first NDF file with code (Figure 1.43), and finally we added the second NDF file using the UI in SQL Server Management Studio. We see both NDF files appearing in our makeshift D drive (Figure 1.52).

Figure 1.52 Confirm that both NDF files appear in our makeshift D drive.

49
www.Joes2Pros.com

Chapter 1. Database File Structures Now re-open the Database Properties dialog to see the change reflected in the Filegroups page.

Figure 1.53 Reopen the Database Properties dialog to see all our changes reflected.

In the first two Joes 2 Pros books, we emphasized robust and reusable code as the preferred method of writing queries and creating database objects. That approach is still the best practice and is the one we hope to use most frequently in our SQL Server career. When we click through an interface to add or modify database objects, we arent creating an automatic trail to check our code (in case of error) and we arent able to easily repeat or rerun those steps the way we can with a script. However, there are helpful tools in the SQL Server Management Studio, which we should be able to navigate as part of our journey to becoming a SQL Pro. For example, we can generate the T-SQL needed to recreate the RatisCo database by navigating through Databases > RatisCo > Script Database as > CREATE To > New Query Editor Window. This can then be saved to reconstruct the database in case it is dropped. We covered a number of these tools in the first two books, and we will continue to demonstrate them in this book, as well.

50
www.Joes2Pros.com

Chapter 1. Database File Structures

Lab 1.3: Altering Database Filegroups

Lab Prep: Before you can begin the lab, you must have SQL Server installed and run the SQLArchChapter1.3Setup.sql script. View the lab video instructions in Lab1.3_AlteringDatabases.wmv. Skill Check 1: In our last example, we added two secondary datafiles to our secondary filegroup, RatisCo_OrderHist. Add a third datafile to this filegroup using code. In Figure 1.56 you can see the logical name should be RatisCo_Hist3. The file location is C:\D_SQL\RatisCo_Hist3.NDF. When complete, your result should resemble the Filegroups page (Figure 1.54) and the Files page (Figure 1.55) of the Database Properties dialog.

Figure 1.54 Your Filegroups page will show three files in RatisCo_OrderHist after Skill Check 1.

Figure 1.55 You will add the file RatisCo_Hist3.NDF to the secondary filegroup.

51
www.Joes2Pros.com

Chapter 1. Database File Structures Skill Check 2: After Skill Check 1, the RatisCo database contains one MDF (main datafile), three NDFs (secondary datafiles), and one LDF (log datafile). Add another file to the RatisCo database. Place this file in the primary filegroup. Note: since PRIMARY is a keyword use square brackets in your code [PRIMARY] when specifying the filegroup. The screenshot below is taken from the Files page of the Database Properties dialog for RatisCo. Your files logical name should be RatisCo_Data2, and the full file name will be C:\C_SQL\RatisCo_Data2.ndf (as shown in Figure 1.56). It is recommended that you write the code for this Skill Check, even if you elect to also try adding the file using the UI. When complete, your Files page should match that shown below (Figure 1.56).

Figure 1.56 You will add the file RatisCo_Data2.ndf to the primary filegroup.

Altering Database Filegroups - Points to Ponder

1. 2. 3. File structures within an existing database can be added or changed using the ALTER DATABASE command. File structures within an existing database can be added or changed using SQL Server Management Studios UI (user interface). Recall that one can generate the SQL that is executed to create the RatisCo database by navigating through Databases > RatisCo > Script Database as > CREATE To > New Query Editor Window. This can then be saved to reconstruct the database in case it is dropped. You can only have one Primary filegroup per database. You can have as many user defined filegroups as you want.

4. 5.

52
www.Joes2Pros.com

Chapter 1. Database File Structures

Chapter Glossary
Alternate Datafile Placement: Placing your datafile on a separate drive that you select. Autogrowth: The property in SQL that can be set up to determine the rate of file growth. Auto Shrink: A database setting that automatically check a database size and return unused space back to the hard drive. CREATE Database: A SQL statement that is used to create new databases and can determine specifications for the datafiles and filegroups within it. DCL: Data Control Language. A statement that affects the permissions a principal has to a securable. DDL: Data Definition Language. A statement that creates, drops or alters databases or database objects. DML: Data Manipulation language. DML statements handle the structure or design of database objects. Datafile: A file that contains your current data and whose purpose is to reflect the current state of your database. Filegroup: A collection of datafiles which are managed as a single unit. Filegrowth: A property that can be used to expand a datafile when it grows beyond its initial size. Filegrowth property: A property that can be used to expand a datafile when it grows beyond its initial size. Graphical UI: User interface. Logfile: Logfiles keep track of your database transactions and help ensure data and system integrity. Metadata: Data about data. Multiple Datafiles Placement: A process that is used to spread the entire database workload evenly across several datafiles. Primary filegroup: Contains the primary datafile (MDF) and possibly secondary datafiles (NDF). All system tables are allocated to the primary filegroup. Secondary Datafile: A secondary datafile is optional and will carry an .NDF extension. Secondary filegroup: Also called a user-defined filegroup; these contain secondary datafiles (NDF) and database objects. T-SQL: Transact Structured Query Language is the computer programming language based on the SQL standard and used by Microsoft SQL Server to create databases, populate tables and retrieve data. TCL: Transaction Control Language, or TCL, provides options to control transactions.

53
www.Joes2Pros.com

Chapter 1. Database File Structures

Chapter One - Review Quiz

1.) What is the extension given to the Main datafile? O a. MDF O b. Main O c. MData 2.) Which files do not automatically get truncated after a backup? O a. Datafile(s) O b. Logfile(s) 3.) What type of action will cause the logfile to grow but not the datafile? O a. O b. O c. O d. SELECT INSERT UPDATE TRUNCATE

4.) What type of action will cause the logfile and the data file to increase their size? O a. O b. O c. O d. SELECT INSERT UPDATE DELETE

5.) How many primary filegroups can you have? O a. None O b. One O c. Two O d. Eight O e. As many as you want 6.) How many user defined filegroups can you have? O a. None O b. One O c. Two O d. Eight O e. As many as you want

54
www.Joes2Pros.com

Chapter 1. Database File Structures 7.) What are two main reasons for using multiple filegroups? (Choose Two) a. User defined filegroups use compression to save space. b. To improve performance. c. To control the physical placement of the data. d. To open up more keyword usage. 8.) How many files can go into the primary filegroup? O a. None O b. One O c. Two O d. Eight O e. As many as you want (up to 32,767). 9.) If you have two files in the same filegroup can they be on different drives? O a. Yes O b. No 10.) Can you place an .NDF file into the primary filegroup? O a. Yes O b. No 11.) Can you place a .LDF file (log file) into the primary filegroup? O a. Yes O b. No

Answer Key
1.) a 2.) a 3.) c 4.) b 5.) b 6.) e 7.)b, c 8.) e 9.) a 10.) a 11.) b

Bug Catcher Game

To play the Bug Catcher game run the BugCatcher_Chapter01DatabaseFileStructures.pps from the BugCatcher folder of the companion files. You can obtain these files from www.Joes2Pros.com or by ordering the Companion CD.

55
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties

Chapter 2. Properties

Database Schemas, Snapshots &

Back in 2005, I heard there was some fancy invention called schemas coming later that year in the new SQL Server 2005 release. My initial reaction was, Yikes, Im already too busy and schemas must mean some fancy code design that will take many hours of serious late night studying to get a handle on. As it turned out, schemas werent difficult at all! In fact, SQL Servers use of schemas resembles a simple categorization and naming convention used from prehistoric times when humans began organizing themselves into clans. And centuries later, names progressed to the system we have now where we each have our individual name (like Bob or Paul) along with our family name (like Paul Johnson). If we were SQL Server objects, we might say our two-part naming convention was FamilyName.FirstName. Our two-part name ensures easier identification and also classification. Paul Johnson and Krista Johnson are more likely to be in the same immediate family than Paul Johnson and Paul Kriegel. In .NET programming languages, the names Johnson and Kriegel would be called Namespaces. In SQL Server we might create two tables called Employee and PayRates which belong to the HR department. We can refer to them as HR.Employee and HR.Payrates if we first set up the HR schema. All HR tables would then be created in the HR schema. You could say that the schema is SQL Servers answer to the Namespace used in .NET languages.
READER NOTE: In order to follow along with the examples in the first section of Chapter 2, please run the setup script SQLArchChapter2.0Setup.sql. The setup scripts for this book are posted at Joes2Pros.com.

56
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties

Schemas
We know that data contained and tracked in SQL Server most likely relates to an organization. The database we frequently use in the Joes 2 Pros series is JProCo, which contains all the data for this small fictitious company. No matter how small an organization, certain tables will be more important to one group than to others. For example, even in JProCo, employee and pay data would be controlled by a Human Resources group. Customer data usually is managed by the Sales and Marketing team, whether that team consists of five or 15,000 people. Shown here is the list of JProCos tables. Notice that all tables show the default dbo (database owner) prefix. There isnt any category to help indicate whether a table is managed by the Sales team or by HR. Prior to SQL Server 2005, the syntax for fully qualified names in SQL Server was [server].[databasename].[owner].[object name], and the idea of dbo pertained to [owner] or which database user created and/or was allowed to access the object. Since SQL Server 2005, the owner identity has been replaced by the schema name. This eliminates the need for a namespace to be tied to the user who created the object. You have the freedom to pick meaningful category names. In SQL Server 2005, the new schemas capability was introduced. Lets look at a sample from the AdventureWorks database to see how schemas can help organize objects within databases.

Figure 2.1 The tables in the JProCo database.

57
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties In the two screenshots here, most of the AdventureWorks schemas are visible: dbo, HumanResources, Person, Production, Purchasing, and Sales. The figure to the right shows there are 71 tables contained in AdventureWorks sorted in order of table name (Figure 2.2). Below, the Object Explorer Details window shows there are 71 tables contained in AdventureWorks sorted in order of schema (Figure 2.3). Instead of creating all tables in the general dbo schema, AdventureWorks has defined a separate category for the tables used by each of its key departments (e.g., Sales, HR).
Figure 2.2 You can sort by table name.

Figure 2.3 AdventureWorks contains several schemas (e.g., HumanResources, Production, Sales).

58
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties We can easily see that the Department, Employee, EmployeeAddress, EmployeeDepartmentHistory, EmployeePayHistory, JobCandidate, and Shift tables all belong to the HumanResources department. Tables such as CreditCard, Customer, and CurrencyRate all belong to the Sales group. The introduction of schemas (SchemaName.ObjectName) has provided more freedom for DBAs to use meaningful names to categorize tables and other database objects. Schemas and principals can also have a One-to-Many relationship, meaning that a principal may own many differently named schemas. Prior to SQL Servers 2005 release, it was not uncommon for DBAs to house each departments tables in a separate database. Now DBAs have more choices and can simply manage access to schemas, rather than managing separate databases just to be able to distinguish tables belonging to separate categories. Below we can see the five custom schemas the AdventureWorks DBA defined to manage each of the five departments tables (Figure 2.4). Notice the many other system-defined schemas which SQL Server has created for its own management and tracking of the database (db_accessadmin, db_backupoperator, etc.).

Figure 2.4 The AdventureWorks DBA created five schemas, one for each departments tables.

59
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties

Creating Schemas With Code

Now we will define several schemas of our own and then create tables within those schemas. Later we will add schemas to the JProCo database, but first well run a few practice examples inside RatisCo. The RatisCo database currently contains no tables. Before we make any changes to RatisCo, lets first check Object Explorer and confirm what schemas we find. From Management Studio, use F8 or the following path:
Management Studio > View > Object Explorer > Databases > RatisCo > Security > Schemas

To display the Object Explorer Details window, hit the F7 key or this path:
Management Studio > View > Object Explorer Details

Figure 2.5 RatisCo contains no user-defined schemas. These 13 schemas are all system-defined.

There should be just the 13 system-defined schemas no user-defined schemas are there yet, such as the Sales, Purchasing, or HumanResources schemas were now going to create. First lets make sure we are in the RatisCo database context by doing either of these items: 1) Toggling the dropdown list (as shown in Figure 2.6). OR 2) Beginning our code with a USE RatisCo statement. (Recall that GO delimits the end of a batch statement and must appear on the line below the last DDL statement.)

60
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties Now lets run this code to create the Sales schema and the Sales.Customer table.

Figure 2.6 When you are in the RatisCo db context, you will create the Sales schema and one table.

Suppose we ran the code in Figure 2.6 but forgot to first check the Object Explorer and see the 13 system-defined schemas by themselves. We would want to go back and remove the Sales schema, so we could see just the system-defined schemas. To do this, we would first need to remove Sales.Customer (DROP TABLE Sales.Customer GO) before SQL Server would allow us to remove the Sales schema (DROP SCHEMA Sales GO). SQL Server will not allow a schema to be removed, if database objects which are dependent on that schema still exist. Now lets run the code below to create two additional schemas (Figure 2.7).

Figure 2.7 These two statements create two new schemas in the RatisCo database.

Now lets check the Schemas folder to see that the newly created schemas are present (Sales, HumanResources, and Purchasing). In Figure 2.5, we saw 13 system defined schemas. We should now see a total of 16 schemas:
Management Studio > View > Object Explorer > Databases > RatisCo > Security > Schemas

61
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties

Creating Schemas with Management Studio

Next we will create two more schemas (People and Production) using SQL Server Management Studios UI:
Object Explorer > Databases > RatisCo > Security > right-click Schemas > New Schema > Schema Name: People > OK

Figure 2.8 shows the creation steps for the first schema, People. After creating the People schema, repeat the process and create the Production schema.

Figure 2.8 Create two new schemas (People and Production) in the RatisCo database.

Figure 2.9 We just added five user-defined schemas to the RatisCo database.

62
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties Well stay with the Management Studio interface and next add some records in the Sales.Customer table we created in the last section (see p. 60, Figure 2.6). We begin by navigating to this table in Object Explorer:
Management Studio > View > Object Explorer > Databases > RatisCo > Tables > Sales.Customer

As shown in Figure 2.10, we will right-click the Sales.Customer table which expands a full menu of options. Choosing Edit Top 200 Rows makes the record editing interface launch in a new tab. Now we enter the two rows of data as shown below (Figure 2.11). Just by clicking and beginning to type inside the first cell containing NULL, a new blank row will appear for us to populate. This interface is similar to Microsoft Access, in that there isnt an explicit OK or Enter button once the user clicks away from a row, the data will be entered into the database. We must enter the two records Figure 2.10 Add records using the SSMS UI. precisely as we see them here. We will continue working with these records later in this chapter. Notice the full four-part name in the tab (Server.Database.Schema.ObjectName). My server name is RENO. So the fully qualified name of this table object is RENO.RatisCo.Sales.Customer.

Figure 2.11 Manually enter two records into the Sales.Customer table.

We must enter the two records precisely as we see them here. We will continue working with these records later in this chapter.

63
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties

Qualified Names Using Schemas

Next well query to see the records and confirm they are showing in our Sales.Customer table. If we queried SELECT * FROM Customer, we would get a SQL Server error (Invalid object name 'Customer'.). Generally speaking, once we create a table within a schema, we must explicitly use the SchemaName.ObjectName naming convention whenever we call upon it. (In most cases, we will explicitly use the two part name SchemaName.ObjectName as a best practice and recommended guideline for objects created within a specific schema. Later in the security book in the Joes 2 Pros series, we will see that changing a users security settings and selecting a default schema other than dbo is one way to mitigate the requirement to explicitly invoke an object by its two-part name, even if it was created within a schema.) Another interesting point. Notice that, if we specify the database in the table name (Database.Schema.ObjectName), the query is able to locate our intended table even though the database context is set to another database (i.e., AdventureWorks). Running this query will show the two records we entered manually (Figure 2.12).

Figure 2.12 This query locates the intended table even though the context points to a different db.

When we specify (SchemaName.ObjectName) in our query (SELECT * FROM SchemaName.ObjectName), this is known as a qualified query because we are using the qualified name. Qualified queries look in the exact schema for the table. Unqualified queries (SELECT * FROM ObjectName) use dbo as the default schema and consequently only check within the dbo schema. In other words, SQL Server actually interprets the query [SELECT * FROM ObjectName] as [SELECT * FROM dbo.ObjectName]. The four part name (Server.Database.SchemaName.ObjectName) is also referred to as the fully-qualified name. Later in this book, we will see that a fully-qualified name is required with linked servers.

64
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties

Lab 2.1 Schemas

Lab Prep: Before you can begin the lab, you must have SQL Server installed and run the SQLArchChapter2.1Setup.sql script. View the lab video instructions in Lab2.1_Schemas.wmv. Skill Check 1: In the JProCo database, use T-SQL code to create the following five schemas: HumanResources, Purchasing, Production, Person, Sales Before you add these schemas to JProCo, open Object Explorer and notice the Owner dbo has just one schema created (dbo). After you add the five new schemas, your Object Explorer & Object Explorer Details should resemble Figure 2.13.

Figure 2.13 Skill Check 1 uses T-SQL code to create five new schemas in JProCo.

Answer Code: The T-SQL code to this lab can be found in the downloadable files in a file named Lab2.1_Schemas.sql

65
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties

Schemas - Points to Ponder

1. 2. A schema is a namespace for database objects. In previous versions of SQL Server, database owners and schemas were conceptually the same object. Beginning in SQL Server 2005, owners and schemas are separate, and schemas serve as containers of objects. Objects (tables, stored procedures, views, etc.) are created within a schema inside the database. Objects can be transferred between schemas by using the following code: ALTER SCHEMA schema_name TRANSFER securable_name Example: ALTER SCHEMA HumanResources TRANSFER Person.Address Each database has its own schema set. Every object in a database has a fully qualified name (Server.Database.Schema.Object). A usage example would be: SELECT * FROM Reno.RatisCo.People.Employee. To use object delimiters with the schema name it would be [People].[Employee] A fully qualified name (FQN) is the complete object identifier. The FQN includes the server name, database name, schema name, and object name. The first three parts (server, database, and schema names) are known as the qualifiers of the object name, as they are used to differentiate the object from any other database object. Partially qualified names omit some of the qualifiers by leaving them out or by replacing them with another period. For example, since Reno.JProCo..Employee does not list the schema, it is assumed to be dbo. When using fully qualified names, the object must be explicitly identified. Each object must have a unique fully qualified name. Objects can have the same simple name as long as the fully qualified names are different. Example: With multiple schemas in place , two tables with the same name could exist. For example, two Order tables: a. Sales.Order b. Production.Order 13. Within a database the name can be shortened to SchemaName.ObjectName. Example: SELECT * FROM People.Employee.

3. 4.

5. 6.

7. 8. 9.

10.

11. 12.

66
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties 14. 15. A query with a simple name might cause some confusion if multiple schemas have an object with the same name (SELECT * FROM Order). SQL attempts to search schemas for simple object names in the following order: a. SQL attempts to find simple names from the default schema. b. If no default exists (OR if the default does not contain the requested object) it attempts to find simple names from dbo. A default schema can be assigned to a user in two ways. a. Using the UI in the properties of a Database user. b. Specifying the schema name in the DEFAULT_SCHEMA clause of the CREATE or ALTER user statement. A default schema can be assigned to each database user.

16.

17.

67
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties

Database Snapshots
Most database backups sit in a file store in case you ever need to restore a database to a point in the past. We cant see the data inside the backup unless we restore the database. This makes comparing the real-time database with the backup file limited or even impossible. A new capability introduced in SQL Server 2005 is the database snapshot. A snapshot is an online, point-in-time reference to a database on our system. Think of it like taking a static picture of our database with references to its data. We can use SQL Server to query our database and look for all changes made since the last snapshot was taken. (We will see this done toward the end of this section in Figure 2.18.)

Snapshot Basics
Database snapshots are created from our source database (e.g., the JProCo database, the RatisCo database). Database snapshots are not really backups at all. A snapshot can help our database revert back to a point in time, but the snapshot relies upon the source database and must be able to communicate with it in order to function. In fact if the source database becomes corrupt or unavailable, the snapshot(s) of it will be useless. The snapshot begins as an empty shell of our database file(s) and stores only changed data pages. If our database never changes after we create the snapshot, then the snapshot will always remain just an empty shell. When we make (or write) a change to the source database, the database gets updated and the old record is then copied into the snapshot. This is known as copy on write (COW). If we query for changes, the snapshot shows us those records from its own datafiles. However, if we query a snapshot database for data that has never changed, SQL Server will fetch the data from the source database. When a change is made to the source database the new record is updated. The old record is then copied to the snapshot. In this way a snapshot maintains a view of the database as it existed when the snapshot was created.

Creating Database Snapshots

Database snapshots are one of the few features that can only be created using T-SQL code there is no point-and-click method to create a snapshot using the Management Studio UI.

68
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties Before we can create a snapshot, we need to know the name of the database and where all of its data is stored. In other words, we need to know the name and storage location for the MDF, as well as any NDF files. We want to create a snapshot of RatisCo, so lets look for the file details contained in the Files page of the Database Properties dialog for RatisCo. (Object Explorer >
Databases > right-click RatisCo > Properties > Files page (from left nav menu).)

In Figure 2.14, we see the MDF file for the RatisCo database is named RatisCo.

Figure 2.14 Prepare to create a snapshot of RatisCo by locating the MDF and NDF files (if any).

Before we create the snapshot database its a good idea to change you current query window context to the Master database. The code used to create a snapshot of a database is similar to the code we use to create a database (see Figure 2.15).

Figure 2.15 The skeleton code used to create a snapshot of the RatisCo database.

Figure 2.16 We have successfully created our snapshot of RatisCo database.

69
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties Check Object Explorer to confirm we can see the newly created snapshot.
Object Explorer > Database Snapshots > RatisCo_Monday_noon

Figure 2.17 The newly created snapshot.

Querying Source and Snapshot Database Data

We can use SQL Server to query our database and look for all changes made since the last snapshot was taken. Since we just created the snapshot, the queries below produce an identical result.

Figure 2.18 The queries of the snapshot and Sales.Customer produce an identical result.

70
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties Note that the snapshot is a static, read-only reference to the database. No matter what data or objects are added to the RatisCo database after 12:01pm Monday, the snapshot we created (RatisCo_Monday_noon) will not contain those changes. The snapshots job is to keep track of any changes impacting the data it cares about (i.e., RatisCo and its data at the time the snapshot was taken at noon on Monday). An EXCEPT query is a quick way to check for changes between the snapshot and the source database. Since we just created this snapshot of RatisCo (RatisCo_Monday_noon), we would expect there to be no difference between the snapshot and the source (see Figure 2.19).

Figure 2.19 An EXCEPT query will reveal any changes between the snapshot and the source db.

Recall with multiple query operators, the top table is dominant. So in this query, if changes had been made to data which the snapshot is tracking, the result would show the old record. To see the new record, just reverse the order of these tables so that the table from the source database is dominant. --The result of this query will be the new record(s).

SELECT * FROM RatisCo.Sales.Customer EXCEPT SELECT * FROM RatisCo_Monday_noon.Sales.Customer

(To read more on the multiple query operators EXCEPT, INTERSECT, UNION, and UNION ALL, please see Chapter 8 of SQL Queries Joes 2 Pros.)

71
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties Lets make a change to a record that was included in the Monday noon snapshot.

Figure 2.20 Changing a record in the Customer table.

Now lets reattempt our EXCEPT query with the snapshot as the dominant table.

Figure 2.21 Our EXCEPT query reveals one record changed after the Monday noon snapshot.

This result provides us two pieces of information. It tells us at least one record has changed in RatisCo since we took the Monday noon snapshot. It also provides us the old record. Lets think about the activity of the snapshot and the COW (copy on write) behavior. Prior to the moment we updated one of the records this snapshot (RatisCo_Monday_noon) is tracking, the snapshot was an empty shell. When the one record was updated in RatisCo (Figure 2.21, the CustomerName Kush-a-rama was changed to Cush-A-Rama), the source database copied the old record into the snapshot file. In other words, when RatisCo wrote the update to the record, the old record was copied into the snapshot. Afterwards, the snapshot was a shell containing exactly one record.

72
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties

Lab 2.2 Database Snapshots

Lab Prep: Before you can begin the lab, you must have SQL Server installed and run the SQLArchChapter2.2Setup.sql script. View the lab video instructions in Lab2.2_DatabaseSnapshots.wmv. Skill Check 1: Create a database snapshot from the dbBasics database called dbBasics_Monday_Noon.

Figure 2.22 The dbBasics_Monday_Noon snapshot is created.

Skill Check 2: Change the last name of Employee 106 from Davies to Santwon. Run a query to show all the changes from the source database Employee table and the snapshot database Employee table. Use the snapshot you created in the first Skill Check (dbBasics_Monday_Noon).

Figure 2.23a The data for Employee 106s old record contained in the snapshot.

Figure 2.23b The data for Employee 106s new record contained in the source database.

Answer Code: The T-SQL code to this lab can be found in the downloadable files in a file named Lab2.2_DatabaseSnapshots.sql

73
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties

Database Snapshots - Points to Ponder

1. 2. 3. Database snapshots enable working with data as it appears at a point in time rather than reflecting the current status of the data. Snapshots are useful for reporting, development, and testing purposes. Database snapshots: a. Are read-only (point-in-time) b. Must exist on the same server as the source data Snapshots are also known as a simple copy. Use the AS SNAPSHOT OF clause of the CREATE DATABASE statement to create a database snapshot. Database snapshots are read-only and static from the point in time they were created. The database which the snapshot is created from is referred to as the Source Database. Database snapshots CANNOT be created from Model, Master, or tempdb. Snapshot databases are listed in the Object Explorer and Object Explorer Details but cannot be created through the UI. Snapshot databases can only be created with the CREATE DATABASE statement with an AS SNAPSHOT OF clause appended. A snapshot can be created very quickly. Snapshots allow us to quickly create multiple point-in-time views of our data. Not every user will have permissions to create snapshots. Any user who can create a database can create a database snapshot. Database snapshots are supported by SQL Server Enterprise and are not available in every edition of SQL Server. Full-text indexing is not supported by snapshots.

4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.

74
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties

Setting Database Properties

So far weve worked quite a bit with the Database Properties dialog and its Files and Filegroups pages, which provide useful information for each database and its datafiles. In this section we will look at properties and settings found in the Options page of the Database Properties dialog.
Management Studio >View > Object Explorer > Databases > right-click RatisCo > Properties > Once inside the Database Properties dialog, choose Options from the Select a page menu.

Figure 2.24 The Options page in the Database Properties dialog displays properties and settings.

Open this page in your own instance of SQL Server and notice the several categories of settings and properties found on the Options page (Automatic, Cursor, Miscellaneous, Recovery, Service Broker, and State). Most of these settings can be altered from this page. Later we will also change properties using T-SQL code, and we will also use the scripting tool to generate T-SQL code from the Options page. Another interface where we can quickly view metadata for a database is the Object Explorer Details window. To get this window to appear press the f7 key. There are two panes and most of the data we want to see is in the lower pane. The bottom

75
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties area contains the Details Pane that displays certain details of the selected object. To see more of this lower pane drag the divider from bottom of the window (see Figure 2.25). We cannot use this interface to change settings, as might be guessed from the grey shading. However, its a handy resource for viewing high level metadata (creation date, size (MB), space available (KB)), the physical location and name of the default filegroup, and some commonly referenced properties, such as the ANSI NULL Default setting and the Read Only property.

Column Header Selection Pane

Details Pane

Figure 2.25 The Object Explorer Details window displays 21 points of metadata for a database.

Read Only and ANSI NULL Default are two of the properties we will utilize in this chapter. Figure 2.24 shows RatisCos Read Only property set to False, meaning that it is not in read-only mode. Another indication that RatisCo is not in read-only mode is that its icon displays normally in Object Explorer. A read-only databases icon will be greyed out in the Object Explorer display, and it will have a ReadOnly label alongside its name (an example is shown in Figure 2.27).

76
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties

Altering Databases Using Management Studio

Lets begin by checking our RatisCo database. If RatisCo is not already set to Read-Only mode, then we will first reset that property before proceeding. Navigate to the Database Read-Only property near the bottom of the Options page and confirm it is set to True.
Management Studio >View > Object Explorer > Databases > right-click RatisCo > Properties > Choose Options from the Select a page menu, and then scroll nearly to the bottom of the page. Database Read-Only > True > OK > Yes

Figure 2.26 Reset the Database Read-Only property of RatisCo to True.

Once weve confirmed the Database Read-Only property of RatisCo is set to True, we will recheck the Object Explorer to note the icons changed appearance (as shown on the next page in Figure 2.27). We may need to right-click the

77
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties Databases folder and choose the refresh option in order for the icon to be refreshed and display its newly modified status.

Figure 2.27 The RatisCo database is now in Read-Only mode.

When you create a table you can specify each field as NULL or NOT NULL. If you forget then SQL Server likes to say that field must be nullable. The ANSI standard says if you forget to speciy then the field will not allow nulls. If you want SQL to use the ANSI NULL default you can set this property. Use a similary process to change the ANSI NULL Default to true.

Altering Databases Using T-SQL Code

Although RatisCo is in Read-Only mode, we can query the Sales.Customer table and see the two records (see Figure 2.28).

Figure 2.28 We can query objects within the RatisCo database while it is in Read-Only mode.

Suppose we wanted to update one of these records. We cannot run an UPDATE statement while RatisCo is in Read-Only mode (see Figure 2.29).

78
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties

Figure 2.29 We cannot run an UPDATE statement while RatisCo is in Read-Only mode.

Lets now take the RatisCo database out of Read-Only mode or in other words, put it back into Read-Write mode using the T-SQL code below.

Figure 2.30 We can use T-SQL code to take the RatisCo database out of Read-Only mode.

We now reattempt our UPDATE to the Sales.Customer table.

Figure 2.31 With RatisCo no longer in Read-Only mode, we can now UPDATE Sales.Customer.

Now lets change it back to Read-Only using code.

Figure 2.32 We can use T-SQL code to put RatisCo back into Read-Only mode.

Check the Management Studio interface and see that running the code has the same effect as toggling the Database Read-Only property dropdown to True.

79
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties

Figure 2.33 Using T-SQL code has the same effect as toggling the property dropdown.

Database Code Generators

Another database setting we will use for practice is Auto Shrink, which relates to your MDF and NDF files. With this setting, you can have SQL Server periodically poll your database to check its size and return unused space back to the hard drive. The default setting is False (i.e., the default for Auto Shrink is off this feature remains in SQL Server 2005 and 2008 only for backwards compatibility), which is also what many experts recommend since shrinking and later regrowing can fragment datafiles. You may encounter a rare instance where you perform a onetime deletion of a large quantity of data and know your database will not need such a large amount of space in the future. In that case, you might consider temporarily turning on the Auto Shrink option so that your database can be downsized to its new smaller size and the excess space may be returned to the hard drive. Currently the Auto Shrink option for RatisCo is set to False. Lets use the Management Studio interface to change Auto Shrink to True and click OK. When we click OK, the properties dialog snaps shut.

80
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties

Figure 2.34 We are temporarily turning on the Auto Shrink option for RatisCo.

Now lets use T-SQL code to turn off Auto Shrink, which has the same effect as changing the dropdown to False in the Options page.

Figure 2.35 This T-SQL code will turn off the Auto Shrink option.

Suppose we need to change some properties for our database, but we arent sure of the T-SQL code syntax. Each of the nine pages within the Database Properties dialog contains a Script menu (see Figure 2.36). For most actions we can take

81
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties using these pages, we can have Management Studio generate the T-SQL code which would accomplish that action.

Figure 2.36 Management Studios scripting capability provides T-SQL code upon request.

Every operation performed in SQL Server is accomplished by the execution of TSQL code. That is to say, SQL Server requires code in order to accomplish any task, whether we accomplish the task by running code in a query window, or by clicking through the SQL Server Management Studio interface. When we write and run our own code in the query window, we are obviously providing the code. However, when we use the Management Studio interface to perform tasks (e.g., create or drop database objects, change database properties), behind the scenes SQL Server automatically generates and runs the code needed to execute our tasks. Lets have the scripting tool generate the code for the two settings weve been practicing, Auto Shrink and Database Read-Only. Open the Options page in the Database Properties dialog for RatisCo. Change the Auto Shrink and Read-Only properties (toggling the dropdowns to true and false, respectively) BUT dont yet click OK (see Figure 2.37 on next page). Once we have toggled the dropdowns for the two settings, we will hit the Script button and then the Cancel button to close the Options page.

82
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties

Figure 2.37 Management Studios scripting capability provides T-SQL code upon request.

The Script button registers the changes which weve toggled in the interface and generates a script showing us the code which will affect the change(s) we are considering. Lets run the code which Management Studio has generated for us. Make sure any query windows pointing to RatisCo are closed before running this code.

Figure 2.38 We are running the T-SQL code which Management Studio generated for us.

Notice that SQL Server automatically uses square brackets to delimit every database object name. These and other signs, such as an N appearing with Unicode characters, are often hints that a code sample was generated by a machine (i.e., SQL Server) and not written by a person.

83
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties After running the code, refresh the Databases folder in Object Explorer and see the RatisCo icon appearing normally (its no longer greyed out and the Read-Only notation is gone). Return to the Options page and see that Auto Shrink is now set to True and Database Read-Only is set to False. Since most SQL Pros do not use Auto Shrink on their databases (and prefer to manually control any database resizing operations), lets be sure to reopen the Options page and generate the code to turn Auto Shrink off for RatisCo.

Figure 2.39 Management Studio scripts the action(s) registered when you toggle dropdown items.

Before leaving this section, run the code to turn off Auto Shrink for RatisCo.

Figure 2.40 Execute the script which Management Studio generated for us.

84
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties

Lab 2.3: Setting Database Properties

Lab Prep: Before you can begin the lab, you must have SQL Server installed and run the SQLArchChapter2.3Setup.sql script. View the lab video instructions in Lab2.3_SettingDatabaseOptions.wmv. Skill Check 1: Use T-SQL code to set properties for the RatisCo database as follows: 1) ANSI NULLS Enabled to True 2) AUTO_CLOSE to True 3) Database Read-Only to False You are encouraged to obtain your code by having SQL Server Management Studio generate it for you. Skill Check 2: Reset each property of RatisCo as follows by using T-SQL code: 1) ANSI NULLS Enabled to False 2) AUTO_CLOSE to False 3) Database Read_Only to True You are encouraged to obtain your code by having SQL Server Management Studio generate it for you. Answer Code: The T-SQL code to this lab can be found in the downloadable files in a file named Lab2.3_DatabaseProperties.sql.

85
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties

Setting Database Properties - Points to Ponder

1. 2. T-SQL code can be used to manage properties and settings for the database. SQL Server also allows database properties and settings to be managed using the Options page of the Database Properties dialog.
Management Studio > View > Object Explorer > Databases > Right-click DatabaseName > Properties > Options page

3.

SQL Server Management Studios code generating capabilities can show the T-SQL code syntax for any database action available in the Database Properties dialog. Every operation performed in SQL Server is accomplished by the execution of T-SQL code. That is to say, SQL Server requires code in order to accomplish any task, whether we accomplish the task by running code in a query window, or by clicking through the SQL Server Management Studio interface. When we write and run our own code in the query window, we are obviously providing the code. However, when we use the Management Studio interface to perform tasks (e.g., create or drop database objects, change database properties), behind the scenes SQL Server automatically generates and runs the code needed to execute our tasks.

4.

86
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties

Chapter Glossary
(COW) Copy on Write: When we make (or write) a change to the source database, the database gets updated and the old record is then copied into the snapshot. This is known as copy on write (COW). Database properties: A SQL dialog box that allows you to view and set useful information for each database and its datafiles. Database Snapshots: Database snapshots are read-only (point-in-time) and must exist on the same server as the source data. Database snapshots begin as an empty shell of the database file(s) and stores only changed data pages. Fully qualified names: The syntax for fully qualified names in SQL Server is [server].[databasename].[owner].[object name]. In a fully qualified name the object must be explicitly identified. Naming convention: The convention used for naming databases and files within a system. Objects: Tables, stored procedures, views, etc. are SQL database objects. Partially qualified names: Partially qualified names omit some of the qualifiers by leaving them out or by replacing them with another period. Qualified query: Qualified queries look in the exact schema for the table. Schemas: A namespace for database objects. Script: SQL code saved as a file. Also a control in SQL Server Management Studio which allowed you to generate the underlying code for a database or object. Source database: The database which the snapshot is created from is referred to as the Source Database. System-defined schema: The schemas created by SQL. User-defined schema: Schemas created by the User.

87
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties

Chapter Two - Review Quiz

1.) Find the two things that are true about database snapshots (choose two). a. b. c. d. Are Read Only Are Read/Write Can be updated Are static at a point in time and cannot be updated.

2.) You have the following.

CREATE DATABASE dbPublish_Snap ON (Name = dbPublish_Data, FILENAME = C:\SQL\dbPubMon.ss) AS SNAPSHOT OF dbPublish

What is the name of the source database? O a. O b. O c. O d. dbPublish dbPublish_Snap dbPublish_Data dbPublish_dbPubMon

3.) You have the following code. CREATE DATABASE dbPublish_Snap ON (Name = dbPublish_Data, FILENAME = C:\SQL\dbPubMon.ss) AS SNAPSHOT OF dbPublish What is the name of the source data file? O a. O b. O c. O d. dbPublish dbPublish_Snap dbPublish_Data dbPublish_dbPubMon

4.) Database snapshots are: O a. Read Only O b. Read/Write 5.) Which statement is not true about database snapshots? O a. They are static, point in time versions of a database. O b. They must be located on the same server as the source database. O c. You can create a snapshot for any database including Master.

Answer Key
1.)a, d 2.) a 3.) c 4.) a 5.) c

88
www.Joes2Pros.com

Chapter 2. Database Schemas, Snapshots & Properties

Bug Catcher Game

To play the Bug Catcher game run the BugCatcher_Chapter02DatabaseSchemasSnapshotsProperties.pps from the BugCatcher folder of the companion files. You can obtain these files from www.Joes2Pros.com or by ordering the Companion CD.

89
www.Joes2Pros.com

Chapter 3. Data Type Usage

Chapter 3.

Data Type Usage

In the last chapter we discussed the importance of creating your database adequately large in size, in order to provide the space your data will need. While processing power, memory, and disk storage have all become cheaper and more plentiful in the last decade, the tasks of capacity planning and estimating infrastructure requirements are still important to the IT world. It is also incumbent upon you as a SQL Pro to become intimately familiar with the data types available to SQL Server and their impacts on performance and storage consumption. The next three chapters will cover data type options and usage. In your database career you will use this knowledge in designing and implementing your own database systems, as well as troubleshooting and diagnosing performance issues with existing databases. Factors affecting the space your data consumes are its data types, including fixed versus variable length, and whether or not the data type supports Unicode. The building blocks of database objects are fields, so our storage calculations will be based on the fields contained within a row.
READER NOTE: In order to follow along with the examples in the first section of Chapter 3, please run the setup script SQLArchChapter3.0Setup.sql. The setup scripts for this book are posted at Joes2Pros.com.

90
www.Joes2Pros.com