Beruflich Dokumente
Kultur Dokumente
Table of Contents
Recovery Models:........................................................................................................................................2
Simple Recovery Model:..........................................................................................................................2
Full recovery Model:................................................................................................................................2
Bulk-Logged:............................................................................................................................................2
Back-ups......................................................................................................................................................2
Back-up Scopes:.......................................................................................................................................2
A) Database backups:.......................................................................................................................2
B) Partial Back-ups:..........................................................................................................................2
C) File Back-ups:...............................................................................................................................2
Back-Up Types.............................................................................................................................................2
A) Full Backups:....................................................................................................................................2
B) Differential backups:........................................................................................................................2
SQL SERVER REPLICATION...........................................................................................................................2
A) Load Balancing:................................................................................................................................2
B) Offline Processing:...........................................................................................................................2
C) Redundancy:....................................................................................................................................2
A) Publishers........................................................................................................................................2
B) Subscribers......................................................................................................................................2
A) Snapshot Replication:......................................................................................................................2
B) Transactional Replication:................................................................................................................2
C) Merge Replication:..........................................................................................................................2
A) Express edition................................................................................................................................2
B) Workgroup edition..........................................................................................................................2
C) Standard edition..............................................................................................................................2
D) Enterprise edition............................................................................................................................2
Difference between Temp tables and Table variables in SQL Server...........................................................2
Suggestion for choosing between these two:..........................................................................................2
Stored Procedures.......................................................................................................................................2
Advantages of Stored Procedures:..........................................................................................................2
Recovery Models:
There are 3 recovery Models in SQL Server.
1) Simple
2) Full
3) Bulk-Logged
Simple Recovery Model: Simple recovery model allows you to recover data only to the most
recent full database or differential back-up. Transaction log back-ups are not available because the
contents of the transaction log are truncated each time a checkpoint is issued for the database.
Or
In databases using simple recovery model, you may restore full or differential back-up only. It is not
possible to restore such a database to a given point in time; you may only restore it to the exact time
when a full or differential back-up occurred. Therefore, you will automatically lose any data
modifications made between the time of the most recent full/differential back-up and the time of
failure.
Full recovery Model: Full recovery model uses database back-ups and transaction log back-ups to
provide complete protection against failure. Along with being able to restore a full or differential back-
up, you can recover the database to the point of failure or to a specific point in time. All operations,
including bulk operations such as SELECT INTO, CREATE INDEX and bulk-loading data, are fully logged
and recoverable.
Or
Full Recovery model also bears a self-descriptive name. In this model, SQL Server preserves the
transaction log until you back it up. This allows you to design a disaster back-up in conjunction with
transaction log back-ups.
In the event of a database failure, you have the most flexibility restoring databases using the full
recovery model. In addition to preserving data modifications stored in the transaction log, the full
recovery model allows you to restore a database to a specific point in time. For example, if an erroneous
modification corrupted your data at 2:36 Am on Monday, you could use SQL Server’s point in time to
restore to roll your database back to 2:35 AM, wiping out the effects of the recovery.
Bulk-Logged: Bulk-logged recovery model provides protection against failure combined with the
best performance. In order to get better performance, the following operations are minimally logged
and not fully recoverable: SELECT INTO, bulk load operations.
Or
Bulk recovery model is a special-purpose model that works in a similar manner to the full recovery
model. The only difference is in the way it handles bulk data modification operations. The bulk-logged
model records these operations in the transaction log using a technical known as minimal logging. This
saves significantly on processing time, but prevents you from using point-in-time restore option.
Microsoft recommends that the bulk-logged recovery model only be used for short periods of time. Best
practice dictates that you switch a database to the bulk-logged recovery model immediately before
conducting bulk operations and restore it to the full recovery model when those operations complete.
In this article, we explore the process of backing up data with Microsoft SQL Server. When you create a
backup plan, you will need to create an appropriate mix of backups with varying[em] backup
scopes[/em] and [em]backup types[/em] that meet the recovery objectives of your organization and are
suitable for your technical environment.
Back-up Scopes: The scope of a back-up defines the portion of the database covered by the
backup. It defines the database, file and or file-group that SQL Server will backup. There are three
different types of back-up scope available in Microsoft SQL Server:
A) Database backups: These cover the entire database including all structural schema
information, the entire data contents of the database and any portion of the transaction log
necessary to restore the database from scratch to its state at the time of the backup. Database
backups are the simplest way to restore your data in the event of a disaster, but they consume a
large amount of disk space and time to complete.
B) Partial Back-ups: These are good alternatives to database back-ups for very large
databases that contain significant quantities of read-only data. If you have read-only file-groups
in your database, it probably doesn’t make sense to back them up frequently, as they do not
change. Therefore, the scope of a partial back-up includes all files in the primary file-group; all
read/write file-groups, and any read-only file- groups that you explicitly specify.
C) File Back-ups: This allows you to individually back-up files and/or file-groups from your
database. They may be used to complement partial back-ups by creating one-time-only backups
of your read-only file-groups. They may also play a role in complex back-up models.
Back-Up Types
The second decision you need to make when planning a SQL Server database backup model is the type
each backup included in your plan. The backup type describes the temporal coverage of the database
backup. SQL Server supports two different back-up types:
A) Full Backups: This includes all data within the backup scope. For example, a full database
backup will include all data in the database, regardless of when it was last created for modified.
Similarly, a full partial backup will include the entire contents of every file and file-group within
in the scope of the partial backup.
B) Differential backups: This includes only the portion of data that had changed since the
last full backup. For example, if you perform a full database backup on Monday morning and
then perform a differential backup on Monday evening, the differential backup will be a much
You should keep in mind that the scope and type of a backup are two independent decisions made
when creating your backup plan. As described above, each type and scope allows you to customize
the amount of data included in the backup and, therefore, the amounts of time required to backup
and restore the database in the event of a disaster.
A) Load Balancing: Replication allows you to disseminate your data to a number of servers
and then distribute the query load among those servers.
B) Offline Processing: you may wish to manipulate data from your database on a machine
that is not always connected to the network.
C) Redundancy: Replication allows you to build a fail-over database server that’s ready to pick
up the processing load at a moment’s notice.
A) Publishers have data to offer to the other servers. Any given replication scheme may have
one or more publishers.
B) Subscribers are database servers that wish to receive updates from the publisher when the
data is modified
There’s nothing preventing a single system from acting both of these capabilities. In fact, this is often
done in large-scale distributed database systems. Microsoft SQL Server supports three types of database
replication. They are
A) Snapshot Replication: It acts in the manner its name implies. The publisher simply takes a
snapshot of the entire replicated database and shares it with the subscribers. Of course, this is a
very time and resource-intensive process. For this reason, most administrators don’t use
snapshot replication on a recurring basis for databases that change frequently. There are two
scenarios where snapshot replication is commonly used. First, it is used for databases that rarely
change. Second, it is used to set a baseline to establish replication between systems while future
updates are propagated using transactional or merge replication.
B) Transactional Replication: This offers a more flexible solution for databases that
change on a regular basis. With transactional replication, the replication agent monitors the
publisher for changes to the database and transmits those changes to the subscribers. This
transmission can take place immediately or on a periodic basis.
Each one of these replication techniques serves a useful purpose and is well-suited to particular
database scenarios.
If you are working with SQL Server 2005, you’ll need to choose your edition based upon your
replication needs. Each edition has differing capabilities.
As you have undoubtedly recognized by this point, SQL Server’s replication capabilities offer
database administrators a powerful tool for managing and scaling databases in an enterprise
environment.
Stored Procedures
A stored Procedure is a group of SQL statements that form a logical unit and perform a particular
task. Stored procedures are used to encapsulate a set of operations or queries to execute on a
database server. For example, operations on an employee database (hire, fire, promote, lookup)
could be coded as stored procedure executed by application code. Stored procedures can be
compiled and executed with different parameters and results, and they may have any combination
of input, output, and input/output parameters.
A) Reusing code from one program to another, cutting down on program development time
B) Hiding the SQL details, allowing database developers to worry about SQL and application
developers to deal only in higher-level languages
C) Centralize maintenance, allowing you to make business logic changes in a single place that
automatically affect all dependent applications
At first glance, functions and stored procedures seem identical. However, there are several subtle, yet
important differences between the two:
A) Stored procedures are called independently, using the EXEC command, while functions are
called from within another SQL statement
B) Stored procedures allow you to enhance application security by granting users and applications
permission to use stored procedures, rather than permission to access the underlying tables.
Stored procedures provide the ability to restrict user actions at a much more granular level than
standard SQL Server permissions. For example if you have an inventory table that cashiers must
update each time an item is sold (to decrement the inventory for that item by 1 unit), you can
grant cashiers permissions to use a decrement item stored procedure, rather than allowing
them to make arbitrary changes to the inventory table.
C) Functions always must return a value (either a scalar value or a table). Stored procedures may
return a scalar value, a table value or nothing at all.
Overall, stored procedures are one of the greatest treasures available to SQL Server developers. The
efficiency and security benefits are well worth the upfront investment in time.
SSAS
Different Dimension types by Microsoft available in Analysis Services
1) Regular
2) Time
3) Organization
4) Geography
5) Bill of Materials
6) Accounts
7) Customers
8) Products
9) Scenario
10) Quantitative
Regular: A dimension whose type has not been set to a special dimension type
Time: A dimension whose attributes represents time periods, such as years, semesters, quarters,
months and days
Geography: A dimension whose attribute represents geographic information, such as cities or postal
codes
Accounts: A dimension whose attributes represent a chart of accounts for financial reporting
purposes
Junked Dimension: When you consolidate lots of small dimensions and instead of having 100s
of small dimensions, that will have few records in them, cluttering your database with these mini
identifier tables, all records from all these small dimension tables are loaded into ONE dimension
table and we call this dimension table as JUNK dimension table. (Since we are storing all the Junk in
this one table) For example a company might have handful of manufacture plants, handful of order
types, and so on, so forth, and we can consolidate them into one dimension table called Junk
dimension table
Degenerated Dimension: An item that is in the fact table but is stripped off of its
description, because the description belongs in dimension table, is referred to as Degenerated
Dimension. Since it looks like dimension, but is really in fact table and has been degenerated of its
description, hence is called as Degenerated Dimension.
Slowly Changing Dimensions: These dimensions are those where key value will remain
static but description might change over the period of time
There are 10 types of dimension Tables (This is not the case in most of the instances)
1) Primary Dimensions
2) Secondary Dimensions
3) Degenerate Dimensions
4) Confirmed Dimensions
5) Slowly Changing Dimensions
6) Rapidly Changing Dimensions
7) Large Dimensions
8) Rapidly Changing Monster Dimensions
9) Junk Dimensions
10) Role-Playing Dimensions
Answer - Temporary Stored Procedure is stored in Tempdb database. It is volatile and is deleted once
connection gets terminated or server is restarted......
Some common problems with these large reports are that they contain data fields that are not used in
the report or they contain duplicate datasets. Often users retrieve more data than they really need. To
significantly reduce the load placed on your Reporting Services environment, create summary reports
that use aggregates created at the data source, and include only the necessary columns,. If you want to
provide data feeds, you can do this asynchronously using more appropriate tools such as SSIS, to provide
the data feed.
If you have large reports that create data processing bottle-necks, you can mitigate resource contention
issues by using Scheduled Snapshots. Instead of the report data itself, a regularly scheduled report
execution snapshot is used to render the report. The scheduled snapshot can be executed during off-
peak hours, leaving more resources available for live reports for users during peak hours.
Buffers:
A buffer is an in-memory dataset object utilized by the data flow engine to transform data. The
data flow task has a configurable property called “DefaultMaxBufferSize”, which is set to 10,000
by default. Data-flow task also has a configurable property called “DefaultBufferSize”, which is
set to 10 MB by default. Additionally, data-flow task has a property called “MaxBufferSize”,
which is set to 100 MB and cannot be changed.
Buffer Sizing:
When performance tuning a data-flow task, the goal should be to pass as many records as
possible through a single buffer while efficiently utilizing memory. This begs the question: what
does “efficiently utilizing memory” mean? SSIS estimates the size of a buffer row by calculating
the data source meta-data at design time. Optimally, the buffer row size should be as small as
possible, which can be accomplished by employing the smallest possible data-type for each
column. SSIS automatically multiplies the estimated buffer row size by the
“DefaultMaxBufferRows” setting to determine how much memory to allocate to each buffer in
the data-flow engine. If this amount of memory exceeds Max Buffer Size100 MB, SSIS
Data-flow task has another property called “MinBufferSize”, which is 64 KB and cannot be
changed. If the amount of memory estimated by SSIS to be allocated for each buffer is below 64
KB, SSIS will automatically increase the number of buffer rows per buffer in order to exceed
MinBufferSize memory boundary.
Buffer Tuning:
Data-flow task has a property called “BufferSizeTuning”. When the value of this property is set
to true, SSIS will add information to the SSIS log indicating where SSIS had adjusted the buffer
size. While buffer tuning, the goal should be to fit as many rows into buffer as possible. Thus, the
value for “DefaultMaxBufferRows” should be as large as possible without exceeding a total
buffer size of 100 MB.
Parallelism:
SSIS natively supports the parallel execution of packages, tasks and transformations. Therefore,
parallelism can greatly improve the performance of a package when it is configures with-in the
constraints of system resources. A package has a property called “MaxConcurrentExecutables”,
which can be configured to set the maximum number of threads that can execute in parallel per
package. By default this is set to -1, which translates to the number of logical machine
processors plus 2. All or some of the operations in a package can execute in parallel.
Additionally, data-flow task has a property called “EngineThreads”, which defines how many
threads the data-flow engine can create and run in parallel. This property applies equally to both
the source threads that the data flow engine creates for sources and the worker threads that
the engine creates for transformations and destinations. For example, setting the EngineThreads
property to 10 indicates that the data-flow engine can create upto 10 source threads and 10
worker threads.
Extraction Tuning
a) Increase the connection manager’s packet size property: Use separate connection
managers for bulk loading and smaller packet size for ole-db command transformations
b) Affinitize network connections: this can be accomplished if a machine has multiple
cores and multiple NICs.
c) Tune Queries:
--Select only needed columns
--Use a hint to specify that no shared locks be used during the select (query can potentially
read uncommitted data). Used only if the query must have the best performance
d) Look-ups
-- Select only needed columns
-- Use the “Shared Look-up Cache” (available in 2008)
Look-up
In 2005 for Error Output look-ups had only 3 options Fail Component, Ignore Failure and Re-direct row.
But in 2008 it has an additional feature “No match Out-Put”
In 2005 it did not had the Cache mode, while 2008 has 3 different Cache modes Full Cache, Partial Cache
and No Cache
2005 didn’t have the Connection Manager types while 2008 has OLE DB Connection Manager and Cache
Connection Manager
Cache Transformation
2005 did not have this transformation; it is introduced in 2008 version. This is a Data-flow
transformation. Cache transformation writes data from a connected data source in the data-flow to a
Cache Connection Manager. The Look-up transformation in a package performs lookups on the data
In a single package, only one Cache Transformation can write data to the same Connection Manager. If
the package contains multiple Cache transforms, then first Cache transform that are called when the
package runs, writes the data to the connection manager. The write operations of subsequent cache
transforms fail.
Configuring of the Cache can be made in the following way
1) Specify the connection manager
2) Map the input columns in the cache transform to destination columns in the Cache
connection manager