na2009 enus sql_03

Chapter 3: Advantages of SQL Server Option

3-1

CHAPTER 3: ADVANTAGES OF SQL SERVER OPTION Objectives

The objectives are:

• Define an adequate backup strategy. • Access a Microsoft Dynamics NAV database from third-party tools. • Describe the available Performance Monitoring tools. • Evaluate the scalability requirements of a Microsoft Dynamics NAV

implementation and anticipate future growth.

Introduction As stated earlier, Microsoft Dynamics® NAV can run on two servers - Classic Database Server and Microsoft SQL Server.

To the client these two server options look and perform the same. However, there are some important differences between them, including:

• The way you create a database. • The backup facilities that are available. • The ability to access the data in the database by using third-party

tools. • Performance monitoring. • Scalability. • Multi-processor support.

Multiple processor support and database creation have already been discussed in the chapter Setup and Installation.

This chapter describes the most important differences between both server options.

Microsoft Official Training Materials for Microsoft Dynamics ® Your use of this content is subject to your current services agreement

SQL Server Installation and Optimization for Microsoft Dynamics® NAV 2009

3-2

Backup Facilities An enterprise business solution must be able to manage a substantial amount of input and output activity every day. This increases the need to guard against information loss if there is database or hardware failure. Therefore, make sure that you implement a suitable backup procedure and that the system is set up so that the possibilities for data loss are minimized. If the system fails, you must be able to recover all of your data, including the data that has been modified since you made your last backup.

The SQL Server Option allows you to use two types of backup: Microsoft SQL Server backup and Microsoft Dynamics NAV backup.

Microsoft SQL Server Backup

When using the Microsoft Dynamics NAV SQL Server Option, we recommend that you use the backup facilities provided by SQL Server for your daily needs.

Microsoft SQL Server allows server-side database backups. The scope of a backup of data can be a whole database, a partial database, or a set of files or filegroups. For each of these, SQL Server supports full and differential backups.

SQL Server uses a roll forward capability to recover all the committed transactions that were carried out up to the point of failure. Roll forward is achieved by restoring your last database backup and applying all subsequent transaction log backups to re-create these transactions.

In these cases, only uncommitted work (incomplete transactions) will be lost, provided the active transaction log is also backed up and applied. The active transaction log also contains details of all uncommitted transactions. When you apply the active transaction log backup, SQL Server will roll back the uncommitted transactions.

Losing the active transaction log will prevent the system from successfully applying all the transaction log backups. One way of protecting both the transaction log files and the data files against hardware failure is to place them on mirrored disks.

When you place the primary data file and the transaction log files on different physical disks than the data files containing the user objects, you ensure that any media failure on the disks containing the user database files affects only those files. You can further protect the files from isolated media failure by placing the primary data file and the transaction log files on mirrored disks.

