Category Archives: Imported from BeyondRelational

These posts are imported from my old blog page: http://beyondrelational.com/modules/2/blogs/77/nakuls-blog.aspx

#0188-SQL Server-How to edit XML documents with the SSMS? Using XML Editor feature of SSMS


Today’s an impromptu post, and the intention is to draw attention to a “hidden” feature of the SQL Server Management Studio (SSMS).


Recently, we were working on designing changes that were required in an XML that was required to be exchanged between the application and the database. The team had gathered in a meeting room for a technical design session – a couple of application developers, a database developer and a database administrator.


We had the SQL Server Management Studio running to look at the table design and create/query test data. To edit the existing XML, the application developers launched an instance of the Visual Studio IDE. The database developer and administrator immediately mentioned that there was no need to launch Visual Studio. The question that came from the application team was – “Why?” The simple answer is



SSMS comes with it’s own XML editor!


Here’s the problem though – it’s not obvious. The XML editor in the SSMS is an extension to the query editor window, which is probably why it’s not obvious. The tools and options related to XML editing are only available if an XML document is actually opened within the SSMS. I prepared a sample XML document for this post, and simply opened it using the SSMS. This is how the SSMS interface changes.


image


Notice that in the Text Editor toolbar, we now have the additional operations enabled (from Left to Right):



  1. Create XML schema based on given XML document
  2. Reformat Selection
  3. Format the whole Document
  4. Show XSLT output
  5. Debug XSLT
  6. Cancel XSLT output

The reason one can edit XML documents within the SSMS is because the SSMS is ultimately a Visual Studio shell, inheriting call features common at the shell.



Do you use the XML editor within SSMS? Do leave a note as you go.


Until we meet next time,


Be courteous. Drive responsibly.

#0187-SQL Server-Quiz-What locks are acquired during Index Maintenance? Winners announced!


Earlier this week, I asked a question regarding the locks that are acquired by SQL Server during Index Maintenance. Before I proceed with answering the question, let’s revisit the types of index maintenance operations:



  1. Index Rebuild

    • During a rebuild, the entire index (from the root to the leaf nodes) is rebuilt using the same columns, index type, uniqueness attribute, and sort order
    • The rebuild of an index effectively recreates the entire B-tree structure

  2. Index Reorganize

    • Index reorganization, on the other hand, only removes fragmentation at the leaf level
    • Intermediate-level pages and the root page are not defragmented

From an availability perspective, Reorganization is better than a rebuild, because reorganization is always an ONLINE process, i.e. it acquires only short-term locks whereas REBUILD prevents any changes to the underlying table until the operation completes, i.e. it acquires long-term locks.


What kinds of locks are acquired during Index Maintenance?


To answer this question, let us perform a small test. We will rebuild an index on one of the table within the AdventureWorks sample database, and perform a reorganize on another table, while monitoring the locks acquired.


Locks during Index Rebuild


In one session to the SQL Server, run the following query to rebuild the index on the table HumanResources.Employee within the AdventureWorks sample database. As you can see, we are not using the ONLINE clause.

USE AdventureWorks2012
GO
ALTER INDEX ALL
ON HumanResources.Employee REBUILD
GO

While the rebuild is being executed, execute the following query using another query editor window/session to the same SQL Server instance.

USE AdventureWorks2012
GO
SELECT tl.resource_associated_entity_id AS ObjectId,
OBJECT_NAME(tl.resource_associated_entity_id) AS ObjectName,
tl.request_mode AS LockRequestMode
FROM sys.dm_tran_locks AS tl
WHERE tl.resource_database_id = DB_ID()
AND tl.resource_associated_entity_id = OBJECT_ID(‘HumanResources.Employee’)
GO

Here’s the output:











ObjectId ObjectName LockRequestMode
1237579447 Employee Sch-M

We can see that during a Rebuild, the SQL server requests a Schema Modification Lock (Sch-M) on the underlying object (i.e. “table”). The Sch-M lock prevents concurrent access to the table, meaning that it blocks all outside operations until the locks are released.


Locks during Index ReOrganize


In one session to the SQL Server, run the following query to rebuild the index on the table Sales.SalesOrderDetail within the AdventureWorks sample database. Note that we are not using the ONLINE clause.

USE AdventureWorks2012
GO
ALTER INDEX ALL
ON Sales.SalesOrderDetail REORGANIZE
GO

While the reorganize is being executed, execute the following query using another query editor window/session to the same SQL Server instance.

USE AdventureWorks2012
GO
SELECT tl.resource_associated_entity_id AS ObjectId,
OBJECT_NAME(tl.resource_associated_entity_id) AS ObjectName,
tl.request_mode AS LockRequestMode
FROM sys.dm_tran_locks AS tl
WHERE tl.resource_database_id = DB_ID()
AND tl.resource_associated_entity_id = OBJECT_ID(‘HumanResources.Employee’)
GO

Here’s the output:



















ObjectId ObjectName LockRequestMode
1154103152 SalesOrderDetail S
1154103152 SalesOrderDetail IX
1154103152 SalesOrderDetail IS

