uCertify Articles » MCITP http://www.ucertify.com/article Just another WordPress weblog Wed, 04 Nov 2009 00:00:00 +0000 http://wordpress.org/?v=2.8.4 en hourly 1 What are the conditions under which a function can be schema bound? http://www.ucertify.com/article/what-are-the-conditions-under-which-a-function-can-be-schema-bound-2.html http://www.ucertify.com/article/what-are-the-conditions-under-which-a-function-can-be-schema-bound-2.html#comments Wed, 04 Nov 2009 00:00:00 +0000 uCertify 100033

A function can be schema bound only if the following conditions are true:

  • The function is a Transact-SQL function.
  • The user-defined functions and the views it references are also schema-bound.
  • The objects that the function references are referenced using a two-part name.
  • The function and the objects it references belong to the same database.
  • The user who executed the CREATE FUNCTION statement has REFERENCES permission on the database objects that the function references.
  • SCHEMABINDING cannot be specified for functions that reference alias data types or CLR functions.
Share/Bookmark]]> http://www.ucertify.com/article/what-are-the-conditions-under-which-a-function-can-be-schema-bound-2.html/feed 0 What are non-equijoins? http://www.ucertify.com/article/what-are-non-equijoins-2.html http://www.ucertify.com/article/what-are-non-equijoins-2.html#comments Wed, 04 Nov 2009 00:00:00 +0000 uCertify 100022

Non-equijoins are used to return the result from two or more tables where exact join is not possible.

Example:

There are two tables: EMP and SALGRADE. The SALGRADE table contains the grade of employees. It also contains the minimum and maximum salaries for all grades. Suppose there arises a need to find the grade of employees based on their salaries, then a NON EQUI join can be used as follows:

SELECT E.EMPNO, E.ENAME, E.SAL, S.GRADE
FROM EMP E, SALGRADE S
WHERE E.SAL BETWEEN S.LOWSAL AND S.HISAL;

Share/Bookmark]]> http://www.ucertify.com/article/what-are-non-equijoins-2.html/feed 0 What is an explicit transaction? http://www.ucertify.com/article/what-is-an-explicit-transaction_100038-2.html http://www.ucertify.com/article/what-is-an-explicit-transaction_100038-2.html#comments Tue, 03 Nov 2009 00:00:00 +0000 uCertify 100038

An explicit transaction is one in which a user explicitly defines the beginning and end of the transaction. They are typically defined within the stored procedures. Explicit transactions begin with the BEGIN TRANSACTION statement and end with the COMMIT TRANSACTION or the ROLLBACK TRANSACTION statement. Once a transaction is committed, SQL Server ensures that the data is written to the database even in case of server failure.

Share/Bookmark]]> http://www.ucertify.com/article/what-is-an-explicit-transaction_100038-2.html/feed 0 What is 802.11g? http://www.ucertify.com/article/what-is-80211g.html http://www.ucertify.com/article/what-is-80211g.html#comments Wed, 28 Oct 2009 00:00:00 +0000 uCertify 1401425

The 802.11g standard, defined by IEEE, is an extension to the 802.11b standard of wireless network. It operates in 2.4-GHz band and brings data rates up to 54Mbps using Orthogonal Frequency-Division Multiplexing (OFDM) technology. Since the 802.11g standard is backward compatible with 802.11b, an 802.11b device can interface directly with an 802.11g access point.

Share/Bookmark]]> http://www.ucertify.com/article/what-is-80211g.html/feed 0 What is the Print permission? http://www.ucertify.com/article/what-is-the-print-permission.html http://www.ucertify.com/article/what-is-the-print-permission.html#comments Wed, 28 Oct 2009 00:00:00 +0000 uCertify 2500210

Print is a basic printer permission that allows users or groups to connect to a printer, print documents, and manage their own documents in the print queue. Users having the Print permission are able to pause, resume, restart, and cancel the printing of a document.