For more information about transaction logs, see Transaction Log Physical Architecture (http://msdn.microsoft.com/en-us/library/ms179355.aspx).

In order to apply transaction log backups, you must choose the correct options when you create your databases and implement suitable backup procedures. These options will be explained in the next section.



3-3

Microsoft SQL Server Backups

Microsoft SQL Server supports different types of backup. You should choose the type of backup that you will be using carefully in order to ensure that you achieve the level of security you require.

The four types of backup are the following:

• Database backup - this makes a backup of the entire database. • Transaction log backup - this makes a backup of the entire

transaction log. • Differential backup - this makes a backup of all committed entries

since the last database backup. • File and filegroup backup - this makes a backup of individual files or

filegroups within a database.

These can be combined to form many types of backup and restore procedures. This allows you to make your backup and restore strategy fit your database needs.

The SQL Server backup/restore system is server-based and is therefore considerably faster than the Dynamics NAV backup/restore system, which is client-based.

You can restore a SQL Server backup of a Dynamics NAV database directly into SQL Server without using Dynamics NAV. You can also create a database directly in SQL Server without first having to create it in Microsoft Dynamics NAV and then restore a SQL Server backup of a Dynamics NAV database directly into the database on SQL Server.

SQL Server allows you to make backups when the system is being used. With SQL Server, you can also automate many of your administrative tasks, including making backups. SQL Server also allows you to establish a database maintenance plan (with the help of a wizard) that includes database optimization, integrity tests and a backup plan.

SQL Server Database Tests

You should run SQL Server database consistency tests (using the SQL Server DBCC options) before making backups. However, SQL Server allows you to include integrity tests in its backup procedure.

Backup Media and Destinations

SQL Server can back up to a hard disk or to a tape. Disk files (local or network) are the most common media used for storing backups. When you back up to a tape, the tape drive must be attached locally to SQL Server.



3-4

Notice that SQL Server can write to multiple backup files at the same time (in parallel). In that case, data is striped on across all files. You can back up to multiple tapes or disk controllers to decrease the total backup time for a database. All devices used in a single backup operation must be of the same media type (disk or tape). You cannot mix disk and tape devices for a single backup.

IMPORTANT: You must never store your backups on the same disk drive as your database and/or transaction log files.

Backup Types

Microsoft SQL Server provides several backup methods to meet the needs of many different business environments and database activities.

Full Backups

A full backup of a database includes the data files and part of the transaction log. A full backup represents the database at the time that the backup was completed and serves as your baseline if there is a system failure. When you perform a full database backup, SQL Server does the following:

• Backs up all the data in the database • Backs up any changes that occurred while the backup was running • Backs up any uncommitted transactions in the transaction log.

SQL Server uses the portions of the transaction log that were captured in the backup file to ensure data consistency when the backup is restored. The restored database matches the state of the database when the backup completed, minus any uncommitted transactions. When the database is recovered, uncommitted transactions are rolled back. If your database is a read-only database, full database backups may be sufficient to prevent data loss.

Transaction Log Backups

Transaction log backups record any database changes. You typically back up transaction logs when you perform full database backups. Note the following about transaction log backups:

• You should not back up a transaction log unless you have performed a full database backup at least once.

• You cannot restore transaction logs without a corresponding database backup.

• You cannot back up transaction logs when using the Simple recovery model.



3-5

When you backup the transaction log, SQL Server does the following:

• Backs up the transaction log from the last successfully executed BACKUP LOG statement to the end of the current transaction log

• Truncates the transaction log up to the beginning of the active portion of the transaction log and discards the information in the inactive portion.

The active portion of the transaction log starts at the point of the oldest open transaction and continues to the end of the transaction log.

If you do not make any full database backups, the transaction logs will continue to grow until the transaction log has reached its predefined limit or it runs out of disk space. If you do not plan to use the Microsoft SQL Server backup features, use the Simple recovery model.

Differential Backups

You must perform a differential backup if you want to minimize the time that is required for restoring a frequently modified database. You can perform a differential backup only if you have performed a full database backup. In a differential backup, SQL Server does the following:

• Backs up the parts of the database that have changed since the last full database backup.

• Backs up any activity that occurred during the differential backup, as well as any uncommitted transactions in the transaction log.

If you have a backup strategy including differential backups, it is extremely important not to make ad hoc database backups (except copy-only backups). Ad hoc database backups will disturb the backup schedule, because they will make the differential backups unusable.

File or Filegroup Backups

If performing a full database backup on very large databases is not practical, you can perform database file or filegroup backups. When SQL Server backs up files or filegroups, it does the following:

• Backs up only the database files that you specify in the FILE or FILEGROUP options.

• Allows you to back up specific database files instead of the entire database.

When you perform database file or filegroup backups:

• You must specify the logical files or filegroups



3-6

• You must perform transaction log backups to make restored files consistent with the rest of the database.

• You should establish a plan to back up each file on a rotating basis to ensure that all database files or filegroups are backed up regularly.

Copy-only backups

SQL Server supports creating copy-only backups. Unlike other backups, a copy-only backup does not affect the overall backup and restore procedures for the database. Copy-only backups can be used to create a copy of the backup to take offsite to a safe location.

All recovery models support copy-only data backups. A copy-only backup cannot be used as a base backup and does not affect any existing differential backups.

In Microsoft SQL Server 2005, copy-only backups can be created or restored only by using the BACKUP and RESTORE Transact-SQL statements. SQL Server Management Studio does not support these backups. (In SQL Server 2008, copy-only backups can be made using SQL Server Management Studio.)

The following example shows how to create a copy-only backup from the Demo Database NAV (6-0) database:

BACKUP DATABASE [Demo Database NAV (6-0)] TO DISK='F:\BACKUPS\DemoDB60.BAK' WITH COPY_ONLY

Collations in BACKUP and RESTORE Operations

If you restore a database, RESTORE uses the collation of the source database that was recorded in the backup file. The restored database has the same collation as the original database that was backed up. Individual objects within the database that have different collations also retain their original collation. The database can be restored even if the instance on which you run RESTORE has a default collation different from the instance on which BACKUP was run.

If there is already a database with the same name on the target server, the only way to restore from the backup is to specify REPLACE on the RESTORE statement. If you specify REPLACE, the existing database is replaced with the contents of the database on the backup file, and the restored version of the database will have the same collation recorded in the backup file.

If you are restoring log backups, the destination database must have the same collation as the source database.



3-7

Backup Strategy

Determining a procedure for creating backups is a vital part of maintaining your database. If you make frequent entries in your database, you will need a backup procedure that guarantees the reliability of your data and will allow you to fully recover your data after any failures that may occur.

The choice of a backup strategy is often determined by the recoverability requirement. How much data are you willing to lose if there is a system failure? Or in other words: what is the cost of system downtime?

There are many backup strategies that can be used and each strategy has advantages and disadvantages. If your database must have a high-availability, you have to use database and transaction log backups, but you must have the necessary hardware resources to support this. If high-availability is less important, you can use the Simple recovery model. In that case, it will take more time to recover the database, as point-in-time recovery is not possible.

Point-in-time Recovery

If you want to enable point-in-time recovery, then you must use the Full or Bulk-Logged recovery model and schedule both database and transaction log backups.

Full Backup Strategy

A full database backup strategy is a recovery strategy that involves regular full database backups. If the database fails, you can restore the most recent full backup to recover the database to the same state it was when the backup was taken. Your database size and how frequently data is modified determine together the time and resources that are involved in implementing a full database strategy.

Implement a full backup strategy if:

• The database is small. The time that is required to back up a small database is reasonable.

• The database has few data modifications or is read-only. Performing a full database backup captures a reasonably complete set of data. You may be willing to accept a minor loss of data if the database fails between backups and must be restored.

The recommended recovery model for this strategy is Simple.

Database and Transaction Log Backup Strategy

When it is impractical to meet the recoverability requirements by performing only full database backups, you can perform intervening transaction log backups to have a record of all database activities that occurred between full database backups.



3-8

With this approach, you can restore a database from the most recent full backup and then apply all of the transaction log backups that were created since the last full database backup.

Differential Backup Strategy

A differential database backup strategy involves performing regular full database backups with intervening differential backups. Optionally, you can also perform transaction log backups between the full and differential backups. To recover the database if there is a disaster, you must restore the most recent full database backup, followed by the most recent differential backup, and then restore each transaction log since the differential backup in order.

Use this strategy to reduce recovery time if the database becomes damaged. For example, instead of applying multiple, large transaction logs, you can use a differential backup to apply the changes that were made to the database since the last full database backup.

File or Filegroup Backup Strategy

A file or filegroup backup strategy involves backing up individual files or filegroups on a regular basis. Usually, this strategy is implemented by alternately backing up each read/write file or filegroup. Additionally, you usually back up the transaction log between file or filegroup backups. However, this strategy is complicated and does not automatically maintain referential integrity.

Use this strategy for a very large database that is partitioned among multiple files. When combined with regular transaction log backups, this technique offers a time-sensitive alternative to full database backups. For example, if you have only one hour to perform a full database backup (which usually takes four hours), you could back up individual files each night and still ensure data consistency.

SQL Server supports mirroring of backup media, increasing the reliability of backups by providing redundancy. Backup mirroring increases reliability by reducing the impact of backup-device malfunctions. These malfunctions are especially serious because backups are the last line of defense against data loss.

Mirroring applies to both disk and tape. All backup devices for a single backup or restore operation must be of the same type (either disk or tape). Within these broader classes, you must use similar devices that have the same properties, such as drives with the same model number from the same manufacturer. Insufficiently similar devices generate an error message (3212).

NOTE: Mirrored backups can only be created or restored by using the BACKUP or RESTORE Transact-SQL statements. SQL Server Management Studio does not support these backups.



3-9

The following example shows how to make a mirrored backup:

BACKUP DATABASE [Demo Database NAV (6-0] TO DISK = 'F:\Backups\DemoDB60.bak' MIRROR TO DISK= M:\MirrorBackups\DemoDB60.bak'

Database Access Using Third-Party Tools It is much easier to access data in the database with third-party tools when you are running on the SQL Server Option for Microsoft Dynamics NAV.

Today, companies building client/server and Web-based database solutions seek maximum business advantage from the data and information distributed throughout their organizations.

Microsoft Universal Data Access (UDA) is a platform, application, and tools initiative that defines and delivers both standards and technologies and is a key element in the Microsoft foundation for application development, the Microsoft Windows® Distributed interNet Applications (DNA) architecture.

Universal Data Access provides high-performance access to many different data and information sources on multiple platforms and an easy-to-use programming interface that works with almost any tool or language, taking advantage of the technical skills developers already have. The technologies that support Universal Data Access enable organizations to create easy-to-maintain solutions and use their choice of best-of-breed tools, applications, and data sources on the client, middle tier, or server.

Another benefit of Universal Data Access is that it does not require expensive and time-consuming movement of all corporate data into a single data store, nor does it require commitment to a single vendor's products. Universal Data Access is based on open industry specifications with broad industry support and works with all major established database products. Universal Data Access is an evolutionary step from standard interfaces such as Open Database Connectivity (ODBC), Remote Data Objects (RDO), and Data Access Objects (DAO), and it significantly extends the functionality of these well-known and well-tested technologies. The Universal Data Access platform includes several technologies such as Microsoft Data Access Components and SQL Native Client.

For more information about Data Access Technologies, see http://msdn.microsoft.com/en-us/library/ms810810.aspx.

SQL ODBC

SQL Server supports ODBC via the SQL Server Native Client ODBC driver, as one of the native APIs for writing C, C++, and Microsoft Visual Basic applications that communicate with SQL Server.

SQL Server Native Client contains the SQL OLE DB provider and SQL ODBC driver in one native dynamic link library (DLL) supporting applications using APIs, such as ODBC, OLE DB and ADO, to gain access to Microsoft SQL



3-10

Server. In addition, the Windows Data Access Components (Windows DAC), which have become part of the Windows Server 2008 and Windows Vista operating systems, also provide technologies and components that can be used to build applications that access SQL Server. By providing these technologies like this, Microsoft SQL Server can be accessed by a large number of external applications. For more information, see the Data Platform Development Center (http://msdn.microsoft.com/en-us/data/default.aspx).

Many standard applications or application components provide SQL Server integration functionalities by default. Typical examples are Microsoft Office Excel, Microsoft Office Word, Microsoft Office Access, Microsoft Office InfoPath, Microsoft Visual Studio, Microsoft SQL Server Integration Services and so on.

Microsoft Dynamics NAV uses the DAC ODBC driver installed with Windows.

The SQL Server ODBC driver complies with the Microsoft Win32® ODBC 3.51 specification.

Performance Monitoring Another area in which the two server options differ is how you monitor performance. The Client Monitor can be used with both server options. When you use the Client Monitor with the SQL Server Option, it contains some additional options and fields that give you more insight into how your application is performing.

The Client Monitor is an important tool for troubleshooting performance and locking problems. You can also use it to identify the worst server calls and to identify index and filter problems in the SQL Server Option.

The Client Monitor and the Code Coverage tool now work closely together allowing you to easily identify, for example, the code that generated a particular server call. Microsoft Dynamics NAV also contains a debugger that you can use to refine functions that you write in C/AL code. The debugger can also be used with both server options.

When you are using the SQL Server Option, you can supplement these tools with the SQL Server Error Log. By enabling trace flags 1204 and 3605, you generate additional diagnostic error messages in the error log. These give you information about the type of locks that are involved in a deadlock.

For a detailed description of how to use these tools and of performance troubleshooting in general, see the manual Performance Troubleshooting Guide that is available on the Microsoft Dynamics NAV Tools CD. The Tools CD also contains some additional tools that you can use for troubleshooting.



3-11

Client Monitor

The Client Monitor is an important tool for troubleshooting performance and locking problems. The tool watchdogs the communications between an individual computer and the Classic Database Server, a locally stored database or when used with the SQL Server option. The log that is shown here shows the calls that are made to the database and provides an overview of the sequence in which the calls are made and the database objects are called.

FIGURE 3.1 THE CLIENT MONITOR WINDOW

You can also use it to identify the worst server calls and to identify index and filter problems in the SQL Server Option.



3-12

Session Monitor

Session Monitor is a powerful tool for diagnosing performance problems. It assists analysis efforts by providing information on the computers performance during a specific period of time.

FIGURE 3.2 THE SESSION MONITOR

The Session Monitor (Microsoft Dynamics NAV Database Server) helps you identify the clients that cause performance problems in a Microsoft Dynamics NAV environment.



3-13

Performance Monitor (Perfmon.exe)

Perfmon.exe allows you to open a Performance console configured with the System Monitor ActiveX control and Performance Logs and Alerts Service.

FIGURE 3.3 SYSTEM MONITOR AND PERFORMANCE LOGS AND ALERTS

System Monitor

With System Monitor, you can measure the performance of your own computer or other computers on a network in the following ways:

• Collect and view the real-time performance data of a local computer or several remote computers: Usability has been modified in the Windows Server 2003 family. For example, you can delete multiple counters at the same time and display the data properties page for a counter directly from the list window. You can save selected data from a performance log file or an SQL database to a new file for analysis for later use.

• Also new in the Windows Server 2003 family are two new security groups that help you ensure that only trusted users can access and manipulate sensitive performance data. These are the Performance Log Users group and the Performance Monitor Users group.

• View data collected either currently or previously in a counter log. With the Windows Server 2003 family, you can now concurrently view data from multiple log files.

• Present data in a printable graph, histogram, or report view.



3-14

• Incorporate System Monitor functionality into applications that support ActiveX controls, for example, Web pages, and Microsoft Word or other applications in Microsoft Office

• Create HTML pages from performance views. Views stored in HTML format can be displayed by a browser.

• Create reusable monitoring configurations that can be installed on other computers using Microsoft Management Console (MMC).

With System Monitor, you can collect and view extensive data about the usage of hardware resources and the activity of system services on computers you administer. You can define the data you want System Monitor to collect in the following ways:

• Type of data. To select the data to be collected, you specify performance objects, performance counters, and performance object instances. Some objects provide data on system resources (such as memory); others provide data on the operation of applications (for example, system services).

• Source of data. System Monitor can collect data from your local computer or from other computers on the network for which you have administrative credentials. By default, administrative credentials are required. In addition, you can include real-time data or data collected previously using counter logs. With the Windows Server 2003 family, you can now view performance data that was previously collected and stored in an SQL database by the Performance Logs and Alerts service.

• Sampling parameters. System Monitor supports manual, on-demand sampling or automatic sampling based on a time interval you specify; this functionality applies to real-time data only. When viewing logged data, you can also choose starting and stopping times so that you can view data spanning a specific time range.

In addition to options for defining data content, you have considerable flexibility in designing the appearance of your System Monitor views:

• Type of display. System Monitor supports graph, histogram, and report views. The graph view is the default view; it offers the widest variety of optional settings.

• Display characteristics. For any of the three views, you can define the colors and fonts for the display. In graph and histogram views, you can select from many options when you view performance data: o Provide a title for your graph or histogram and label the vertical

axis.



3-15

o Set the range of values depicted in your graph or histogram. o Adjust the characteristics of lines or bars plotted to indicate

counter values, by using color, width, style, and other graphical features.

For more information about the performance-monitoring process and interface, see Performance console overview (http://technet.microsoft.com/en-us/library/cc785096(WS.10).aspx) and System Monitor interface (http://technet.microsoft.com/en-us/library/cc776933(WS.10).aspx).

Performance Logs and Alerts

With Performance Logs and Alerts you can collect performance data automatically from local or remote computers. You can view logged counter data using System Monitor or export the data to spreadsheet programs or databases for analysis and report generation. Performance Logs and Alerts offers the following capabilities:

• Performance Logs and Alerts collects data in a comma-separated or tab-separated format for easy import to spreadsheet programs. A binary log-file format is also provided for circular logging or for logging instances such as threads or processes that may begin after the log starts to collect data. (Circular logging is the process of continuously logging data to a single file, overwriting previous data with new data.)

• You can also collect data in an SQL database format. This option defines the name of an existing SQL database and log set within the database where the performance data will be read or written. This file format is useful when collecting and analyzing performance data at an enterprise level rather than a per-server basis.

• Counter data collected by Performance Logs and Alerts can be viewed during collection and after collection has stopped.

• Because logging runs as a service, data collection occurs regardless of whether any user is logged on to the computer being monitored.

• You can define start and stop times, file names, file sizes, and other parameters for automatic log generation.

• You can manage multiple logging sessions from a single console window.

• You can set an alert on a counter, thereby defining that a message be sent, a program be run, an entry made to the application event log, or a log be started when the selected counter's value exceeds or falls below a specified setting.



3-16

Similar to System Monitor, Performance Logs and Alerts supports defining performance objects, performance counters, and object instances, and setting sampling intervals for monitoring data about hardware resources and system services. Performance Logs and Alerts also offers other options related to recording performance data:

• Start and stop logging either manually on demand or automatically based on a user-defined schedule.

• Configure additional settings for automatic logging, such as automatic file renaming, and set parameters for stopping and starting a log based on the elapsed time or the file size.

• Create trace logs. Using the default system data provider or another application provider, trace logs record detailed system application events when certain activities such as a disk I/O operation or a page fault occurs. When the event occurs, logs the data to a file specified by the Performance Logs and Alerts service. This differs from the operation of counter logs; when counter logs are being used, the service obtains data from the system when the update interval has elapsed, rather than waiting for a specific event. A parsing tool is required to interpret the trace log output. Developers can create such a tool using application programming interfaces (APIs) provided on the Performance Logs and Alerts interface

Dynamic Management Views and Functions

Introduced in Microsoft SQL Server 2005, dynamic management views (DMV) and functions (DMF) return server state information that can be used to monitor the health of a server instance, diagnose problems, and tune performance.

There are two types of dynamic management views and functions:

• Server-scoped dynamic management views and functions. • Database-scoped dynamic management views and functions. .

All dynamic management views and functions exist in the sys schema and follow this naming convention: dm_*. When you use a dynamic management view or function, you must prefix the name of the view or function by using the sys schema.

Dynamic management views can be referenced in Transact-SQL statements by using two-part, three-part, or four-part names. Dynamic management functions on the other hand can be referenced in Transact-SQL statements by using either two-part or three-part names.



3-17

Dynamic management views and functions have been organized into a number of categories:

• Change Data Capture Related Dynamic Management Views and Functions

• Common Language Runtime Related Dynamic Management Views • Database Mirroring Related Dynamic Management Views • Database Related Dynamic Management Views • Execution Related Dynamic Management Views and Functions • Full-Text Search Related Dynamic Management Views • Index Related Dynamic Management Views and Functions • I/O Related Dynamic Management Views and Functions • Object Related Dynamic Management Views and Functions • Query Notifications Related Dynamic Management Views • Replication Related Dynamic Management Views • Resource Governor Dynamic Management Views • Service Broker Related Dynamic Management Views • SQL Server Extended Event Related Dynamic Management Views • SQL Operating System Related Dynamic Management Views • Transaction Related Dynamic Management Views and Functions • Security Related Dynamic Management Views

For Microsoft Dynamics NAV 2009, the most important views are I/O Related, Index Related, Execution Related and Database Related DMVs.

In the Performance Audit chapter we will cover some of these DMVs in more detail.

For more information about DMV and DMF in SQL Server, see Dynamic Management Views and Functions (http://msdn.microsoft.com/en-us/library/ms188754.aspx).

SQL Server Performance Dashboard Reports

The Microsoft SQL Server 2005 Performance Dashboard Reports are used to monitor and resolve performance problems on your SQL Server 2005 database server. The SQL Server instance being monitored and the Management Studio client used to run the reports must both be running SP2 or a later version.



3-18

The SQL Server 2005 Performance Dashboard Reports are Reporting Services report files designed to be used with the Custom Reports feature that was introduced in the SP2 release of SQL Server Management Studio. The reports allow a database administrator to quickly identify whether there is a current bottleneck on their system, and if a bottleneck is present, capture additional diagnostic data that may be required resolve the problem. For example, if the system is experiencing waits for disk IO the dashboard allows the user to quickly see which sessions are performing the most IO, what query is running on each session and the query plan for each statement.

FIGURE 3.4 THE PERFORMANCE DASHBOARD REPORTS

Common performance problems that the dashboard reports may help resolve include:

• CPU bottlenecks (and what queries are consuming the most CPU) • IO bottlenecks (and what queries are performing the most IO). • Index recommendations generated by the query optimizer (missing

indexes). • Blocking. • Latch contention.



3-19

The information captured in the reports is retrieved from SQL Server's dynamic management views. There is no additional tracing or data capture required, which means the information is always available and this is a very inexpensive means of monitoring the server.

Reporting Services is not required to be installed to use the Performance Dashboard Reports.

The Performance Dashboard Reports can be downloaded from http://www.microsoft.com/downloads/details.aspx?familyid=1d3a4a0d-7e0c-4730-8204-e419218c1efc&displaylang=en.

SQL Server Activity Monitor

Use Activity Monitor to obtain information about SQL Server processes and how these processes affect the current instance of SQL Server.

FIGURE 3.5 THE SQL SERVER ACTIVITY MONITOR

Activity Monitor is a tabbed document window that has the following expandable and collapsible panes: Overview, Active User Tasks, Resource Waits, Data File I/O, and Recent Expensive Queries. When any pane is expanded, Activity Monitor is querying the instance for information. When a pane is collapsed, all querying activity stops for that pane. You can also expand one or more panes at the same time to view different kinds of activity on the instance.



3-20

For the columns that are included in the Active User Tasks, Resource Waits, Data File I/O, and Recent Expensive Queries panes, you can customize the display in the following ways:

• To rearrange the order of the columns, click the column heading and drag it to another location in the heading ribbon.

• To sort a column, click the column name. • To filter on one or more columns, click the drop-down arrow in the

column heading, and then select a value.

To view the Activity Monitor in SQL Server 2005 and SQL Server 2008, a user must have VIEW SERVER STATE permission.

To open the Activity Monitor:

1. On the SQL Server Management Studio standard toolbar, click Activity Monitor.

2. In the Connect to Server dialog box, select the server name and authentication mode, and then click Connect.

You can also open Activity Monitor at any time by pressing CTRL+ALT A.

To open Activity Monitor in Object Explorer, right-click the instance name, and then select Activity Monitor.

Database Engine Tuning Advisor (DTA)

Database Engine Tuning Advisor is a tool that analyzes the performance effects of workloads run against one or more databases. A workload is a set of Transact-SQL statements that executes against databases you want to tune. After analyzing the effects of a workload on your databases, Database Engine Tuning Advisor provides recommendations to add, remove, or modify physical design structures in Microsoft SQL Server databases. These physical performance structures include clustered indexes, nonclustered indexes, indexed views, and partitioning. When implemented, Database Engine Tuning Advisor recommendations enable the query processor to perform workload tasks in the shortest period of time.

Tuning your databases with Database Engine Tuning Advisor requires no expertise in database structure, workloads, or the internal workings of SQL Server.

Database Engine Tuning Advisor provides two interfaces:

• A stand-alone graphical user interface tool for tuning databases, and viewing tuning recommendations and reports.

• A command-line utility program, dta.exe, for Database Engine Tuning Advisor functionality in software programs and scripts.



3-21

In previous releases of SQL Server, some Database Engine Tuning Advisor functionality was provided by the Index Tuning Wizard. Database Engine Tuning Advisor evaluates more types of events and structures, and provides better quality recommendations.

For more information, see Tuning the Physical Database Design (http://msdn.microsoft.com/en-us/library/ms191531.aspx).

SQL Server Profiler

SQL Server Profiler is a tool that captures SQL Server events from a server. The events are saved in a trace file that can later be analyzed or used to replay a specific series of steps when trying to diagnose a problem. SQL Server Profiler is used for activities such as:

• Stepping through problem queries to find the cause of the problem. • Finding and diagnosing slow-running queries. • Capturing the series of Transact-SQL statements that lead to a

problem. The saved trace can then be used to replicate the problem on a test server where the problem can be diagnosed.

• Monitoring the performance of SQL Server to tune workloads. For information about how to tune the physical database design for database workloads, see Database Engine Tuning Advisor Overview (http://msdn.microsoft.com/en-us/library/ms173494.aspx).

• Correlating performance counters to diagnose problems

SQL Server Profiler also supports auditing the actions performed on instances of SQL Server. Audits record security-related actions for later review by a security administrator.

Performance Data Collector (SQL 2008)

SQL Server 2008 introduced a new performance monitoring tool called the data collector. The data collector stores data in the management data warehouse (MDW). There are five collector types: T-SQL Query, SQL Trace, Performance Counters, and Query Activity. Out of the box, SQL Server 2008 provides the following system data collection definitions:

• Disk Usage. Collects local disk usage information for all the databases of the SQL Server instance. This information can help you determine space usage and space requirements for disk capacity planning.

• Server Activity. Collects SQL Server instance-level resource usage information such as CPU, memory, and I/O. This information can help you monitor short-term to long-term resource usage trends and identify potential resource bottlenecks on the system. It can also be used for resource capacity planning.



3-22

• Query Statistics. Collects individual statement-level query statistics, including query text and query plans. This information can help you identify top resource consuming queries for performance tuning.

The data collector is implemented as SQL Server Information Services (SSIS) packages. These packages can be configured to run manually, continuously, or scheduled as SQL Server Agent jobs to periodically collect and upload data to a central database referred to as the management data warehouse (sometimes known as the MDW). The MDW is simply a database serving the purpose of storing the collected data for viewing and reporting. The following figure shows the architecture of the feature.

FIGURE 3.6 DATA COLLECTION ARCHITECTURE

A single MDW database can serve as the central repository for data collectors running on multiple target SQL Server instances. The data collectors are configured on each target server, and they collect and upload data to the MDW database, which can be on a remote server. Between the time that the data is captured and the time it is uploaded, the data collector can write temporary data into cache files on the target server. The collection sets are usually run as SQL Server Agent jobs, so metadata about collection frequency, what items to collect, and so on, is stored in the msdb database. The system collection sets have predefined reports, which are accessed through SQL Server Management Studio and used to visualize the captured data.

You can change the schedule of collection sets if they are configured as scheduled jobs. You can also specify how long to keep the collected data and where to store cached data prior to upload. For example, by default, the Server Activity collection set collects data every minute and uploads data every 15 minutes. Depending on the time frame of your target window, you might choose to decrease the collection frequency to 5 minutes, which will capture only one-fifth of the data (mostly performance counters).



3-23

The definition of system collection sets cannot be modified. However, you can define your own collection sets and store that information in the MDW (tables will be created in the custom_snapshots schema) and define your own custom reports for this data.

Scalability Another one of the main differences between the two server options is scalability, not only in terms of hardware resources but also in terms of concurrent users.

Before starting a new Microsoft Dynamics NAV implementation, we strongly recommend to consider the scalability requirements and select adequate hardware resources and software platforms.

Microsoft SQL Server provides a better scalability than Classic database server. While the Classic database server supports only one processor and up to 1 GB of memory, SQL Server can be configured to use multiple processors and more memory. In addition, the maximum database size for the Classic database server is 132 GB, where SQL Server (except Express and Compact editions) can scale out to bigger databases. For detailed feature specifications, see http://www.microsoft.com/sqlserver/2008/en/us/editions-compare.aspx.

The SQL Server Option also supports more concurrent users than Classic Database Server. In August 2008, Microsoft has run tests to compare the performance of Microsoft Dynamics NAV 5.0 SP 1 on SQL Server 2005 SP2 with that of Microsoft Dynamics NAV 5.0 SP 1 on a classic database.

Test results clearly show that Microsoft Dynamics NAV 5.0 SP1 performs at a better level with Microsoft SQL Server than with a classic database, and in particular SQL Server outperforms the other database with greater levels of concurrent use. This means that Microsoft Dynamics NAV customers can fully enjoy the benefits of SQL Server 2005 while improving the performance and scalability of Microsoft Dynamics NAV. The combination of Microsoft Dynamics NAV 5.0 SP1 and SQL Server 2005 SP 2 allows users to process documents faster and more efficiently, which means that customers can push more business through the system.

Summary In this chapter you have seen the differences between the two database platforms. The different types of backups in Microsoft SQL Server were explained and the tools you can use to monitor performance for a Microsoft Dynamics NAV 2009 database on SQL Server. In the next chapter, Performance Audit, you will find more detailed information, scripts, procedures and examples on how to conduct a performance review, by using the tools introduced in this chapter.



3-24

Test Your Knowledge Test your knowledge with the following questions.

1. Which recovery model is required to enable point-in-time recovery? (Select all that apply)

( ) Simple ( ) Bulk-Logged ( ) Full ( ) All of the above

2. Which backup strategy allows point-in-time recovery? (Select all that apply)

( ) Full Backup Strategy ( ) Database and Transaction Log Backup Strategy ( ) File or Filegroup Backup Strategy ( ) Differential Backup Strategy, combined with Transaction Log

Backups

3. What is true about SQL Server Native Client ODBC driver?

( ) SQL Server Native Client ODBC driver is installed automatically with the client.

( ) SQL Server Native Client ODBC driver can write to the database. ( ) SQL Server Native Client ODBC driver ensures data consistency and

validation by firing C/AL code triggers. ( ) SQL Server Native Client ODBC driver can be used to access Classic

database and SQL Server database.

4. Which tools can be used to monitor performance on a classic database? (Select all that apply)

( ) Client Monitor ( ) Session Monitor ( ) Performance Data Collector ( ) Perfmon



3-25

5. What are Dynamic Management Views and Functions used for and how can you use them?

6. One of your customers wants to upgrade to Microsoft Dynamics NAV 2009. You have calculated the initial size of the database to be 110 GB, with an expected annual growth of 20%. Which server option will you recommend and why?



3-26

Lab 3.1 - Create a Backup and Restore to a Point in Time In this lab you will use the point in time restore option of Microsoft SQL Server.

Scenario

To update some fields in the Customer table, Mort runs a processing-only report that executes a DELETEALL operation on a temporary instance of the Customer table. After running the report, Mort notices that his report contained an error. He forgot to use a temporary instance, and as a result, all customers in the production environment have disappeared.

In order to resolve this issue, Tim, the IT-manager, starts by creating a backup of the production environment. Next, he restores the backup to a point in time shortly before the DELETEALL operation.

In the next lab, Tim will copy the Customers from the test to the live database.

Challenge Yourself!

Make a full backup and a transaction log backup from the Demo Database NAV (6-0) database. Next, delete all customers from the database by running a small processing-only report, to simulate a disaster scenario. Make a new database and transaction log backup. Restore the latest backup to a new database Test Database NAV (6-0) and reapply the transaction log to a point in time that precedes the DELETEALL statement. Check the Customer table in the Test database.

Need a Little Help?

1. Enable Database and Transaction Log Backups for the Demo Database NAV (6-0) database.

2. Create a report to delete all customers. 3. Make a Database and Transaction Log Backups for the Demo

Database NAV (6-0) database. 4. Restore the Database Backup to a New Test Database To a Point In

Time. 5. Check the Customer table.

Step by Step

Create Database Backup for the Demo Database NAV (6-0) database

1. Open SQL Server Management Studio. 2. In the Object Explorer pane, expand the Databases tree.



3-27

3. Right-click the Demo Database NAV (6-0) database and select Tasks > Back Up.

4. In the Back Up Database window, enter the following settings to create a full database backup:

FIGURE 3.7 THE BACKUP DATABASE WINDOW FOR A FULL BACKUP

5. Click OK to start the backup.

Create a Transaction Log Backup for the Demo Database NAV (6-0) database




3-28


4. In the Back Up Database window, enter the following settings to create a transaction log backup:

FIGURE 3.8 THE BACKUP DATABASE WINDOW FOR A TRANSACTION LOG BACKUP


Delete all Customers

1. Open Microsoft Dynamics NAV 2009 Classic client. 2. In the Tools menu, select Object Designer. 3. Click Report. 4. Click New. 5. In the New Report window, select Create a blank report. 6. Click OK. 7. In the Report Designer window, on the first blank line, press

Shift+F4 to open the Properties window. 8. In the Properties window, set the ProcessingOnly property to Yes.



3-29

9. In the Report Designer window, on the first blank line, enter Customer in the DataItem column.

10. Select the newly added data item and press F9 to open the C/AL Editor window.

11. Enter the following lines of code in the OnPreDataItem() trigger.

FIGURE 3.9 THE CODE TO DELETE ALL CUSTOMERS

12. On the File menu, select Save As... 13. Save the report as 123456701, Delete All Customers. 14. Close the Report Designer window. 15. In the Object Designer window, select report 123456701 and then

click Run. 16. In the Report Request form, click the OK button. A dialog box will

be displayed. 17. Write down the time displayed in the dialog box and then click Yes.

The customers will now be deleted. 18. In the Object Designer, click Table. 19. Select table 18, Customer. 20. Click Run to open the Customer table. As you can see, all customers

have been deleted.

Make a Transaction Log Backups for the Demo Database NAV (6-0) database




3-30


4. In the Back Up Database window, enter the following settings to create a transaction log backup:

FIGURE 3.10 THE BACKUP DATABASE WINDOW FOR A TRANSACTION LOG BACKUP


Restore the Database Backup to a New Test Database To a Point In Time

The backup set Lab_3_2.trn contains two transaction log backups: one executed before the deletion, and one made after the deletion. When restoring the test database, you can safely restore the entire first transaction log, as it contains database changes made before the deletion. However, you must make sure not to restore the complete transaction log. To stop the restore at a specific point in time, you can add the STOPAT parameter to the RESTORE command.

1. Open SQL Server Management Studio.



3-31

2. In the Object Explorer pane, right-click the Databases node and select Restore database.

3. In the Restore database window, specify the following restore options:

FIGURE 3.11 THE RESTORE DATABASE WINDOW

4. In the Restore Database window, click the Script button. An SQL script for the restore operation will now be generated.

RESTORE DATABASE [Test Database NAV (6-0)] FROM DISK = N'C:\Lab_3_2.bak' WITH FILE = 1, MOVE N'Demo Database NAV (6-0)_data' TO N'C:\Program Files\Microsoft Dynamics NAV\60\Database\Test Database NAV (6-0).MDF', MOVE N'Demo Database NAV (6-0)_log' TO N'C:\Program Files\Microsoft Dynamics NAV\60\Database\Test Database NAV (6-0)_1.LDF', NORECOVERY, NOUNLOAD, STATS = 10 GO RESTORE LOG [Test Database NAV (6-0)] FROM DISK = N'C:\Lab_3_2.trn' WITH FILE = 1,



3-32

NORECOVERY, NOUNLOAD, STATS = 10 GO RESTORE LOG [Test Database NAV (6-0)] FROM DISK = N'C:\Lab_3_2.trn' WITH FILE = 2, NOUNLOAD, STATS = 10, RECOVERY, STOPAT=N'YYYY-MM-DDTHH:MM:SS' GO

At the bottom of the script, you will see the RESTORE command for the second transaction log.

5. To this RESTORE command, add the RECOVERY and STOPAT=N'YYYY-MM-DDTHH:MM:SS' parameters, where YYYY-MM-DD and HH:MM:SS represent the date and time to which you want to restore the transaction log. In this case, replace the time with the start time of the DELETEALL - 1 second.

6. Click the Execute button to run the SQL script.

When the database has been restored, right-click the Databases tree in the Object Explorer then select Refresh. The Test Database NAV (6-0) database will appear in the Databases tree.

Check the Customer table in the Test Database NAV (6-0) database

1. Open SQL Server Management Studio. 2. In the Object Explorer pane, expand the Databases tree. 3. In the Test Database NAV (6-0) database; expand the Tables node. 4. Right-click the Cronus International Ltd_$Customer table and

choose Select Top 1000 Rows. You will notice that all customers are still in the test database. You can now start transferring the customer data from the Test Database NAV (6-0) to the Demo Database NAV (6-0) database.



3-33

Lab 3.2a - Transfer Data from Test to Live Database (Transact-SQL)

In this lab, you will use SQL Server features to transfer data between databases.

Scenario

After restoring the database to a point in time, Tim needs to get the lost Customer data back into the live database. Tim does not want to lose time developing C/SIDE objects to export and import the data. Instead, he will use built-in features of SQL Server to transfer the data. In this lab, Tim will use a Transact-SQL statement.

Before copying the data, Tim will make sure he is the only person working in the Demo Database NAV (6-0) database. He instructs the other users to leave the database and opens the database in single-user mode. After copying the data, Tim removes the single-user flag.

Challenge Yourself!

Open the Demo Database NAV (6-0) database in single-user mode. Use a Transact-SQL statement to move the Customer data from the Test Database NAV (6-0) to the Demo Database NAV (6-0) database. Remove the single-user mode flag.

Need a Little Help?

1. Open the Demo Database NAV (6-0) database in single-user mode. 2. Create the Transact-SQL query. 3. Design the Transact-SQL query. 4. Execute the Transact-SQL query. 5. Check the Customer table in Demo Database NAV (6-0). 6. Remove the single-user mode flag.

Step by Step

Open the Demo Database NAV (6-0) database in single-user mode

1. Open Microsoft Dynamics NAV 2009 Classic client. 2. In the File menu, select Database, Information to open the

Database Information window.



3-34

3. On the Sessions tab, check that the Current Sessions field displays 1. You can click the lookup button to see a list of all active database sessions. In the list, you can see the Host Name and User ID of all active database sessions. If the Current Sessions field does not display 1, you will be unable to open the database in single-user mode.

4. Close the Database Information window. 5. In the File menu, select Database, Alter to open the Alter Database

window. 6. On the Options tab, and select the Single-user option. 7. Click OK to close the Alter Database window and activate the

single-user mode. 8. Exit the Microsoft Dynamics NAV Classic client.

If you look at the list of databases in SQL Server Management Studio, you will see the Demo Database NAV (6-0) listed as Demo Database NAV (6-0) (Single-user).

FIGURE 3.12 DATABASE MARKED AS SINGLE-USER



3-35

In addition, in the Database Properties window in SQL Server Management Studio, you will see that the Restrict Access property is now set to SINGLE_USER. Be aware that you must exit the Microsoft Dynamics NAV Classic client before you can look at the database properties.

Create the Transact-SQL query

1. Open SQL Server Management Studio. 2. Connect to the NAV-SRV-01 Database Engine. 3. Click the New Query button. 4. In the new query window, enter the following SQL statement:

SELECT * FROM [Test Database NAV (6-0)].[dbo].[CRONUS International Ltd_$Customer]

Design the Transact-SQL query

1. In the New Query window, select the entire SQL statement. 2. Right-click the selected line and select Design Query in Editor. 3. In the Query Designer window, in the top pane, remove the check

mark in front of the time stamp column, to exclude the time stamp column.

FIGURE 3.13 THE QUERY DESIGNER WINDOW

In the bottom pane, the time stamp will be removed from the SELECT clause.

4. Click OK to close the Query Designer window and return to the query window.



3-36

5. In the Query window, select the list of fields between the SELECT and FROM keywords.

6. Press Ctrl+C to copy the list to the Clipboard. 7. Place the cursor before the SELECT keyword. 8. Press Enter to insert a new line. 9. On the new line, enter the following command:

INSERT INTO [Demo Database NAV (6-0)].dbo.[CRONUS International Ltd_$Customer] ()

10. Place the cursor between the parenthesis. 11. Press Ctrl+V to insert the field list from the Clipboard. The query

window will now look like this:

FIGURE 3.14 THE QUERY WINDOW WITH THE INSERT INTO ... SELECT... STATEMENT



3-37

Execute the Transact-SQL query

Click the Execute button to run the query. The data is now transferred from the Test Database NAV (6-0) to the Demo Database NAV (6-0) database.

Check the Customer Table in Demo Database NAV (6-0)

1. In the Object Explorer window in SQL Server Management Studio, expand the Databases node.

2. Select and expand Demo Database NAV (6-0). 3. In the Tables node, right-click the CRONUS International

Ltd_$Customer table and select Select Top 1000 Rows. A new query window is opened, showing all customers.

Remove the Single User flag

1. Open SQL Server Management Studio. 2. Click the New query button to open a new query window. 3. In the Query window, enter the following command:

ALTER DATABASE [Demo Database NAV (6-0)] SET MULTI_USER WITH NO_WAIT

4. Click the Execute button. The single-user flag will be removed.

If you refresh the list of databases in SQL Server Management Studio, you see that the (Single-user) tag has been removed for the Demo Database NAV (6-0) database. In addition, in the Database Properties window, the Restrict Access property is reset to MULTI_USER.

In the Alter Database window in the Classic client, the single-user option is no longer selected.



3-38

Lab 3.2b - Transfer Data from Test to Live Database (SSIS) In this lab, you will use SQL Server features to transfer data between databases. The method described in this lab can be used as an alternative for the one described in the previous lab.

Scenario

After restoring the database to a point in time, Tim needs to get the lost Customer data back into the live database. Tim does not want to lose time developing C/SIDE objects to export and import the data. Instead, he will use built-in features of SQL Server to transfer the data. In this lab, Tim will use the SQL Server Import and Export Wizard to create a SQL Server Integration Services (SSIS) package.

Before copying the data, Tim will make sure that nobody is working in the Demo Database NAV (6-0) database. He instructs the other users to leave the database and opens the database in restricted user mode. After copying the data, Tim removes the restricted user flag.

Challenge Yourself!

Open the Demo Database NAV (6-0) database in restricted user mode. Use the SQL Server Import and Export Wizard to move the Customer data from the Test Database NAV (6-0) to the Demo Database NAV (6-0) database. Check the data and remove the restricted user mode flag.

Need a Little Help?

1. Open the Demo Database NAV (6-0) database in restricted user mode.

2. Execute the SQL Server Import and Export Wizard. 3. Select the Customer table in Demo Database NAV (6-0). 4. Remove the restricted user mode flag.

Open the Demo Database NAV (6-0) Database in Restricted-user Mode

1. Open Microsoft Dynamics NAV 2009 Classic client. 2. In the File menu, select Database, Information to open the

Database Information window. 3. On the Sessions tab, check that the Current Sessions field displays

1. 4. Exit the Microsoft Dynamics NAV Classic client. 5. Open SQL Server Management Studio. 6. Connect to the Database Engine.



3-39

7. Click the Activity Monitor button in the menu bar or press Ctrl+Alt+A to open the Activity Monitor window.

8. Double-click the Processes tab to see a list of the active SQL Server processes.

9. In the Application Name column, check for Microsoft Dynamics NAV Classic client processes. The session information that you see here corresponds to the information displayed in the Database Information and Database Sessions window. If Microsoft Dynamics NAV Classic client processes appear, it means that there are active users connected to the database. In that case, the Login column contains the user who opened the session. Contact the user and ask the user to exit Microsoft Dynamics NAV. Eventually, you can terminate a session by right-clicking the session, then selecting Kill Process. Note that killing a process should only be done in emergency cases. Always verify the current user's activity before you kill the process.

10. When no Microsoft Dynamics NAV Classic client processes are active, close Activity Monitor.

11. Click the New query button to open a new query window. 12. In the query window, enter the following command.

ALTER DATABASE [Demo Database NAV (6-0)] SET RESTRICTED_USER WITH NO_WAIT

13. Click the Execute button.

Execute the SQL Server Import and Export Wizard

1. In the Object Explorer, select the Demo Database NAV (6-0) database.

2. Right-click the database and select Tasks > Import Data. The SQL Server Import and Export Wizard will appear.

3. On the Welcome page, click Next. 4. On the Choose a Data Source page, select SQL Server Native

Client 10.0 as Data source. 5. In the Server Name field, enter NAV-SRV-01. 6. Select Windows Authentication. 7. In Database, select Test Database NAV (6-0) from the drop-down

list. 8. Click the Next button. 9. On the Choose a Destination page, select SQL Server Native

Client 10.0 as Data source. 10. In the Server Name field, enter NAV-SRV-01. 11. Select Windows Authentication.



3-40

12. In Database, select Demo Database NAV (6-0) from the drop-down list.

13. Click the Next button. 14. On the Specify Table Copy or Query page, select the Write a

query to specify the data to transfer option. 15. Click the Next button. 16. On the Provide a Source Query page, enter the following SQL

statement:

SELECT [No_],[Name],[Search Name],[Name 2],[Address 2], [Address],[City],[Contact],[Phone No_],[Telex No_], [Our Account No_],[Territory Code], [Global Dimension 1 Code],[Global Dimension 2 Code], [Chain Name],[Budgeted Amount],[Credit Limit (LCY)], [Customer Posting Group],[Currency Code], [Customer Price Group],[Language Code], [Statistics Group],[Payment Terms Code], [Fin_ Charge Terms Code],[Salesperson Code], [Shipment Method Code],[Shipping Agent Code], [Place of Export],[Invoice Disc_ Code], [Customer Disc_ Group],[Country_Region Code], [Collection Method],[Amount],[Blocked],[County], [Invoice Copies],[Last Statement No_],[Priority], [Print Statements],[Bill-to Customer No_], [Payment Method Code],[Last Date Modified], [Application Method],[Prices Including VAT], [Location Code],[Fax No_],[Telex Answer Back], [VAT Registration No_],[Combine Shipments], [Gen_ Bus_ Posting Group],[Picture],[Post Code], [E-Mail],[Home Page],[Reminder Terms Code], [No_ Series],[Tax Area Code],[Tax Liable], [VAT Bus_ Posting Group],[Service Zone Code], [Block Payment Tolerance],[IC Partner Code], [Prepayment %],[Primary Contact No_], [Responsibility Center],[Shipping Advice], [Shipping Time],[Shipping Agent Service Code], [Reserve],[Allow Line Disc_],[Base Calendar Code], [Copy Sell-to Addr_ to Qte From] FROM [Test Database NAV (6-0)].[dbo].[CRONUS International Ltd_$Customer]

You can use the Parse button to check the syntax of your query. 17. Click the Next button. 18. On the Select Source Table and Views page, in the Destination

column, select [dbo].[CRONUS International Ltd_$Customer]. Optionally, you can click the Edit Mappings button to check the field mappings in the tables.

19. Click the Next button.



3-41

20. On the Review Data Type Mapping page, click the Next button. 21. On the Save and Run Package page, you can choose to Run the

package immediately and/or Save the SSIS package. Select the Run Immediately option. The Save SSIS package option allows you to save the query (either in SQL Server or on the File system), so you can rerun the package afterwards. (You can run the package manually or schedule the SSIS package through the SQL Server Agent.)

22. Click the Next button. 23. On the Complete the Wizard page, click the Finish button.

The package is executed and the Customer data is transferred to the Demo Database NAV (6-0) database. After the package has run, a status window with the execution results is shown.

FIGURE 3.15 SQL SERVER IMPORT AND EXPORT WIZARD



3-42

Check the Customer Table in Demo Database NAV (6-0)

1. Open SQL Server Management Studio. 2. Click the New Query button to open a new query window. 3. In the New Query window, enter the following SQL statement

SELECT * FROM [Demo Database NAV (6-0)].[dbo].[CRONUS International Ltd_$Customer]


Remove the Restricted User Mode Flag

1. Open SQL Server Management Studio. 2. Connect to the NAV-SRV-01 Database Engine. 3. Click the New Query button. 4. In the new query window, enter the following SQL statement:

ALTER DATABASE [Demo Database NAV (6-0)] SET MULTI_USER WITH NO_WAIT




3-43

Quick Interaction: Lessons Learned Take a moment and write down three Key Points you have learned from this chapter

1.

2.

3.



3-44

Solutions Test Your Knowledge

1. Which recovery model is required to enable point-in-time recovery? (Select all that apply)

( ) Simple (√) Bulk-Logged (√) Full ( ) All of the above

2. Which backup strategy allows point-in-time recovery? (Select all that apply)

( ) Full Backup Strategy (√) Database and Transaction Log Backup Strategy ( ) File or Filegroup Backup Strategy (√) Differential Backup Strategy, combined with Transaction Log

Backups

3. What is true about SQL Server Native Client ODBC driver?

( ) SQL Server Native Client ODBC driver is installed automatically with the client.

(•) SQL Server Native Client ODBC driver can write to the database. ( ) SQL Server Native Client ODBC driver ensures data consistency and

validation by firing C/AL code triggers. ( ) SQL Server Native Client ODBC driver can be used to access Classic

database and SQL Server database.

4. Which tools can be used to monitor performance on a classic database? (Select all that apply)

(√) Client Monitor (√) Session Monitor ( ) Performance Data Collector (√) Perfmon



3-45

5. What are Dynamic Management Views and Functions used for and how can you use them?

MODEL ANSWER:

Dynamic management views (DMV) and functions (DMF) were introduced as a new feature in SQL Server 2005. They return server state information that can be used to monitor the health of a server instance, diagnose problems, and tune performance. Dynamic Management Views All dynamic management views and functions exist in the sys schema and follow this naming convention: dm_*. Dynamic management views can be referenced in Transact-SQL statements by using two-part, three-part, or four-part names. Dynamic management functions on the other hand can be referenced in Transact-SQL statements by using either two-part or three-part names.

6. One of your customers wants to upgrade to Microsoft Dynamics NAV 2009. You have calculated the initial size of the database to be 110 GB, with an expected annual growth of 20%. Which server option will you recommend and why?

MODEL ANSWER:

Given the initial database size and the expected growth, SQL Server option offers better opportunities for future growth. The maximum database size with Classic database server is 132 GB, while SQL Server can scale out to bigger databases. If you recommend Classic database server, the maximum database size limit will be reached after one year already and the customer will have to switch to the SQL Server Option.



3-46


na2009 enus sql_03

Technology

differential backup

microsoft dynamics nav

microsoft sqlserver

filegroup backup

thetype of backup

active transaction log

sql server installation

server options