We can see that during a Reorganize, the SQL Server requests effectively an Intent Exclusive lock on the table. The table is therefore locked for definition changes (DDL), but is still available for SELECT operations. This is expected because REORGANIZE is always an ONLINE process.


Conclusions – The correct answer to the question



  • Locks acquired on the underlying table during Index Rebuild: Schema Modification Lock (Sch-M)
  • Locks acquired on the underlying table during Index Reorganize: Intent Exclusive lock (IX)

Who came up with the correct answers?


First of all, I would like to thank everyone who responded. But, this is a competition, and hence, below are the people whose responses were correct (partially correct answers also considered here):



  • Olga Medvedeva
  • Nirav Gandhi
  • Gaurang Patel
  • Roji Thomas

And now, for the winners…


The following are the winners, randomly selected from those who participated in the quiz.



  • Olga Medvedeva
  • Roji Thomas

CONGRATULATIONS TO ALL THE WINNERS! Expect my DM on your twitter accounts this week-end (or earlier) with more information on your prize – a Pluralsight training code!


Check out: http://www.pluralsight-training.net/microsoft for a detailed list of the courses available. Did you know that Pluralsight has courses spanning almost every Microsoft technology currently available in the Market? If you are a blogger, do write about how you used the Pluralsight trainings – which trainings you took, and what is your feedback.


Interesting Reading/Reference:


Locking and Index Maintenance within SQL Server is a very interesting topic, and here are some resources to help you read/know more:



Until we meet next time,


Be courteous. Drive responsibly.


Edit: August 17, 2012: Statement “The table is therefore locked for changes” has been changed to “The table is therefore locked for definition changes (DDL)” for clarity.

#0186-SQL Server-Quiz-Locks during Index maintenance (REBUILD/REORGANIZE)? Prize: Two (2) Pluralsight training codes!


What is the first word that comes to mind whenever one mentions the need for optimizing search or for increasing the performance of a database? Index.


Indexes play a vital role in SQL Server performance tuning, but they too need periodic maintenance. An index is logically implemented as a B-tree.


Over time as data is accumulated by the table, fragmentation may set in and the distribution of data within the index may become unbalanced, with some pages becoming full (as governed by the fill factor) leading to “page splits” whereas others might be sparsely filled. If data is deleted from the table, it leaves behind a “hole” in the index page – this free space is not reclaimed, which contributes to the bloating of the index. This reduces the efficiency of the indexes, while possibly consuming more than required disk space. At this stage, administrators need to perform maintenance operations on the index.


Index Maintenance operations can be classified into two:



  1. Index Rebuild

    • During a rebuild, the entire index (from the root to the leaf nodes) is rebuilt using the same columns, index type, uniqueness attribute, and sort order
    • The rebuild of an index effectively recreates the entire B-tree structure

  2. Index Reorganize

    • Index reorganization, on the other hand, only removes fragmentation at the leaf level
    • Intermediate-level pages and the root page are not defragmented

From an availability perspective, Reorganization is better than a rebuild, because reorganization is always an ONLINE process, i.e. it acquires only short-term locks whereas REBUILD prevents any changes to the underlying table until the operation completes, i.e. it acquires long-term locks. The question therefore is:



What types of locks do index REBUILD and index REORGANIZE operations occupy on the underlying table, by default (i.e. the “ONLINE” option is not specified)?


Bonus Exercise


As a bonus exercise, you may want to share any queries or tests that you may have conducted to arrive at the answer to the question above. Please note that the bonus exercise does not carry any rewards this time around – it is only as an exercise for the brain cells.


Rules


The rules are very simple:



  1. You can answer these questions till Wednesday 22:00hrs (IST)/Wednesday 12:30hrs (US-EDT) – August 15, 2012
  2. Answers will be shared and winners declared in my post on Thursday, August 16, 2012
  3. You can answer multiple times – however, at the end of the day, only one entry would be considered
  4. Follow the following on Twitter!

  5. Winners will be chosen randomly
  6. Prizes will be given out through Twitter – hence, it is important that you follow me Smile

Remember: Participation is always more important! Make sure you reply to the quiz even if it’s just a guess!


Until we meet next time,


Be courteous. Drive responsibly.

#0185 – SQL Server – Quiz-Which database does not follow one of the ACID properties? Winners Announced!


Earlier this week, we discussed the following ACID properties that are geared towards ensuring the integrity of the data residing within the database.



  • Atomicity
  • Consistency
  • Isolation
  • Durability

Every user database within Microsoft SQL Server follows these ACID properties. However, there is one special case – one database which does not support one of the ACID properties. Therefore, I had asked 3 questions – one main, and the rest were bonus questions as mentioned below:



  1. Which SQL Server database does not follow one of the ACID properties?
  2. Name the ACID property which is not followed in the answer to question #1
  3. Explain, in your own words, the reason why you believe the database does not follow the said ACID property

Today, I will attempt to answer these questions myself.


