Showing posts with label SQL Server. Show all posts
Showing posts with label SQL Server. Show all posts

Comments in T-SQL SQL Server 2008 2012 with examples


Examples of Comments in T-SQL SQL Server 2008 2012 

  1. In this article i will explain the types of comments in SQL Server Programming in SQL Server 20012 or 2008
  2. Basically there are two types of commenting syntax that are widely used in SQL Programming which are described as follows
  • Block Comments
  • In-Line Comments
let us now see each comment pattern with examples
Block Comments
  1. Block comments are typically used at the beginning of a T-SQL code to provide an explanation about the purpose of the code.
  2. The following example contains a block comment that describes the purpose of the T-SQL code. Comments are enclosed within the /* and */ elements.
Example:
/* The purpose of the Transact-SQL 
statement below is to retrieve the 
Firstname and Lastname of StudentID 1 */

USE Adventureworks
GO
SELECT Firstname, Lastname
FROM students
WHERE StudentID = 1


In-Line Comments
  1. In-line comments are added within the T-SQL code to add descriptive comments to portions of the code.
  2. In-line comments begin with -- (two hyphens). Any characters to the right of this are commented out on the line where the -- are placed, and are excluded from the T-SQL statement. Comments inserted with -- are terminated by the newline character.
  3. Additional elements can also be used to add flexibility and logic to any T-SQL statements. These elements can add dynamic capabilities to your statements and logic, and provide you with the ability to create powerful T-SQL statements
  4. The following is an example of an in-line comment within a T-SQL statement.
Example:
USE Adventureworks
GO
SELECT Firstname, Lastname 
FROM students
WHERE StudentID = 1 -- Only StudentID one is returned

Star Snowflake Normalised and Hybrid Schema in BI Datawarehouse SQL Server 2008 2012


Data Warehouse Structures normalised,star,snowflake,hybrid schema


  1. In this article i will explain the different schemas for datawarehouses with SQL Server 2012 2008 such as normalised schema,star schema,snowflake schema,hybrid schema 
  2. Data warehouse structures are hosted as tables within the database engine of SQL Server 2008 and 2012.
  3. There are different data warehouse schemas that can be implemented when creating a data warehouse as outlined in the table below.

Normalised schema

  1. Normalisation is the process of organising data and tables within the SQL Server database. 
  2. This is implemented by creating tables and setting relationships between the tables to remove repetitive and redundant data.
  3. Transactional systems typically contain tables that are structured in a normalised manner. 
  4. The idea is that it is easier to make modifications to the data. However, this means that retrieving the data is not as efficient.

Star schema

  1. A star schema describes the layout of the fact tables and the dimension tables within a data mart.
  2. In a star schema, the fact table resides at the centre of the data mart. 
  3. There are dimension tables that have a direct join with the fact table.

Snowflake schema

  1. Within a snowflake schema, the fact table resides at the centre of a data mart. 
  2. Some dimension table have a direct relationship to the fact table.
  3.  However, there are dimension tables that have a direct relationship with the fact table, but have another relationship to another table. 
  4. hese relationships can also extend to further tables as well.
  5. An example of this can be related to a data mart about a products business entity.
  6.  In this example, you have a one-dimension table that lists columns about the product including colour, size, category and subcategory. 
  7. If you have 10,000 products spread across 4 categories and 25 subcategories, it is more efficient to store the subcategory information within a separate table with one record for each subcategory and relate this to a separate category table.
  8. Rather than repeating the same information many times within a single dimension table to unnecessarily increase the size of the dimension table, it is more efficient to store this information in separate tables.

Hybrid schema

  1. A hybrid schema is a data warehouse structure that combines star schema structures and snowflake schemas.
  2. As additional data marts are added to a data warehouse, the schema of the entire data warehouse hosts a combination of the star and snowflake schema to store the data efficiently within the data warehouse for each data mart.
  3. Dimension tables may also be shared across different data marts to provide data consistency

Difference between Table Variables and Temporary Tables


Difference between Table Variables and Temporary Tables 

In this article i will explain the difference between table variables and temporary tables in sql server 2005/2008/2012

