When: Monday, June 4th, 2012

Where: Dekel Hall, Microsoft Offices, Hapnina 2 St., Raa’nana

Schedule:

• 17:30 – 17:45 Gathering
• 17:45 – 18:45 First Session
• 18:45 – 19:00 Q&A and Job Search
• 19:00 – 19:15 Break
• 19:15 – 20:15 Second Session

Agenda:

To register for the event in order for Microsoft to arrange parking and food:http://isug119.eventbrite.com

Using special functions for querying and executing commands at linked servers is not very convenient, and sometimes even very problematic.
For example, I need to execute some code on several linked servers but the linked server names are dynamic (queried from a table for example).
On each such linked server I need to execute a dynamic query.
However because I must use the EXECUTE() AT [...] command I'm exposing a big hole here for SQL Injection.
I found myself wishing I could use sp_executesql with linked servers but there's no such way as far as I know.

For example, this is what I’m forced to do:

CREATE PROCEDURE BackupOnRemoteServer

    @Path NVARCHAR(4000)

AS

    DECLARE

        @Statement    NVARCHAR(MAX)

    SET @Statement = N'    

    BACKUP DATABASE [MyDB]

    TO DISK = ''' + @Path + ''''

    EXECUTE (@Statement) AT [SQLINS1]

I’ve posted a suggestion on Microsoft Connect for the following feature:

It would be very helpful if we were able to connect to databases on linked servers with the "USE" keyword.

Technically, it would be like "opening a new session" from one SQL Server to another.

The sample I’ve posted above could be executed like this:

CREATE PROCEDURE BackupOnRemoteServer

    @Path NVARCHAR(4000)

AS

    DECLARE

        @ServerName VARCHAR(200),

        @Statement    NVARCHAR(MAX),

        @Parameters NVARCHAR(MAX)

    SET @ServerName = 'SQLINS1';

    SET @Parameters = N'@Path NVARCHAR(4000)';

    SET @Statement = N'

    USE [' + @ServerName + N'].[MyDB]

    BACKUP DATABASE [MyDB]

    TO DISK = @Path'

    EXEC sp_executesql @Statement, @Parameters, @Path

Once the USE command was executed, theoretically it's like I'm connected directly to the linked server using a query window.

Security could be improved versus SQL Injection (use sp_executesql with parameters instead of EXECUTE() AT) like the example above.

Usability could be improved due to cleaner and more readable code.

If you like this idea, please visit this page and vote for it so it’ll get higher priority on Microsoft’s to-do list:

https://connect.microsoft.com/SQLServer/feedback/details/742327/use-keyword-with-linked-servers#details

If you love SQL Server 2012, if you already know a thing or two about it and you want to learn more, this is for you!

Press here to learn more about NAYA Technologies and Microsoft's SQL Server 2012 Team vs 100.

Madeira is celebrating 5 years and the best way to party was a 2 days, better-than-ever, company trip.

You can watch selected pictures from our trip at our Facebook company page here.

Introduction

Service Broker is a cool new feature since SQL Server 2005. Yes, SQL 2012 just came out so it’s hardly “new” anymore. But in reality, many DBAs and DB users are still not aware of this feature, or don’t know how to utilize it, or are afraid to do so because they’re not familiar with it.

Using this short series of posts, I’m hoping to ease the minds of such people

In short, Service Broker is an asynchronous queuing engine working inside SQL Server. Using this engine we can send and receive binary or XML messages between queues. When a message is inserted in a queue, Service Broker executes an “activation procedure” that you specified, which is supposed to handle messages from that queue.

Since we have a lot to cover in our sample, I won’t go into too much detail introducing Service Broker. But Microsoft has an excellent and detailed chapter about Service Broker available right here: http://msdn.microsoft.com/en-us/library/bb522893.aspx

Sample 1: Multi-Threading

I managed to encounter several times a scenario where an application needed to execute several queries independent of each other, and then group them together somehow. However, each of these queries takes a while to execute.
One might wonder: If only we could use some kind of multi-threading mechanism to execute them in parallel, and then the total running time will be of the slowest query only and not the total of them.