Share/Bookmark]]> http://www.ucertify.com/article/what-is-the-print-permission.html/feed 0 Service Broker http://www.ucertify.com/article/service-broker-2.html http://www.ucertify.com/article/service-broker-2.html#comments Sun, 11 Oct 2009 00:00:00 +0000 uCertify 7101047

Service Broker is a new technology in SQL Server 2005 and provides a solution to message delivery issues that occur while transferring transactional data from one server to another. This technology provides a message-based communication platform and is part of the Database Engine. Database developers develop secure, reliable, and scalable applications with the help of Service Broker. Service Broker is used for the applications that use a single instance of SQL Server 2005 as well as for those that use multiple instances of SQL Server 2005 across the network. It provides reliable messaging between multiple instances of SQL Server 2005. It uses TCP/IP protocol to exchange messages between instances of SQL Server 2005, prevents unauthorized users from accessing the network, and encrypts messages that are sent over the network. It provides a robust asynchronous programming model. Asynchronous programming is the most popular technique in database application programming. In asynchronous programming, the Database Engine handles commands while the application continues to run. Asynchronous programming minimizes response time and enhances application throughput of database applications.

Service Broker consists of various components that make up the entire architecture. It can be divided into three broad components. They are as follows:

  • Conversation components

  • Service definition objects

  • Remoting and security components

Conversation Components

All the applications using Service Broker communicate through conversations that involve messages, dialog conversations, and conversation groups.

Message: A message is textual information exchanged between applications that use Service Broker. A message is part of a conversation. A message has a unique conversation identity and a sequence number within the conversation. When Service Broker receives messages, it enforces the order of messages by using the conversation identity and the sequence number of each message.

Dialog Conversation: All messages are part of a conversation. A dialog conversation, or dialog, is an agreement between two services. Dialogs use the conversation identity and the sequence number of the messages to identify them and deliver them in the correct order. A dialog conversation has two participants: The Initiator and the Target. The initiator begins the conversation, and the target accepts a conversation started by the initiator.

Conversation Group: A conversation group is a group of related conversations. Each conversation belongs to one conversation group. Each conversation group is associated with a specific service.

Service definition objects

Service definition objects are database objects that specify the basic design of an application that uses Service Broker. These database objects are message types, contracts, queues, and services. A Service Broker application uses these objects to hold conversation.

Message Types: Applications using Service Broker communicate with each other through conversations. The participants in a conversation agree with the name and contents of the message. A message type object is a name and the type of data for a message type. Service Broker offers a DEFAULT built-in message type. If an administrator does not specify a message type in a Service Broker SEND command, Service Broker will use the DEFAULT message type.

Contracts: An application uses message types to accomplish a particular task through a contract. A contract is an agreement between two services. The contract specifies which message types will be used to process a message. Service Broker offers a DEFAULT built-in contract. If an administrator does not specify a contract in the BEGIN DIALOG statement, Service Broker will use the DEFAULT contract.

Queues: Queues, such as containers, store messages. When Service Broker receives a message for a service, it inserts the message into the queue for that service. Service Broker manages queues and presents a view of a queue like a table. Each service is associated with one queue. When a message comes for a service, Service Broker places the message in the queue associated with that service. Each message in the queue is arranged in a row. A row contains the contents of a message and information about the message type, the service that the message is aimed at, the contract that the message follows, the conversation that the message is a part of, and other internal information related to the queue.

Services: Services reference the contract. Service Broker uses the name of a service to route and deliver messages to the correct queue and enforce the contract for a conversation. Each service specifies a queue to hold messages.

Remoting and Security components

Service Broker enables secure and reliable communication between multiple instances of SQL Server 2005, allows you to manage routing, and establishes security for the conversation.