Feature
Table Variables
Temporary Tables
Scope
Current batch
Current session, nested stored procedures. Global: all sessions.
Creation
DECLARE statement only.
CREATE TABLE statement.
SELECT INTO statement.                    
Indexes
Can only have indexes that are automatically created with PRIMARY KEY & UNIQUE constraints as part of the DECLARE statement.
Indexes can be added after the table has been created.
Constraints
PRIMARY KEY, UNIQUE, NULL, CHECK, but they must be incorporated with the creation of the table in the DECLARE statement. FOREIGN KEY not allowed.
PRIMARY KEY, UNIQUE, NULL, CHECK. Can be part of the CREATE TABLE statement, or can be added after the table has been created. FOREIGN KEY not allowed.
Insert explicit values into identity columns (SET IDENTITY_INSERT).
The SET IDENTITY_INSERT statement is not supported.
The SET IDENTITY_INSERT statement is supported.
Truncate table
Not allowed.
Allowed.
Destruction
Automatically at the end of the batch.
Explicitly with DROP TABLE statement. Automatically when session ends. (Global: also when other sessions have no statements using table.)
Rollbacks
Not affected (Data not rolled back).
Affected (Data is rolled back).
Dynamic SQL
Must declare table variable inside the dynamic SQL.
Can use temporary tables created prior to calling the dynamic sql.
Usage
UDFs, Stored Procedures, Triggers, Batches.
Stored Procedures, Triggers, Batches.
Statistics
Optimizer cannot create any statistics on columns, so it treats table variable has having 1 record when creating execution plans.
Optimizer can create statistics on columns. Uses actual row count for generation execution plan.
Pass to stored procedures
SQL 2008 only, with predefined user-defined table type.
Not allowed to pass, but they are still in scope to nested procedures.
Explicitly named objects (indexes, constraints).
Not allowed.
Allowed, but be aware of multi-user issues.
Transactions
Last only for length of update against the table variable. Uses less than temporary tables.
Last for the length of the transaction. Uses more than table variables.
Stored procedure recompilations
Not applicable.
Creating temp table and data inserts cause procedure recompilations.
Table name
Maximum 128 characters.
Maximum 116 characters.
Column data types
Can use user-defined data types.
Can use XML collections.
User-defined data types and XML collections must be in tempdb to use.
Collation
String columns inherit collation from current database.
String columns inherit collation from tempdb database.
Post-creation DDL (indexes, columns)
Statements are not allowed.
Statements are allowed.
Data insertion
INSERT statement (SQL 2000: cannot use INSERT/EXEC).
INSERT statement, including INSERT/EXEC.
SELECT INTO statement.

SSAS Synchronize Databases by Using the Database Wizard in Analysis services 2008 2012



SSAS How to Synchronize Databases by Using the Database Wizard in Analysis services 2008 2012



  1. The Synchronize Database Wizard synchronises one way to a database on a separate instance of Analysis Services. 
  2. This can be useful when maintaining the same Analysis Services database on two separate versions of SQL Server and can help with the migration from Analysis Services 2005 to Analysis Services 2008 and . 
  3. If the database does not exist on the instance, it will create the database automatically.
  4. To access the Synchronize Database Wizard, open SQL Server Management Studio, in Object Explorer, right-click the database, and then click Synchronize.
  5. The wizard prompts you to perform the following steps:
  • Select the Analysis Services source instance and database from which to synchronise.
  • Select storage locations for local partitions on the destination instance.
  • Select storage locations for remote partitions on other destination instances.
  • Select the level of security and membership information to copy from the source instance and database to the destination instance.
  • Select whether to synchronise immediately or to save the XMLASynchronize command generated by the Synchronize Database Wizard to a script file for later synchronisation.
After following the above steps the Synchronize Databases task in ssas 2008 and 2012 will be completed 

SSAS Deploying Analysis Services in SQL Server 2008 and 2012



In this tutorial example i will explain the following deployment methods in SSAS 2008 2012 analysis services 
  1. Business Intelligence Development Studio
  2. Deployment Wizard
  3. XMLA Scripts
  4. Synchronize Database Wizard
  5. Backup and Restore
  6. Analysis Management Objects (AMO)
SSAS 2008 2012 Analysis Services Deployment Introduction
  1. Deploying Analysis Services can be performed through many methods. 
  2. Understanding the capability of each method will help you to determine the most effective deployment method to employ within your organization.
Analysis Services provides a number of methods to deploy Analysis Services objects. The following table describes the different methods available to perform a deployment.