Well, it just so happens that our first sample will show how you can implement “multi-threading” in SQL Server using Service Broker queues!

The Design

First, I’ll explain the general idea of the design:

Since Service Broker only works with binary or XML messages, we’ll use XML to send a “query request”, and wait for a “query response”.
Specifically, we’ll send a message containing some kind of a dynamic query. But that dynamic query must return its result in XML form using an output parameter. Then, Service Broker will execute the query, retrieve the result from the output parameter, and send the result back as the response.
After that, it’s up to us to gather all the responses together and do whatever it is we wanted to do with it.

Also, for the sake of our sample, we’ll need to simulate long execution times. We’ll do this simply by adding a WAITFOR DELAY command into our dynamic queries which will cause the query to wait for a random number of seconds (between 10 and 30).

The Scripts

Available below is a ZIP file with the two scripts we’ll use:
One is the installation script, responsible for creating all the objects we require – the database, the service broker procedures, endpoints and queues. Everything you need to implement multi-threading in SQL Server.
The other is a sample of how to use this mechanism, using simple queries and a WAITFOR DELAY command to simulate long execution times.

The scripts are commented to help you understand what’s going on. But we’ll go over them bit by bit just in case.

The Installation Script

In order to explain the installation script, I’ll list all the objects that we’re creating and explain the purpose of each object. More detailed information about the implementation can be found in the script itself.

• SB_PQ_Test:
  That’s the database we’ll be using to create all the necessary objects.
• SB_PQ_ServiceBrokerLogs:
  This is a logging table which will be used to log the start and end of each query execution, and any errors that may occur.
• SB_PQ_ExecuteDynamicQuery:
  This is the procedure which will actually execute the dynamic queries. It builds the dynamic command, uses sp_executesql to execute it, and returns the result as an output parameter. The name of the output parameter itself can be dynamic.
• SB_PQ_HandleQueue:
  This is the activation procedure that Service Broker executes when it creates a “reader instance”. Or in other words, when there’s something in the request queue.
  This procedure is the most important part because it’s responsible for retrieving messages from the request queue, execute the query (using SB_PQ_ExecuteDynamicQuery), and handle any errors that may occur in-between.
• SB_PQ_Request_Queue:
• This is the queue where all query requests will be waiting to be processed. Its activation procedure is SB_PQ_HandleQueue.
• SB_PQ_Response_Queue:
  This is the queue into which query responses will be sent. Its doesn't have an activation procedure because query response extraction is done manually.