After taking a brief look at the Service Broker architecture, you will learn how to design this architecture. To design this architecture, you will take the following steps:

  1. Create message types that will be sent by the initiator and returned by the target.
  2. Create queues where messages will be submitted.
  3. Create a contract that will establish an agreement between services.
  4. Create services that will reference the contract.

Now you can start creating a message type. The message type is created using the CREATE MESSAGE TYPE statement.

The syntax for creating a message type is as follows:

CREATE MESSAGE TYPE message_type_name
[ AUTHORIZATION owner_name ]
[ VALIDATION = { NONE
| EMPTY
| WELL_FORMED_XML
| VALID_XML WITH SCHEMA COLLECTION schema_collection_name
} ]
[ ; ]

Here is an example. In this example, you create the message types in the typed XML format for the initiator and the target.

CREATE MESSAGE TYPE CricketRequest
AUTHORIZATION dbo
VALIDATION = WELL_FORMED_XML

CREATE MESSAGE TYPE CricketStatus
AUTHORIZATION dbo
VALIDATION = WELL_FORMED_XML

After creating the message types, you will create the queue where the message types will be submitted. The queue is created using the CREATE QUEUE statement.

The syntax for creating a queue is as follows:

CREATE QUEUE <object>
[ WITH
[ STATUS = { ON | OFF } [ , ] ]
[ RETENTION = { ON | OFF } [ , ] ]
[ ACTIVATION (
[ STATUS = { ON | OFF } , ]
PROCEDURE_NAME = <procedure> ,
MAX_QUEUE_READERS = max_readers ,
EXECUTE AS { SELF | ‘user_name’ | OWNER }
) ]
]
[ ON { filegroup | [ DEFAULT ] } ]
[ ; ]

<object> ::=
{
[ database_name. [ schema_name ] . | schema_name. ]
queue_name
}

<procedure> ::=
{
[ database_name. [ schema_name ] . | schema_name. ]
stored_procedure_name
}

In the example given below, you create the sender queue and the receiver queue to send and receive messages with no parameters.

CREATE QUEUE CricketSender
CREATE QUEUE CricketReceiver

After creating the queues, you will create the contract that will establish an agreement between services.
The contract is created using the CREATE CONTRACT statement.

The syntax for creating a contract is as follows:

CREATE CONTRACT contract_name
[ AUTHORIZATION owner_name ]
( { message_type_name SENT BY { INITIATOR | TARGET | ANY } | [ DEFAULT ] }
[ ,...n] )

[ ; ]

In the following example, you submit a cricket request from the initiator using the CricketRequest message and receive a cricket status from the target through the CricketStatus message.

CREATE CONTRACT CricketContract
(CricketRequest SENT BY INITIATOR, CricketStatus SENT BY TARGET)

After creating the contract, you will create the service that will reference the contract. The service is created using the CREATE SERVICE statement.

The syntax for creating a service is as follows:

CREATE SERVICE service_name
[ AUTHORIZATION owner_name ]
ON QUEUE [ schema_name. ] queue_name
[ ( contract_name | [DEFAULT] [ ,...n ] ) ]

[ ; ]

In the example given below, you create the services for the sender and the receiver.

CREATE SERVICE CricketSenderService ON QUEUE CricketSender (CricketContract)
CREATE SERVICE CricketReceiverService ON QUEUE CricketReceiver (CricketContract)

Share/Bookmark]]> http://www.ucertify.com/article/service-broker-2.html/feed 0 What are the types of capacity planning? http://www.ucertify.com/article/what-are-the-types-of-capacity-planning-3.html http://www.ucertify.com/article/what-are-the-types-of-capacity-planning-3.html#comments Wed, 30 Sep 2009 00:00:00 +0000 uCertify 3601480

The following are the types of capacity planning:

  • Preconfiguration capacity planning: This capacity planning involves the planning and implementation of hardware resources that will be used to accomplish a given task.

  • Postconfiguration capacity planning: This capacity planning involves monitoring performance of the current hardware resources. It is also used to analyze trends and plan the upgrade or replacement of hardware as per requirements.