Which SQL Server database does not follow one of the ACID properties? Why?


In my humble opinion, this has to be the tempdb database. The tempdb database does not follow the ACID property of Durability. Here’s why:


Whenever Microsoft SQL Server is restarted, the tempdb is recreated. Any data that was committed to the tempdb is lot and replaced by a fresh copy from the model database. To test this out on your own, or to read about my experiments with the re-creation of the tempdb, you can refer my previous posts referenced below:



  1. TempDB – Is it a copy of the Model database?
  2. TempDB v/s Model database – Minimum size considerations – CREATE DATABASE – Error Msg 1803

Who came up with the correct answers?


First of all, I would like to thank everyone who responded. But, this is a competition, and hence, below are the people whose responses were correct:



Unfortunately, I will not be considering the answer of the user “sk2000” because the original answer was “NoSQL”, which generally do not have the concept of ACID properties.


And now, for the winners…


The following are the winners, randomly selected from those who participated in the quiz.



Expect my DM on your twitter accounts this week-end (or earlier) with more information on your prize – a Pluralsight training code!


Check out: http://www.pluralsight-training.net/microsoft for a detailed list of the courses available. Did you know that Pluralsight has courses spanning almost every Microsoft technology currently available in the Market? If you are a blogger, do write about how you used the Pluralsight trainings – which trainings you took, and what is your feedback.


For those who did not win…


Do not despair if your name did not appear in the list above. Another quiz is coming up on Monday, August 13, 2012. Be sure to participate in that one too!


Until we meet next time,


Be courteous. Drive responsibly.

#0184-SQL Server-Quiz-Which database does not follow one of the ACID properties? Prize: Two (2) Pluralsight training codes!


Any RDBMS system follows a certain set of general principles that are geared towards ensuring the integrity of the data residing within the database. These fundamental principles are collectively known as ACID properties, which every database within an RDBMS system should confirm to.



  • Atomicity:

    • At a transaction level, this is the all-or-nothing approach, i.e. either all changes are committed or none – one cannot have a partially committed transaction
    • Example: A parallel can be established with the banking industry – when transferring funds from one bank account to another, it is imperative that the amount of money deducted from the source account are credited to the destination account. It is not acceptable to have a deduction from one account, but no credit to another account (that would be a scam!). If something goes wrong during the transaction, the rollback needs to be triggered in both systems – source and destination
    • Similarly, all RDBMS systems need to ensure that if something goes wrong within any transaction, an “undo” or “rollback” happens for the non-committed transaction

  • Consistency:

    • Whenever any transaction is “committed”, the effect of the transaction should leave the database in a logically consistent state
    • Example: When adding sales data into a database, it would be logically inconsistent to enter a sales order without having a corresponding customer record. Through the use of foreign keys, the RDBMS ensures that one cannot leave the database in a logically inconsistent state when committing a transaction

  • Isolation

    • Each transaction should be isolated (or protected) from the effects of other concurrently running transactions
    • This means that although multiple transactions are running in parallel, the net effect of the execution of the execution should be identical to that of executing all transactions in series (i.e. one after another in some serial order)
    • Example: Taking our banking example further, let’s assume that John wants to transfer $100 to Jack’s account. Jack wants to transfer $75 to Steve’s account. Both are separate transactions, but the net effect of these transactions is that Jack will end up with $25 more than his base balance ($x). Here’s how: [($x + $100) – ($75)] = $x + $25. If this is not the end result, the system is no good

  • Durability

    • Durability simply means that once a transaction has been completed, it’s effect must be persisted within the database irrespective of the state of the system (i.e. even in case of a system crash, the data must be permanently committed to disk upon recovery)
    • Example: Continuing our example of the banking system, if the system goes down in the middle of the banking transaction, Atomicity would ensure that uncommitted transactions are rolled back. However, if the system goes down after completion of the transaction, then changes made to all accounts involved must remain as-is when the system comes back online

The Question – Which SQL Server database does not follow one of the ACID properties?


Every user database within Microsoft SQL Server follows these ACID properties. However, there is one special case – one database which does not support one of the ACID properties. The question today is:



Which SQL Server database does not follow one of the ACID properties?


Bonus Questions!!!


Here are two (2) bonus questions which you can answer – the bonus questions also contribute to the prize-winning questions!



  1. Based on the answer to the basic question, name the ACID property which the database does not follow
  2. Explain, in your own words, the reason why you believe the database does not follow the said ACID property

Rules


The rules are very simple:



  1. You can answer these questions till Wednesday 22:00hrs (IST)/Wednesday 12:30hrs (US-EDT) – August 08, 2012
  2. Answers will be shared and winners declared in my post on Thursday, August 09, 2012
  3. You can answer multiple times – however, at the end of the day, only one entry would be considered
  4. Follow the following on Twitter!

  5. Winners will be chosen randomly

Remember: Participation is always more important! Make sure you reply to the quiz even if it’s just a guess! 


Until we meet next time,


Be courteous. Drive responsibly.