• [//SB_PQ/Message]:
  This is a simple message type of “Well Formed XML”. We’ll be using it to verify our messages.
• [//SB_PQ/Contract]:
  This is a contract defining that both target and initiator must send messages of type [//SB_PQ/Message].
• [//SB_PQ/ProcessReceivingService]:
  This is the service endpoint working as the “address” of request queries. We will be sending messages into this service. The queue it’ll be using to receive messages is SB_PQ_Request_Queue.
• [//SB_PQ/ProcessStartingService]:
  This is the service endpoint working as the “address” of response queries.
  We will be sending messages from this service. The queue it’ll be using to receive messages is SB_PQ_Response_Queue.
• SB_PQ_Start_Query:
  This is the public procedure that will used for starting an execution thread, by sending a request query to [//SB_PQ/ProcessStartingService].
  You can think of it as an API simplifying our use of all the above objects.
  It receives as parameters the SQL command that should be executed, the name of the output parameter (without the @), and the conversation group ID.
• SB_PQ_Get_Response_One:
  This is the public procedure that will be used to retrieve the results of our queries. It receives as a parameter the conversation group ID to be used, and returns the first result it finds as an output parameter. You may also think of it as part of the API simplifying our use of the above objects.

Whew, that was a long list! Please note that since Service Broker works asynchronously in the background, error handling is extremely important. Note all the error handling, especially in the SB_PQ_HandleQueue procedure.

The Sample Script

Now we can really get down to business. I’ll go over the important parts in the script and explain each of them:

-- random workload simulation settings

SET @MinDelay = 10

SET @MaxDelay = 30

SET @ConvGroup = NEWID();    -- the messages will be grouped in a specific conversation group

SET @NumOfSegments = 3;        -- number of "threads" to use

-- create several segments

SET @Segment = 1;

WHILE @Segment <= @NumOfSegments

BEGIN

In our sample, we create several “segments” (or threads) where each of them will have a random delay between 10 and 30 seconds, and execute a simple query returning its details. In the above script we define the minimum and maximum delay in seconds, set the conversation group ID by which our threads will be grouped, total number of threads (3 in our case), and we start looping per each of the threads.

-- random delay between @MinDelay and @MaxDelay seconds to simulate long execution time

SET @Delay = '00:00:' + CONVERT(varchar(8), ROUND(RAND() * (@MaxDelay - @MinDelay),0) + @MinDelay)

The above script simply prepares the delay representation by generating a random number of seconds as we defined earlier (between 10 and 30).

-- build our dynamic SQL command. note the use of XML as the result.

SET @SQL = N'

WAITFOR DELAY ''' + @Delay + ''';

SET @SB_PQ_Result = 

(

    SELECT

        Segment = ' + CONVERT(nvarchar(max), @Segment) + N',

        Delay = ''' + @Delay + N''',

        StartDate = GETDATE(),

        Name = QUOTENAME(name),

        object_id, type, modify_date

    FROM

        SB_PQ_Test.sys.tables AS Tab

    FOR XML AUTO, ELEMENTS

);

';

In the script above we create the dynamic SQL command which will be executed by the current thread. Note the use of XML AUTO, ELEMENTS to format the results in XML and put them in the output parameter.

Also note the use of WAITFOR DELAY at the start to simulate long execution time.

-- Send request to queue

EXEC SB_PQ_Start_Query @SQL, @OutputParam, @ConvGroup;

The above script executes the API procedure SB_PQ_Start_Query with the SQL command we prepared, the name of the output parameter, and the conversation group ID. This will put the message in the request queue and continue executing without waiting for a response (the magic of asynchronous work).

    -- increment segment index

    SET @Segment = @Segment + 1;

END

The above script increases the thread index so we can continue to the next one.

-- init final result

DECLARE @TotalResult XML;

SET @TotalResult = '<Tables> </Tables>'

The above script initializes an XML variable called @TotalResult which will contain all the results we’re about to receive.

-- count based on number of segments that we created earlier

SET @Segment = 1;

WHILE @Segment <= @NumOfSegments

BEGIN

In this part of the script we’re resetting the @Segment index and looping again based on the number of threads in @NumOfSegments.

    -- Get segment from response queue

    EXEC SB_PQ_Get_Response_One @ConvGroup, @CurrentResult OUTPUT

In the above script, we use the API procedure SB_PQ_Get_Response_One to retrieve a single result from any of the threads (whichever finished executing first). The result will be returned in the output variable @CurrentResult.

-- insert into TotalResults using XML DML (syntax for SQL2008 and newer)

SET @TotalResult.modify('

insert sql:variable("@CurrentResult")

into (/Tables)[1] ');

The above script uses XML DML language with reference to the @CurrentResult variable to insert its contents into the @TotalResult variable.

Please note that this method of “inserting” a SQL variable into an XML document is SQL 2008 syntax and won’t work in older versions.

If you have SQL Server 2005, you will need to work a little harder to collect the results (for example, declaring @TotalResult as nvarchar(4000) without a closing tag, concatenating the results one-by-one, and only at the end concatenate the closing tag as well).

    -- increment segment index

    SET @Segment = @Segment + 1;

END

The above script increases the thread index so we can continue to the next one.

-- return final result (as XML)

SELECT @TotalResult.query('.') AS FinalResult

-- return final result (as relational table)

SELECT

    Segment        = T.XRecord.query('.').value('(/Tab/Segment)[1]','varchar(100)'),

    Delay        = T.XRecord.query('.').value('(/Tab/Delay)[1]','varchar(8)'),

    StartDate    = T.XRecord.query('.').value('(/Tab/StartDate)[1]','datetime')

FROM

    @TotalResult.nodes('/Tables/Tab') AS T(XRecord)

The above script shows two methods of how you can return your final data.

The first method returns the simple XML representation of @TotalResult.

The second method shows how you can break down each element in @TotalResult (using the nodes() method) and display the values of each element (using the value() method).

-- check the SB logs to see how many unique sessions executed our requests

DECLARE @NumOfSessions INT;

SELECT @NumOfSessions = COUNT(DISTINCT SPID)

FROM SB_PQ_ServiceBrokerLogs

WHERE LogDate >= @StartTime

PRINT CONVERT(nvarchar(100),@NumOfSessions) + ' unique sessions participated in execution'

SELECT *

FROM SB_PQ_ServiceBrokerLogs

WHERE LogDate >= @StartTime

The above script is a sort of “debug” script which will display information from our Service Broker logging table, specifically showing how many unique sessions participated in execution since the start of the script, and displays the contents of the logging table from that period of time.

Execution Delay

It takes Service Broker several seconds before activating more than one reader instance. However, because our activation procedure continues waiting for new requests even after finishing an execution, once a reader instance is activated it’ll stay active until it’s manually shut down.

As a result of this behavior, your first execution in multi-threading may not be as fast as you’d expect. But from the second try onwards it shouldn’t take longer than the longest running query.

Customizing for Your Version

The above sample script is a very crude sample of how to use the API we created using the installation script. But this architecture can be used for just about anything you want to execute multi-threaded.

Your own implementation will probably be much different.

You may want to perform a query on a large range of records, and prefer to break down that range to several sub-ranges, where each sub-range will be a separate thread / segment.

Maybe you have several different queries and you need to do different things with them, so you’ll have several different executions of the API procedures (you’d need to think how to identify each query though, perhaps by adding that information in the XML somewhere).

Maybe you’re not even performing queries. Maybe it’s some maintenance tasks you wish to perform simultaneously (you still should expect a response of some kind, for example a message notifying of success or failure).

In any case, you’ll need to follow these rules:

• Your SQL command must make use of an output parameter of type XML. You don’t need to declare it inside your command, but simply put into it the XML result you want to expect.
• Take note of the name of the output parameter you’re using and provide it during the execution of the SB_PQ_Start_Query procedure.
• If there’s a chance other sessions will be using this API at the same time, it’s extremely important to make use of the Conversation Group ID parameter so you’d have a way of separating between the data of different sessions.
• In any case, the thread will try to return a response even if there was an error in your query (NULL will be returned). So in order to prevent clogging on the response queue, don’t forget to use the SB_PQ_Get_Response_One procedure to take them out of the queue.

Conclusion

This was but one example of how you can use Service Broker to improve your work with SQL Server. I’ll be working on new examples so check back soon!

I hope my post wasn’t too complicated or confusing. But if you have any questions, please post them in the comment section below, and I’d be happy to help!

Get ready for the biggest SQL Server event of the year!

Microsoft in cooperation with John Bryce – Hi-Tech College are conducting a two-day advanced professional training event with lots of professional seminars for DBAs, programmers and BI professionals. This is the place and time to take your skills to a higher level and learn about all the new features in SQL Server 2012.

When: Sunday-Monday, 10-11/06/2012, 09:00-16:30

Where: Daniel Hotel, Herzelia

Guy Glantser is presenting a seminar on 10/06 – SQL Server for Developers.

This seminar is intended for development DBAs as well as application developers, and it covers some of the more interesting and practical aspects of development in SQL Server, including some of the new features in SQL Server 2012.

If you want to register for Guy's seminar or for any other seminar, contact us for a lowered price.

Don’t wait for the last minute. Reserve your place now!

Microsoft’s annual event in the IT field was held last Monday (23.4.2012) at Ganei Hata’arukha, Tel Aviv.

The event title was "In order to lead you don't need just to stay up to date – you need to be what's next"

Details about the event at Microsoft site: http://www.microsoft.com/israel/benext/

Lectures about SQL Server 2012 from "Be what's next" event: http://www.youtube.com/user/MicrosoftIsrael?feature=watch

When: Monday, May 7^th, 2012

Where: Dekel Hall, Microsoft Offices, Hapnina 2 St., Raa’nana

Schedule:

• 17:30 – 17:45 Gathering
• 17:45 – 18:45 First Session
• 18:45 – 19:00 Q&A and Job Search
• 19:00 – 19:15 Break
• 19:15 – 20:15 Second Session

Agenda:

Common Errors That Effect Performance (Adi Cohen, Naya-Tech)

There are quite a few commonly used techniques that have a negative impact on your database perfromance. In this session we will review some of these errors, see why and how they impact performance and also provide some better performing alternative solutions. Among others, we will cover:

• Misunderstanding of the query plan when using procedures
• Query plan differences between procedures and ad-hoc batches
• The differences between a temporary table and a table variable
• And many more…

Who is afraid of Columnstore Indexes? (Michael Zilberstein, DB-Art)

This talk describes new SQL Server 2012 feature called "columnstore index". In this session we will learn about the differences between columnstore indexes and B-Tree indexes we are used to work with. We will see when it is best to use and when not to use this new index. We will cover limitations that columnstore index imposes on the tables that use it and how to live with those limitations. Like in all my sessions, I won't let you go without some internals – how columnstore index is organized on a physical level and how Query Processor works this new type of index. And of course demos, demos, and more demos…

To register for the event in order for Microsoft to arrange parking and food: http://isug118.eventbrite.com

Don’t know what’s with you guys, but when I first bumped into subqueries I could have understood their importance and efficiency, but for some reason, it wasn’t as intuitive for me as I hoped to. That means, I already know joins, right? And if, as claimed, subquries are only another way of writing it, and the SQL’s optimizer uses joins in any way, why bother?

Well, because it’s worthy and well, because it’s much more simple than it might look when dealing with it for the first time.

How simple are subqueries, or better said – how simple is understanding them? Let’s see:

First, a subquery is basically a query inside a query. That’s all there is to it. It might also become handy to understand that it’s basically, as mentioned before, another way of writing joins.

Now, let’s divide subqueries into 3 types in order to understand which type is to be used where:

Let’s think of a result set of a query, any result set, as the purpose of the inner query of ours (inner query, needless to say, is the one who’s inside the brackets, as opposed to the outer query who’s, well, you get the picture, ain’t ya?) : One type is a table – a data set with columns and rows. Other type is a data set that contains only one column and couple of rows, and the third type is a case when we get only one column and only one row.

Now, let’s call the first type “Derived Table”, the second type “List” and the third type “Scalar value”. Now and in general, derived tables will be placed after the “FROM” part of the outer query, lists will be placed after the “IN” part of the “WHERE” part of the outer query and scalar value will be put wherever we can use an expression in the outer query.

Examples? Why not?

Scalar values subqueries:

– Retrieve the orders with total amount greater than the average total amount

SELECT

       Id ,

       CustomerId ,

       TotalAmount ,

       DateAndTime

FROM

       Sales.Orders

WHERE

       TotalAmount >

              (

                     SELECT

                           AVG (TotalAmount)

                     FROM

                           Sales.Orders

              )

ORDER BY

       TotalAmount ASC;

GO

– Retrieve the English customers along with the number of orders

– and the number of support calls of each customer

SELECT

       CustomerId                 = Customers.Id ,

       CustomerName               = Customers.FirstName + N' ' + Customers.LastName ,

       NumberOfOrders             =

              (

                     SELECT

                           COUNT (*)

                     FROM

                           Sales.Orders AS Orders

                     WHERE

                           Orders.CustomerId = Customers.Id

              ) ,

       NumberOfSupportCalls =

              (

                     SELECT

                           COUNT (*)

                     FROM

                           Support.Calls AS Calls

                     WHERE

                           Calls.CustomerId = Customers.Id

              )

FROM

       Marketing.Customers AS Customers

WHERE

       Customers.CountryId = 7    – England

ORDER BY

       CustomerId ASC;

GO

SELECT
Id,
FirstName,
LastName,
(SELECT Name FROM Lists.Countries WHERE Id = Operation.Members.CountryId)
FROM
Operation.Members;
GO

Notice the difference between the first 2 examples and the third one: The last depends on a parameter from the outer query while the first two stand on their own. That’s the difference between a correlated subquery (the last one) and non-correlated one (first two).

List subquery:

SELECT p.Name

FROM Production.Product p WHERE ProductSubcategoryID IN

(SELECT ProductSubcategoryID FROM Production.ProductSubcategory WHERE

Name = 'Wheels')

Derived Table subquery (as another way of writing a join query, for example):

The join way:

SELECT p.Name

FROM Production.Product p

INNER JOIN Production.ProductSubcategory psc

ON p.ProductSubcategoryID = psc.ProductSubcategoryID

WHERE psc.Name = 'Wheels'

And the subquery way:

SELECT p.Name

FROM Production.Product p

INNER JOIN (SELECT * FROM Production.ProductSubcategory

WHERE Name = 'Wheels') psc

ON p.ProductSubcategoryID = psc.ProductSubcategoryID

A derived table can also be correlated, but in that case we will need to use a CROSS/OUTER APPLY. Lets take a look at an example:

– Retrieve all the customers along with the last 3 orders of each customer

SELECT

       CustomerId                 = Customers.Id ,

       CustomerName               = Customers.FirstName + N' ' + Customers.LastName ,

       OrderId                    = LastThreeOrders.Id ,

       OrderAmount                = LastThreeOrders.TotalAmount ,

       OrderDateTime              = LastThreeOrders.DateAndTime

FROM

       Marketing.Customers AS Customers

OUTER APPLY

       (

              SELECT TOP (3)

                     Orders.Id ,

                     Orders.TotalAmount ,

                     Orders.DateAndTime

              FROM

                     Sales.Orders AS Orders

              WHERE

                     Orders.CustomerId = Customers.Id

              ORDER BY

                     Orders.DateAndTime DESC

       )

       AS

              LastThreeOrders

ORDER BY

       CustomerId    ASC ,

       OrderDateTime DESC;

GO

Some things to remember about subqueries, and you are free to start working with them (Of course, it’s only the basics of it, but hey, as long as you understand the way of using it and where to use it, the rest is simply a select query in which you can do whatever you already know about select queries):

Derived tables:

· Can return any number of rows.

· Can return any number of columns.

· Must follow rules for being relational:

o Set must have a name (alias. Write “AS <query_name> outside of it).

o All columns must have unique names (aliases).

o Rows and columns have no order. Order (by) is done at the outer query anyway.

Scalar value subquery:

· Must return only 1 row and only 1 column.

· Does not require column or set alias.

· Can be correlated.

List subquey:

· Must return only 1 column

· Can return any number of rows

· Does not require column or set alias

· Can be correlated.

Let’s finish this post by saying, that subqueries can also be used for an EXIST check. In most cases, it is a very efficient way for such a check.

You might want to remember that:

· Subquery can and should be correlated.

· It does not return any output.

· Number of rows and columns is irrelevant, because SQL Server only checks for the existence of rows and doesn’t really need to retrieve any data, so specifying a long list of columns or a single constant in the column set is identical in this case. Here is an example:

– Retrieve the customers who have at least one order in the last 3 days

SELECT

       Customers.Id ,

       Customers.FirstName ,

       Customers.LastName

FROM

       Marketing.Customers AS Customers

WHERE

       EXISTS

              (

                     SELECT

                           NULL

                     FROM

                           Sales.Orders AS Orders

                     WHERE

                           Orders.CustomerId = Customers.Id

                     AND

                           Orders.DateAndTime > DATEADD (DAY , -3 , SYSDATETIME ())

              )

ORDER BY

       Customers.Id ASC;

GO

בפוסט הקודם כתבתי בנושא המבנה של הPage ועל מה המקום שבתוכו "מתבזבז" הן עם זה עבור ה- Page Header או בעבור ה- Slot Array, בנוסף בסוף הפוסט גם נתתי איזכור לגבי עמודה חבוייה בשם PhysLoc שקיימת עבור כל שורה בכל טבלה בDB של SQL SERVER.

ניתן לעבור ולקרוא שוב או בפעם הראשונה את הפוסט הראשון בקישור הבא : "היכן הרשומות שלי?!"

וכעת נדבר על העמודה (או יותר נכון הפונקציה) PhysLoc (קיצור של Physical location) ולשם מה היא קיימת ומה ניתן לעשות איתה.

נשים לב שגם בOracle קיימת עמודה (מזהה) דומה והיא מוכרת בשם ROWID.

ניצור טבלה פשוט בכדי להמחיש את השימוש בעמודה:

USE MASTER;
GO
IF DATABASEPROPERTY (N'CheckPhysLoc', 'Version') > 0
    DROP DATABASE CheckPhysLoc;
GO
CREATE DATABASE [CheckPhysLoc] ON  PRIMARY
( NAME = N'a', FILENAME = N'C:\CheckPhysLoc.mdf' , SIZE = 2304KB ,  FILEGROWTH = 1024KB ),
( NAME = N'b', FILENAME = N'C:\b.ndf' , SIZE = 3072KB , FILEGROWTH = 1024KB ),
( NAME = N'c', FILENAME = N'C:\c.ndf' , SIZE = 3072KB , FILEGROWTH = 1024KB ),
( NAME = N'd', FILENAME = N'C:\d.ndf' , SIZE = 3072KB , FILEGROWTH = 1024KB ),
( NAME = N'e', FILENAME = N'C:\e.ndf' , SIZE = 3072KB , FILEGROWTH = 1024KB )
 LOG ON
( NAME = N'CheckPhysLoc_log', FILENAME = N'C:\CheckPhysLoc_log.LDF' ,
    SIZE = 10240KB , MAXSIZE = 2048GB , FILEGROWTH = 131072KB )
GO
USE CheckPhysLoc;
GO
create table RowLocation (Id tinyint, Name varchar(1000));
GO

בכוונה יצרתי את הDB עם 5 קבצי DATA תחת אותו הFile group שהוא הPRIMARY אני אגיע לשימוש בכך בהמשך.

כעת נדאג להכניס רשומות אל הטבלה שיצרנו:

insert into RowLocation
select top 1000 ABS(CHECKSUM(NEWID()))%255, REPLICATE('X', 500)
from sys.all_objects

עכשיו נשלוף את הרשומות ואת הPhysLoc של כל רשומה בנוסף נשתמש בפונקציה ה-Undocumented: fn_PhysLocFormatter

select     %%physloc%% as PhysLoc,
         sys.fn_PhysLocFormatter(%%physloc%%) as PhysLocaion,
         r.*
from     RowLocation r

ונקבל את התוצאה הבאה :

ובעצם קיבלנו את העמודות הנסתרות, נסתכל על העמודה שנתתי לה את השם "PhysLocaion" ונראה שהיא בנויה במבנה של (XX:YYYY:ZZ) ככה ש:

הXX- מתאר את הFileID שבו ממוקמת הרשומה.

הYY- מתאר את הPageID שבו ממוקמת הרשומה.

הZZ- מתאר את הSlotID המיקום בתוך הPage ששייך לאותה הרשומה.

בקיצור זהו נתון מאוד חשוב והכרחי לשם העבודה התקינה של המנוע של SQL SERVER שידע כל רשומה ורשומה היכן היא נמצאת בדיוק.

ישנו הבדל קטן בין הגרסאות של SQL SERVER 2008/5, ההבדל הוא בשם העמודה ובפונקציות הקיימות עבורה.

לדגומא ב2008 – העמודה נקראת באמת %%physloc%%

בעוד שב2005- העמודה נקראת %%lockres%% (קיים גם ב2008 מקביל ל%%physloc%% לאחר הפרסור)

כעת נדבר על פונקציה הקיימת בגרסאת 2008 ומעלה ונקראת : sys.fn_PhysLocCracker  הפונקציה מפרקת את הPhysLoc ל3 העמודות (file_id, page_id, slot_id)  בצורה הבאה:

select     %%physloc%% as PhysLoc,
         sys.fn_PhysLocFormatter(%%physloc%%) as PhysLocaion,
         physLocator.file_id as FileId,
         physLocator.page_id as PageId,
         physLocator.slot_id as SlotId,
         r.*
from     RowLocation r
cross apply sys.fn_PhysLocCracker(%%physloc%%) physLocator

נקבל את התוצאה הבאה :

בגרסאת SQL SERVER 2005 הפונקציה הנ"ל איננה קיימת אבל אין זה אומר שלא ניתן לממש אותה, עשיתי את זה והיא נראת כך למי שמעוניין.

CREATE FUNCTION [dbo].[hf_PhysLocformatter]
(
    @v varchar(100)
)
RETURNS TABLE
AS
RETURN
(
    select  SUBSTRING(@v, PATINDEX('(_%', @v) + 1, PATINDEX('%:%', @v) - (PATINDEX('(%:%', @v) + 1)) AS FileID,
            SUBSTRING(SUBSTRING(@v, PATINDEX('%:%', @v)+1, LEN(@v) - PATINDEX('%:%', @v)), 1, PATINDEX('%:%', SUBSTRING(@v, PATINDEX('%:%', @v)+1, LEN(@v) - PATINDEX('%:%', @v)))-1) AS PageID,
            SUBSTRING(SUBSTRING(@v, PATINDEX('%:%', @v)+1, LEN(@v) - PATINDEX('%:%', @v)), PATINDEX('%:%', SUBSTRING(@v, PATINDEX('%:%', @v)+1, LEN(@v) - PATINDEX('%:%', @v)))+1, LEN(SUBSTRING(@v, PATINDEX('%:%', @v)+1, LEN(@v) - PATINDEX('%:%', @v))) - 1 - PATINDEX('%:%', SUBSTRING(@v, PATINDEX('%:%', @v)+1, LEN(@v) - PATINDEX('%:%', @v)))) AS SlotID
)

והשימוש בה זהה לשימוש בפונקציה הקיימת ב2008.

אתם שואלים מה זה עוזר לנו ?

נסתכל על הדוגמא הבאה, בתחילת הפוסט יצרנו DB עם מספר DATA FILES המשוייכים לו, לאחר מכן, הכנסנו חומר לטבלה שהתפרש על כל חמשת הקבצים שהגדרנו ובגלל שהתחלנו מאותה "נקודת פתיחה" בכל הקבצים (כולם היו ריקים).

עכשיו, במידה ונרצה לדעת עבור כל רשומה על איזה קובץ היא "יושבת", נוכל להשתמש בשליפה שהצגנו למעלה.

ובמידה ונרצה לדעת כמה רשומות “יושבות” לנו על כל קובץ פיזי מאותה הטבלה,  איך נדע ? נריץ את השליפה הבאה :

select     physLoc.file_id as FileId,
         COUNT(*) as [RowCount]
from     RowLocation r
cross apply sys.fn_PhysLocCracker(%%physloc%%) physLoc
group by physLoc.file_id
order by FileId

והתוצאה תחזיר לנו את הפלט הבא:

כעת שאנחנו יודעים על הקיום של הדבר המופלא הזה שנקרא PhysLoc אנחנו יכולים לעשות איתו כל מה שברצוננו ובנוסף זהו מזהה חד חד ערכי בטבלה הרי ששתי רשומות לא יכולות לשבת באותו המיקום הפיזי בעת ובעונה אחת.

ומכאן תוכלו להשתמש בידע על הPhysLoc גם עבור מציאת מה ממוצע של מספר השורות בכל PAGE בטבלה ועוד, השתמשו ביצירתיות שלכם ובידע לפי צרכיכם.

ספויילרים קטנים לשימושים נחוצים שניתן להתחיל לבדוק כיצד הדברים כאן עוזרים לנו הם :

• כאשר מנטרים LOCKS / DEADLOCKS המשאבים שננעלים כנראה מתוארים בעזרת הייצוג של הפונקציות הנ"ל.
• ובכדי למצוא את הרשומות כאשר מתמודדים עם CORRUPTION.

ולבסוף אני רוצה להגיד תודה לרוני ורד שבזכותה שמתי לב לפונקציות האלו וזאת בזכות חידה שהיא שאלה אותי, אז תודה!

מקווה שנהנתם,

חיים פישנר.