Share/Bookmark]]> http://www.ucertify.com/article/what-are-the-types-of-capacity-planning-3.html/feed 0 Replication http://www.ucertify.com/article/replication_3601460-2.html http://www.ucertify.com/article/replication_3601460-2.html#comments Tue, 29 Sep 2009 00:00:00 +0000 uCertify 3601460

Replication is a type of configuration used to copy data and database objects from one database instance to another. A database administrator has to configure a server for replication, and monitor it in order to detect and resolve issues regarding replication.

Requirements for replication: The following roles are required for replication configuration:

  • Distributor: The server that is configured to the Distributor role distributes data to Subscribers. It creates tables and files to store the data for replication. The computer to be used as a Distributor should have a large amount of storage space.

  • Publisher: The server that is configured to the Publisher role stores data for replication. It detects data changes and maintains information about all publications.

  • Subscriber: The server that is configured to the Subscriber role receives data published by either Publisher or Distributor. The Subscriber configuration depends on the type of replication chosen to replicate data. Each replication type should have a different configuration for a Subscriber.

Replication objects: After the configuration of Publisher, Distributor, and Subscriber servers, various objects are needed to replicate the data. These objects are as follows:

  • Article: Article is an object that includes various database objects such as tables, views, stored procedures, etc. Each of the database objects can be selected as an article. All the articles are combined to create a publication.

  • Publication: Publication is a combination of articles. The data to be received by the Subscriber is sent as a publication. An article must be placed in a publication in order to send the data to the Subscriber.

  • Subscription: Subscription receives the publication sent by the Publisher or Distributor. Subscription is of the following two types:
    • Push subscription: A push subscription is created at the Publisher. Data is pushed to the Subscribers by the Merge or the Distribution agent.

    • Pull subscription: A pull subscription is created at the Subscriber. Data is pulled by the Merge or the Distribution agent from the Publisher.

Replication Models: A DBA has to decide the type of replication model before replicating the data. He has to decide the configuration for the Publisher, Distributor, and Subscriber databases. The following replication models can be applied before data replication:

  • Peer-to-Peer: It is a type of replication model in which a single database is hosted by multiple servers. The purpose of this model is to maintain a database and manage database failures. If a server containing the database is unavailable, the applications can access the data through other servers hosting the database.

  • Central Publisher: The Central Publisher is a replication model in which the Publisher and the Distributor roles are maintained on the same SQL Server 2005/2008 computer. The Subscriber role is configured on other servers. The maintenance of the server is easy, but it adds additional load on the server.

  • Central Publisher with Remote Distributor: The Central Publisher with Remote Distributor is a replication model in which the Publisher and the Distributor roles are maintained on separate SQL Server 2005/2008 computers. The Subscriber role is configured on other servers. The workload of the Publisher server is distributed, but an additional Distributor server is to be maintained.

  • Central Subscriber: Central Subscriber is a replication model in which the Subscriber role is configured on a single server. It is used to collect data from several Publisher servers. It can also be configured to send data to other servers.

  • Publishing Subscriber: Publishing Subscriber is a replication model in which data is obtained from a Publisher and transferred to other Subscribers. This replication model can be used with other replication models for the replication of data.