1.Business Intelligence Development Studio
  1. Business Intelligence Development Studio is one method that can be used to deploy an Analysis Services project. 
  2. This method will prove useful as you develop your Analysis Services solutions to test the functionality of the solution. 
  3. This method builds a complete set of XML files in the output folder containing all of the necessary commands required to build all of the Analysis Services database objects in the project. 
  4. It will also validate the objects that are deployed.
  5. Prior to deploying the solution, you can configure a number of deployment options within the properties of the Analysis Services solution specific to the deployment.
  6.  These options can be accessed by right-clicking an Analysis Services project in Solution Explorer, and then clicking Properties. 
  7. Within the project Properties, click the Deployment page and configure the following settings:
  • Process Options. Determines whether the cube is process as it is deployed.
  • Transactional Deployment. Determines if the deployment is transactional and rolls back the deployment should it fail.
  • Deployment Mode. Specifies if all of the Analysis Services objects are deployed or only the changes are deployed.
  • Server. The name of the server to which the Analysis Services solution is deployed.
  • Database. The name of the database in which the Analysis Services solution is deployed.
2. Deployment Wizard
  1. The Deployment Wizard is a very useful feature for those database professionals who do not work within Business Intelligence Development Studio but need to deploy the Analysis Services solution. 
  2. This can include situations where a company’s infrastructure team is responsible for the deployment of the Analysis Services solution to the production SQL Server.
  3. The Deployment Wizard uses the XML files in the Output folder that has been created from within Business Intelligence Development Studio as the basis for the deployment.
  4. At the end of the wizard, you also have the option to generate an XMLA script of the Analysis Services objects and the deployment options that have been defined in the Deployment Wizard. 
  5. The Deployment Wizard can be run both interactively and at the command prompt.
  6. To access the Deployment Wizard interactively, click Start, point to All Programs, click Microsoft SQL Server 2008, point to Analysis Services, and then click Deployment Wizard.
The wizard consists of the following screens:
  • The wizard will first require the location of the *.asdatabase file, which, by default, is located in the bin folder of the Analysis Services project.
  • You are then prompted to specify the Server and database name of the Analysis Services database.
  • The third screen allows you to define any partitioning and security options that will be set as the cube is deployed.
  • You can then define properties for the components of the cube including configuration and optimisation settings.
  • The next screen allows you to specify the processing mode and whether the deployment is transactional.
  • The penultimate screen allows you to specify if you wish to generate a deployment script.
  • The final screen will start and complete the deployment.
Files used in the deployment of Analysis Services
When you build an Analysis Services project, Business Intelligence Development Studio generates XML files for the project. Business Intelligence Development Studio puts these XML files in the Output folder of the Analysis Services project. By default, output is out in the \bin folder. The following table lists the XML files that Business Intelligence Development Studio creates:
XMLA file

Description

<project name>.asdatabase
Contains the declarative definitions for all the Analysis Services objects in the project.
<project name>.deploymenttargets
Contains the name of the Analysis Services instance and database in which the Analysis Services objects will be created.
<project name>.configsettings
Contains environment specific settings, such as data source connection information and object storage locations. Settings in this file override settings in the <project name>.asdatabase file.
<project name>.deploymentoptions
Contains deployment options, such as whether deployment is transactional and whether deployed objects should be processed after deployment.

3. XMLA Scripts
  1. XMLA scripts can be generated by using the Deployment Wizard that allows you to execute the script in SQL Server Management Studio, to recreate the database objects, which are defined within the script file.
  2. The XMLA script consists of settings that are used to create the Analysis Services objects. It also consists of the settings required to process the Analysis Services database and the objects found in the script.
  3. You can edit the XMLA script to add custom object through the XMLA language. This can be performed in any editor.
  4.  However, SQL Server Management Studio is a useful platform for making such changes, because the script is colour-coded and can be executed from within it to create the objects.
  5. After you have the XMLA script in a saved file, you can easily run the script according to a schedule, or embed the script in an application that connects directly to an instance of Analysis Services. 
  6. Furthermore, after running the script and deploying the database, the newly created database must be processed before users can browse it.
  7. The XMLA script does not contain a password. If a password is specified in either the connection string for a data source or for impersonation purposes, you must add the password manually to the script before it executes or add it after the script executes.
4.Synchronize Database Wizard
  1. The Synchronize Database Wizard helps you to synchronize an Analysis Services database to another instance of SQL Server.
  2. This synchronization is one-way and cannot be performed on the same instance of Analysis Services.
  3. While the wizard synchronizes the data between the two databases, users can continue to query the destination database. 
  4. After synchronization finishes, Analysis Services automatically switches the users to the newly copied data and metadata, and drops the old data from the destination database.
5.Backup and Restore
  1. Analysis Services contains its own backup and restore utility.
  2. Using this method, you can back up an Analysis Services database and restore the database to a separate instance of Analysis Services.
6.Analysis Management Objects (AMO)
  1. AMO provides a programmatic interface to the complete command set for Analysis Services available to the developer. 
  2. Therefore, AMO can be used for deployment and also for the many administrative commands it otherwise supports.