Types of replication: There are different types of replication and a DBA has to choose which type of replication he needs to configure. Some applications need only a snapshot of the database, whereas others need incremental data changes. The different types of replication are as follows:

  • Transactional Replication: Transactional replication starts with a snapshot of the Publication database objects and data. The modifications made in the data and in the schema are delivered to the Subscriber database, simultaneously. Transactional replication is used in a server-to-server environment in the following conditions:

    • When a Publisher or Subscriber is a non-SQL Server database, such as Oracle.

    • When incremental changes are to be made at the Subscriber.

    • When an application requires low latency.

    • When an application requires access to data changes.

    • When the Publisher has a high volume of insert, update, or delete operations.
  • Merge Replication: Merge replication starts with a snapshot of the Publication database. Triggers track the modifications in the data and the schema at the Publisher or the Subscriber server. Merge replication is performed in a server-to-client environment. It should be performed in the following conditions:
    • When same data is to be updated by multiple Subscribers.

    • When data changes are to be propagated to the Publisher and other Subscribers.

    • When offline data changes are to be synchronized on the Publisher and other Subscribers.

    • When conflicts are to be detected and resolved.

    • When each Subscriber needs different partitions of data.

    Merge replication does not take place if a Publisher or Subscriber is a non-SQL Server database.

  • Snapshot Replication: Snapshot replication distributes data at a specific moment. It does not monitor the modifications in data or schema. The entire snapshot is sent to Subscribers when synchronization occurs. The snapshot replication can be performed in the following conditions:
    • When data changes infrequently.

    • When small volumes of data are to be replicated.

    • When large volumes of changes occur over a short period of time.

    It does not take place when a Publisher or a Subscriber is a non-SQL Server database.

Replication Agents: Replication agents are used during the replication of data. They store data published by a Publisher. They also initialize and monitor the replication. Replication agents are as follows:

  • Queue Reader Agent: The Queue Reader agent runs with a transactional replication. It runs at the Distributor database and transfers the changes from the Subscribers to the Publisher database. Only one instance of this agent exists to serve all the Publishers.

  • Snapshot Agent: The Snapshot agent is used with all types of replication. It is used to prepare snapshot files that contain the schema and the data of published tables and database objects in the publication database. It also records synchronization jobs in the distribution database. It runs at the Distributor database instance.

  • Log Reader Agent: The Log Reader agent is used with a transactional replication. It is used to monitor the transaction log of each database configured for transactional replication. It copies the transactions that are marked for replication to the Distribution database.

  • Distribution Agent: The Distribution agent is used with transactional and snapshot replications. It is used in a transactional replication to move transaction files and data to the Subscribers database. It runs at the Subscribers database for pull subscriptions or at the Distributors database for push subscriptions.

  • Merge Agent: The Merge agent is used with the merge replication. It applies the snapshot to the Subscriber database instance, and the changes in the Subscriber are reflected in the Publisher database. The Merge agent uploads data changes from Subscribers to Publishers, and downloads data from Publishers to Subscribers.
Share/Bookmark]]> http://www.ucertify.com/article/replication_3601460-2.html/feed 0 What is Schtasks.exe? http://www.ucertify.com/article/what-is-schtasksexe-2.html http://www.ucertify.com/article/what-is-schtasksexe-2.html#comments Sun, 27 Sep 2009 00:00:00 +0000 uCertify 3502294

Schtasks.exe is a command line tool that is used to create, modify, delete, query, run, and end a scheduled task on a local or remote computer. It supports the following parameters:

  • /Create: To create a new task
  • /Delete: To delete an existing task
  • /Query: To view task list
  • /Change: To change an existing task
  • /Run: To launch an existing task
  • /End: To stop a currently executing task
Share/Bookmark]]> http://www.ucertify.com/article/what-is-schtasksexe-2.html/feed 0 What is a side-by-side migration? http://www.ucertify.com/article/what-is-a-side-by-side-migration-2.html http://www.ucertify.com/article/what-is-a-side-by-side-migration-2.html#comments Sat, 26 Sep 2009 00:00:00 +0000 uCertify 3501290

In a side-by-side migration, user data is migrated from the source computer to an intermediate store. Windows Vista is installed on another computer known as a destination computer and user data is transferred to this computer instead of transferring it back to the source computer. The figure below depicts side-by-side migration:

Note: During migration, user data is backed up on either a network share or on a removable USB drive.

Share/Bookmark]]> http://www.ucertify.com/article/what-is-a-side-by-side-migration-2.html/feed 0