From jwcolby at colbyconsulting.com  Mon Nov 12 10:01:12 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Mon, 12 Nov 2007 11:01:12 -0500
Subject: [dba-SQLServer] summing in a crosstab
Message-ID: <00b201c82545$3faa5dc0$6c7aa8c0@M90>

I am doing a count like this
	10 11 12 13 14 15 16 17 etc
AK
AL
AR
AZ

This is by state, by boat length.  However the user wants the boat lengths
grouped, i.e. a single column for 10-15, 15-20 etc. where I have summed the
counts for 10,11,12,13,14, and 15 and display that in a single column.  Is
this possible in a single query or am I going to have to go to a separate
query to sum the lengths by state and then add that in to the crosstab
somehow?

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From fuller.artful at gmail.com  Mon Nov 12 10:27:23 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Mon, 12 Nov 2007 11:27:23 -0500
Subject: [dba-SQLServer] summing in a crosstab
In-Reply-To: <00b201c82545$3faa5dc0$6c7aa8c0@M90>
References: <00b201c82545$3faa5dc0$6c7aa8c0@M90>
Message-ID: <29f585dd0711120827h36ccc8farca401881f6f653c0@mail.gmail.com>

I think that I'd approach this by first building a query that contains a
calculated column for the ranges as described. To keep the query simple, I'd
create a function that returns the specified number. Something like this:

Function Ranger( BoatLength as Int ) as Int
    Dim result as Int
    Select Case BoatLength
           Case 10 to 15
                 result = 15
           Case 16 to 20
                 result = 20
           'etc.
    End Select
    Ranger = result
End Function

With that in hand, the rest is a cinch. Add a column to the query that calls
the Ranger() function and cross-tab that.

hth,
Arthur

On 11/12/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
> I am doing a count like this
>         10 11 12 13 14 15 16 17 etc
> AK
> AL
> AR
> AZ
>
> This is by state, by boat length.  However the user wants the boat lengths
> grouped, i.e. a single column for 10-15, 15-20 etc. where I have summed
> the
> counts for 10,11,12,13,14, and 15 and display that in a single column.  Is
> this possible in a single query or am I going to have to go to a separate
> query to sum the lengths by state and then add that in to the crosstab
> somehow?
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


From jwcolby at colbyconsulting.com  Mon Nov 12 15:09:19 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Mon, 12 Nov 2007 16:09:19 -0500
Subject: [dba-SQLServer] Pivot in SQL Server 2005
Message-ID: <00b801c82570$4af193d0$6c7aa8c0@M90>

I just wrote my first Pivot table by hand in SQL Server 2005 and HOLY COW
was that a PITA!!!  Is there a wizard anywhere for doing this?

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From jwcolby at colbyconsulting.com  Mon Nov 12 19:17:24 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Mon, 12 Nov 2007 20:17:24 -0500
Subject: [dba-SQLServer] indexes on cursors
Message-ID: <00bb01c82592$f321ca30$6c7aa8c0@M90>

I built a crosstab as follows:

SELECT St as USState, [C] as 'Canoe', [D] as 'Deck', [E] as 'Cat', [H] as
'House', [I] as 'Inflate', [J] as 'JetSki', [M] as 'Muscle', [P] as
'Pontoon',[T] as 'Waterski', [W] as 'Waterski2', [X] as 'Jet'
FROM(
SELECT     dbo.vAZHSIDFamilyHash.St, dbo.vBaseBoatType.Boat_Type
FROM         dbo.vAZHSIDFamilyHash INNER JOIN dbo.vBaseBoatType 
ON dbo.vAZHSIDFamilyHash.PK = dbo.vBaseBoatType.PKID) BoatType
PIVOT 
(
COUNT(BoatType.Boat_Type)
FOR BoatType.Boat_Type IN([C],[D],[E],[H],[I],[J],[M],[P],[T],[W],[X]))
AS BT
ORDER BY USState

Notice the inner select tab is defined as a named cursor BoatType.  The
fields making up the cursor, ST and Boat_Type both have indexes on them.
Will the indexes be used for the outer select in order to perform the actual
count and orderby?

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From fuller.artful at gmail.com  Mon Nov 12 22:16:54 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Mon, 12 Nov 2007 23:16:54 -0500
Subject: [dba-SQLServer] indexes on cursors
In-Reply-To: <00bb01c82592$f321ca30$6c7aa8c0@M90>
References: <00bb01c82592$f321ca30$6c7aa8c0@M90>
Message-ID: <29f585dd0711122016ke492393w66aaf93a2d8a7636@mail.gmail.com>

There is a SQL clause called HINT which may or may not be useful in your
situation. It overrides the optimizer and tells it to forget looking at
other alternatives and instead use your hint, which is a directive to use
some particular index that the optimizer may have overlooked and/or not
deemed useful. Look up HINT in BOL for more detailed info.

hth,
A.

On 11/12/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
> I built a crosstab as follows:
>
> SELECT St as USState, [C] as 'Canoe', [D] as 'Deck', [E] as 'Cat', [H] as
> 'House', [I] as 'Inflate', [J] as 'JetSki', [M] as 'Muscle', [P] as
> 'Pontoon',[T] as 'Waterski', [W] as 'Waterski2', [X] as 'Jet'
> FROM(
> SELECT     dbo.vAZHSIDFamilyHash.St, dbo.vBaseBoatType.Boat_Type
> FROM         dbo.vAZHSIDFamilyHash INNER JOIN dbo.vBaseBoatType
> ON dbo.vAZHSIDFamilyHash.PK = dbo.vBaseBoatType.PKID) BoatType
> PIVOT
> (
> COUNT(BoatType.Boat_Type)
> FOR BoatType.Boat_Type IN([C],[D],[E],[H],[I],[J],[M],[P],[T],[W],[X]))
> AS BT
> ORDER BY USState
>
> Notice the inner select tab is defined as a named cursor BoatType.  The
> fields making up the cursor, ST and Boat_Type both have indexes on them.
> Will the indexes be used for the outer select in order to perform the
> actual
> count and orderby?
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


From jwcolby at colbyconsulting.com  Tue Nov 13 04:37:36 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Tue, 13 Nov 2007 05:37:36 -0500
Subject: [dba-SQLServer] SP to create C# classes
Message-ID: <00d101c825e1$357b9520$6c7aa8c0@M90>

I ran across this this morning.

http://www.sqlservercentral.com/scripts/Miscellaneous/31997/

I have not tested it yet but thought that someone might find it useful.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From jwcolby at colbyconsulting.com  Tue Nov 13 05:29:23 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Tue, 13 Nov 2007 06:29:23 -0500
Subject: [dba-SQLServer] Performance of a unique index
Message-ID: <00d801c825e8$715c8bb0$6c7aa8c0@M90>

Are there any performance implications for a unique index, pro or con?  I
have tables where no data is added after the tables are set up.  Are unique
indexes faster than non-unique?  Are they slower?  No difference?  I do not
need the capability to enforce uniqueness since the tables are completely
static so I want the fastest index.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From jwcolby at colbyconsulting.com  Tue Nov 13 06:53:49 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Tue, 13 Nov 2007 07:53:49 -0500
Subject: [dba-SQLServer] merging records
Message-ID: <00e401c825f4$3ca28170$6c7aa8c0@M90>

I have tables of information about people.  The tables represent polls that
people have taken, so if a person takes a poll about brands of cigarettes
smoked, the table would have a record about that person for that poll.  If
that same person took a poll about software used, the table would have a NEW
record with information about the same person, but about the software that
person used.  And so forth and so on.  Now I need to "roll up" all of the
information about a person into a single record so that one record contains
all of the information about that person contained in all of the records
about that person in the table.

Is this possible directly in SQL?  Do I need to write code to iterate
through the table finding each person and all the records for that person,
and then consolidating the information from the second and subsequent
records into the first record found?

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From fuller.artful at gmail.com  Tue Nov 13 07:17:46 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Tue, 13 Nov 2007 08:17:46 -0500
Subject: [dba-SQLServer] merging records
In-Reply-To: <00e401c825f4$3ca28170$6c7aa8c0@M90>
References: <00e401c825f4$3ca28170$6c7aa8c0@M90>
Message-ID: <29f585dd0711130517g3fd6d3e8q7c4387df42c1158c@mail.gmail.com>

Given an unknown number of duplicate person records (for different polls), I
can't think offhand of a set-based way to do it (although perhaps a creative
use of COALESCE() might work). I think that the recordset approach may be
your best option. Even that approach might have problems, however. I may
have filled in one poll as Arthur Fuller and another as Arthur B. Fuller.

A.

On 11/13/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
> I have tables of information about people.  The tables represent polls
> that
> people have taken, so if a person takes a poll about brands of cigarettes
> smoked, the table would have a record about that person for that poll.  If
> that same person took a poll about software used, the table would have a
> NEW
> record with information about the same person, but about the software that
> person used.  And so forth and so on.  Now I need to "roll up" all of the
> information about a person into a single record so that one record
> contains
> all of the information about that person contained in all of the records
> about that person in the table.
>
> Is this possible directly in SQL?  Do I need to write code to iterate
> through the table finding each person and all the records for that person,
> and then consolidating the information from the second and subsequent
> records into the first record found?
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
>


From jwcolby at colbyconsulting.com  Tue Nov 13 07:31:24 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Tue, 13 Nov 2007 08:31:24 -0500
Subject: [dba-SQLServer] merging records
In-Reply-To: <29f585dd0711130517g3fd6d3e8q7c4387df42c1158c@mail.gmail.com>
References: <00e401c825f4$3ca28170$6c7aa8c0@M90>
	<29f585dd0711130517g3fd6d3e8q7c4387df42c1158c@mail.gmail.com>
Message-ID: <00e601c825f9$7cbd14f0$6c7aa8c0@M90>

>I may have filled in one poll as Arthur Fuller and another as Arthur B.
Fuller.

True.  Unfortunately there is not much I can do about that.  I do have the
full address (verified correct by the post office) to work with however.  I
may end up doing something about that scenario but in the meantime Arthur
and Arthur B. are two people.  

It could be argued that if you are inconsistent in how you write your name
that perhaps you really are two people anyway.  Or even three or four (or a
dozen in your case).  There is a psychological term for folks like you!!!

;-)


John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
Fuller
Sent: Tuesday, November 13, 2007 8:18 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] merging records

Given an unknown number of duplicate person records (for different polls), I
can't think offhand of a set-based way to do it (although perhaps a creative
use of COALESCE() might work). I think that the recordset approach may be
your best option. Even that approach might have problems, however. I may
have filled in one poll as Arthur Fuller and another as Arthur B. Fuller.

A.

On 11/13/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
> I have tables of information about people.  The tables represent polls 
> that people have taken, so if a person takes a poll about brands of 
> cigarettes smoked, the table would have a record about that person for 
> that poll.  If that same person took a poll about software used, the 
> table would have a NEW record with information about the same person, 
> but about the software that person used.  And so forth and so on.  Now 
> I need to "roll up" all of the information about a person into a 
> single record so that one record contains all of the information about 
> that person contained in all of the records about that person in the 
> table.
>
> Is this possible directly in SQL?  Do I need to write code to iterate 
> through the table finding each person and all the records for that 
> person, and then consolidating the information from the second and 
> subsequent records into the first record found?
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
>
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From jwcolby at colbyconsulting.com  Tue Nov 13 08:22:08 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Tue, 13 Nov 2007 09:22:08 -0500
Subject: [dba-SQLServer] Compacting a data file
Message-ID: <00eb01c82600$93620830$6c7aa8c0@M90>

I made the foolish mistake of asking SQL Server to compact a large (200GB)
file using "reorganize pages".  This is a static table with about 40% empty
space and I foolishly thought this might be a good thing to do.  OK FINE, I
WAS FOOLISH ALRIGHT!  8-(

I started it last night about 6:00 pm and as of this morning at 9:17 AM it
is still chugging away.  Does anyone know whether this will actually finish
some day and further whether that someday will be today or next January?
Fast server, lots of memory, fast disk.  LOTS of CPU activity (50% of two
cores).

This is a database that I need to get some work done on.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From fuller.artful at gmail.com  Tue Nov 13 08:46:39 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Tue, 13 Nov 2007 09:46:39 -0500
Subject: [dba-SQLServer] Compacting a data file
In-Reply-To: <00eb01c82600$93620830$6c7aa8c0@M90>
References: <00eb01c82600$93620830$6c7aa8c0@M90>
Message-ID: <29f585dd0711130646j1e9e447dv982683a175780325@mail.gmail.com>

The physical size of the db is not of interest. The number of rows is the
guideline here. A "re-organize pages" operation writes the entire db to
tempdb and then creates a copy from tempdb and only when said copy is
complete does it destroy the original and rename the new copy to the
original name. Given the number of rows involved, did you expect this to
happen quickly?

A.

On 11/13/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
> I made the foolish mistake of asking SQL Server to compact a large (200GB)
> file using "reorganize pages".  This is a static table with about 40%
> empty
> space and I foolishly thought this might be a good thing to do.  OK FINE,
> I
> WAS FOOLISH ALRIGHT!  8-(
>
> I started it last night about 6:00 pm and as of this morning at 9:17 AM it
> is still chugging away.  Does anyone know whether this will actually
> finish
> some day and further whether that someday will be today or next January?
> Fast server, lots of memory, fast disk.  LOTS of CPU activity (50% of two
> cores).
>
> This is a database that I need to get some work done on.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


From jwcolby at colbyconsulting.com  Tue Nov 13 09:07:16 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Tue, 13 Nov 2007 10:07:16 -0500
Subject: [dba-SQLServer] Compacting a data file
In-Reply-To: <29f585dd0711130646j1e9e447dv982683a175780325@mail.gmail.com>
References: <00eb01c82600$93620830$6c7aa8c0@M90>
	<29f585dd0711130646j1e9e447dv982683a175780325@mail.gmail.com>
Message-ID: <00ef01c82606$e1a2a0d0$6c7aa8c0@M90>

>Given the number of rows involved, did you expect this to happen quickly?

LOL.  YES!  I pumped raw caffeine into the caffeine port on the front of the
computer.

Seriously though, I see no sign that is happening.  AFAICT the temp file is
out on my C: drive (which has plenty of room) and it is only about 28 mb
right now and not changing size.  In fact the main data file and log file
are likewise not varying in size.  So what is this thing doing?  The shrink
database dialog is still up and the little indicator says activity is
happening.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
Fuller
Sent: Tuesday, November 13, 2007 9:47 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Compacting a data file

The physical size of the db is not of interest. The number of rows is the
guideline here. A "re-organize pages" operation writes the entire db to
tempdb and then creates a copy from tempdb and only when said copy is
complete does it destroy the original and rename the new copy to the
original name. Given the number of rows involved, did you expect this to
happen quickly?

A.

On 11/13/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
> I made the foolish mistake of asking SQL Server to compact a large 
> (200GB) file using "reorganize pages".  This is a static table with 
> about 40% empty space and I foolishly thought this might be a good 
> thing to do.  OK FINE, I WAS FOOLISH ALRIGHT!  8-(
>
> I started it last night about 6:00 pm and as of this morning at 9:17 
> AM it is still chugging away.  Does anyone know whether this will 
> actually finish some day and further whether that someday will be 
> today or next January?
> Fast server, lots of memory, fast disk.  LOTS of CPU activity (50% of 
> two cores).
>
> This is a database that I need to get some work done on.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From robert at webedb.com  Tue Nov 13 09:21:29 2007
From: robert at webedb.com (Robert L. Stewart)
Date: Tue, 13 Nov 2007 09:21:29 -0600
Subject: [dba-SQLServer] Performance of a unique index
In-Reply-To: <mailman.2929.1194966453.29181.dba-sqlserver@databaseadviso
	rs.com>
References: <mailman.2929.1194966453.29181.dba-sqlserver@databaseadvisors.com>
Message-ID: <200711131525.lADFPSqY012614@databaseadvisors.com>

The fastest index is the clustered index.

At 09:07 AM 11/13/2007, you wrote:
>Date: Tue, 13 Nov 2007 06:29:23 -0500
>From: "jwcolby" <jwcolby at colbyconsulting.com>
>Subject: [dba-SQLServer] Performance of a unique index
>To: <dba-sqlserver at databaseadvisors.com>
>Message-ID: <00d801c825e8$715c8bb0$6c7aa8c0 at M90>
>Content-Type: text/plain;       charset="us-ascii"
>
>Are there any performance implications for a unique index, pro or con?  I
>have tables where no data is added after the tables are set up.  Are unique
>indexes faster than non-unique?  Are they slower?  No difference?  I do not
>need the capability to enforce uniqueness since the tables are completely
>static so I want the fastest index.
>
>John W. Colby




From markamatte at hotmail.com  Tue Nov 13 09:26:14 2007
From: markamatte at hotmail.com (Mark A Matte)
Date: Tue, 13 Nov 2007 15:26:14 +0000
Subject: [dba-SQLServer] Compacting a data file
In-Reply-To: <00ef01c82606$e1a2a0d0$6c7aa8c0@M90>
References: <00eb01c82600$93620830$6c7aa8c0@M90>
	<29f585dd0711130646j1e9e447dv982683a175780325@mail.gmail.com> 
	<00ef01c82606$e1a2a0d0$6c7aa8c0@M90>
Message-ID: <BAY127-W297A3BBB6EE5289801CEF6D2800@phx.gbl>


Personally, I would check task manager...to determine if anything is happening...memory usage specifically.

Just a thought...

As I've mentioned before...I have a friend who works with the same type and size of datasets...and a 12 to 20 hour rebuild of a db is not unheard of.


Best of luck,

Mark

> From: jwcolby at colbyconsulting.com
> To: dba-sqlserver at databaseadvisors.com
> Date: Tue, 13 Nov 2007 10:07:16 -0500
> Subject: Re: [dba-SQLServer] Compacting a data file
>
>>Given the number of rows involved, did you expect this to happen quickly?
>
> LOL. YES! I pumped raw caffeine into the caffeine port on the front of the
> computer.
>
> Seriously though, I see no sign that is happening. AFAICT the temp file is
> out on my C: drive (which has plenty of room) and it is only about 28 mb
> right now and not changing size. In fact the main data file and log file
> are likewise not varying in size. So what is this thing doing? The shrink
> database dialog is still up and the little indicator says activity is
> happening.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
> Fuller
> Sent: Tuesday, November 13, 2007 9:47 AM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] Compacting a data file
>
> The physical size of the db is not of interest. The number of rows is the
> guideline here. A "re-organize pages" operation writes the entire db to
> tempdb and then creates a copy from tempdb and only when said copy is
> complete does it destroy the original and rename the new copy to the
> original name. Given the number of rows involved, did you expect this to
> happen quickly?
>
> A.
>
> On 11/13/07, jwcolby  wrote:
>>
>> I made the foolish mistake of asking SQL Server to compact a large
>> (200GB) file using "reorganize pages". This is a static table with
>> about 40% empty space and I foolishly thought this might be a good
>> thing to do. OK FINE, I WAS FOOLISH ALRIGHT! 8-(
>>
>> I started it last night about 6:00 pm and as of this morning at 9:17
>> AM it is still chugging away. Does anyone know whether this will
>> actually finish some day and further whether that someday will be
>> today or next January?
>> Fast server, lots of memory, fast disk. LOTS of CPU activity (50% of
>> two cores).
>>
>> This is a database that I need to get some work done on.
>>
>> John W. Colby
>> Colby Consulting
>> www.ColbyConsulting.com
>>
>> _______________________________________________
>> dba-SQLServer mailing list
>> dba-SQLServer at databaseadvisors.com
>> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>> http://www.databaseadvisors.com
>>
>>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>

_________________________________________________________________
Boo!?Scare away worms, viruses and so much more! Try Windows Live OneCare!
http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews


From fuller.artful at gmail.com  Tue Nov 13 09:43:07 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Tue, 13 Nov 2007 10:43:07 -0500
Subject: [dba-SQLServer] Performance of a unique index
In-Reply-To: <200711131525.lADFPSqY012614@databaseadvisors.com>
References: <mailman.2929.1194966453.29181.dba-sqlserver@databaseadvisors.com>
	<200711131525.lADFPSqY012614@databaseadvisors.com>
Message-ID: <29f585dd0711130743t24e96d40qc9068057872e34ed@mail.gmail.com>

This is correct, and is due to the fact that creating a clustered index
physically resorts the table into the sequence specified by the key.
Although, JC, be aware that this is going to take a while, given the size of
your table.

A.

On 11/13/07, Robert L. Stewart <robert at webedb.com> wrote:
>
> The fastest index is the clustered index.
>


From jwcolby at colbyconsulting.com  Tue Nov 13 10:12:17 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Tue, 13 Nov 2007 11:12:17 -0500
Subject: [dba-SQLServer] Performance of a unique index
In-Reply-To: <29f585dd0711130743t24e96d40qc9068057872e34ed@mail.gmail.com>
References: <mailman.2929.1194966453.29181.dba-sqlserver@databaseadvisors.com><200711131525.lADFPSqY012614@databaseadvisors.com>
	<29f585dd0711130743t24e96d40qc9068057872e34ed@mail.gmail.com>
Message-ID: <000001c8260f$f7341650$6c7aa8c0@M90>

> The fastest index is the clustered index.

And in fact it missed the point of my question.  An index can be unique or
not unique.  I am asking specifically about these two things, not anything
else.  I have tables with DOZENS of indexes.  There can be only one
clustered index and I don't have any on these tables or it is on the PKID
(created by SQL Server when I created the PKID field and made it the PK). 

So I am really not interested in what is the FASTEST index in the universe,
simply in whether there is ANY difference in speed between a unique index
and a non unique index.  IOW should I make all of my indexes UNIQUE because
they are faster, or should I make all of my indexes NON UNIQUE because they
are fastest or should I not care because they are equal speed.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
Fuller
Sent: Tuesday, November 13, 2007 10:43 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Performance of a unique index

This is correct, and is due to the fact that creating a clustered index
physically resorts the table into the sequence specified by the key.
Although, JC, be aware that this is going to take a while, given the size of
your table.

A.

On 11/13/07, Robert L. Stewart <robert at webedb.com> wrote:
>
> The fastest index is the clustered index.
>
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From jwcolby at colbyconsulting.com  Tue Nov 13 10:12:59 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Tue, 13 Nov 2007 11:12:59 -0500
Subject: [dba-SQLServer] Compacting a data file
In-Reply-To: <BAY127-W297A3BBB6EE5289801CEF6D2800@phx.gbl>
References: <00eb01c82600$93620830$6c7aa8c0@M90><29f585dd0711130646j1e9e447dv982683a175780325@mail.gmail.com>
	<00ef01c82606$e1a2a0d0$6c7aa8c0@M90>
	<BAY127-W297A3BBB6EE5289801CEF6D2800@phx.gbl>
Message-ID: <000101c82610$0f5cc790$6c7aa8c0@M90>

Yep, I did that.  SQL Server is using ~50% of the processor time and ~1.7 gb
of memory.  It is chugging away doing something. 


John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Mark A
Matte
Sent: Tuesday, November 13, 2007 10:26 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Compacting a data file


Personally, I would check task manager...to determine if anything is
happening...memory usage specifically.

Just a thought...

As I've mentioned before...I have a friend who works with the same type and
size of datasets...and a 12 to 20 hour rebuild of a db is not unheard of.


Best of luck,

Mark

> From: jwcolby at colbyconsulting.com
> To: dba-sqlserver at databaseadvisors.com
> Date: Tue, 13 Nov 2007 10:07:16 -0500
> Subject: Re: [dba-SQLServer] Compacting a data file
>
>>Given the number of rows involved, did you expect this to happen quickly?
>
> LOL. YES! I pumped raw caffeine into the caffeine port on the front of 
> the computer.
>
> Seriously though, I see no sign that is happening. AFAICT the temp 
> file is out on my C: drive (which has plenty of room) and it is only 
> about 28 mb right now and not changing size. In fact the main data 
> file and log file are likewise not varying in size. So what is this 
> thing doing? The shrink database dialog is still up and the little 
> indicator says activity is happening.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of 
> Arthur Fuller
> Sent: Tuesday, November 13, 2007 9:47 AM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] Compacting a data file
>
> The physical size of the db is not of interest. The number of rows is 
> the guideline here. A "re-organize pages" operation writes the entire 
> db to tempdb and then creates a copy from tempdb and only when said 
> copy is complete does it destroy the original and rename the new copy 
> to the original name. Given the number of rows involved, did you 
> expect this to happen quickly?
>
> A.
>
> On 11/13/07, jwcolby  wrote:
>>
>> I made the foolish mistake of asking SQL Server to compact a large
>> (200GB) file using "reorganize pages". This is a static table with 
>> about 40% empty space and I foolishly thought this might be a good 
>> thing to do. OK FINE, I WAS FOOLISH ALRIGHT! 8-(
>>
>> I started it last night about 6:00 pm and as of this morning at 9:17 
>> AM it is still chugging away. Does anyone know whether this will 
>> actually finish some day and further whether that someday will be 
>> today or next January?
>> Fast server, lots of memory, fast disk. LOTS of CPU activity (50% of 
>> two cores).
>>
>> This is a database that I need to get some work done on.
>>
>> John W. Colby
>> Colby Consulting
>> www.ColbyConsulting.com
>>
>> _______________________________________________
>> dba-SQLServer mailing list
>> dba-SQLServer at databaseadvisors.com
>> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>> http://www.databaseadvisors.com
>>
>>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>

_________________________________________________________________
Boo!?Scare away worms, viruses and so much more! Try Windows Live OneCare!
http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailn
ews
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com




From jwcolby at colbyconsulting.com  Tue Nov 13 11:25:09 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Tue, 13 Nov 2007 12:25:09 -0500
Subject: [dba-SQLServer] Query builder
Message-ID: <001201c8261a$24ba3f50$6c7aa8c0@M90>

My client is asking if there is a tool I can buy to make me more productive
in building the queries for the analysis he is asking me to do.  Just a
quick Google of "SQL Server query generator"  gets me these:

http://www.querytool.com/?gclid=COXT2a-i2o8CFQNlHgodhSWX1Q
http://sqlmanager.net/products/tools/querybuilder
http://www.activequerybuilder.com/

Has anyone ever used any of these or have any recommendations for other
tools like these?

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From jwcolby at colbyconsulting.com  Tue Nov 13 14:13:43 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Tue, 13 Nov 2007 15:13:43 -0500
Subject: [dba-SQLServer] 4 Core cpu
Message-ID: <000401c82631$b1463340$6c7aa8c0@M90>

Does anyone out there have a quad core processor?  I am interested in how
the 4 cores work with SQL Server specifically.  I can tell you that moving
to a dual core made a huge difference in "response time" for allowing me to
do things simultaneously in SQL Server.  I am running a compact database (I
think / hope) and am also able to run queries, build indexes on other
databases etc.  I am just wondering how it looks with a quad core?

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From fhtapia at gmail.com  Tue Nov 13 16:45:28 2007
From: fhtapia at gmail.com (Francisco Tapia)
Date: Tue, 13 Nov 2007 14:45:28 -0800
Subject: [dba-SQLServer] Query builder
In-Reply-To: <001201c8261a$24ba3f50$6c7aa8c0@M90>
References: <001201c8261a$24ba3f50$6c7aa8c0@M90>
Message-ID: <b874372a0711131445j7ddde1b0m411b186dcb9413f8@mail.gmail.com>

If you're looking for tools I would check out the toolbelt from Red-Gate
software
http://www.red-gate.com/index.htm

For standardizing your existing code you can use the sql refractor tool, but
to build new queries quickly with intellisense-like technology, then use
sql-prompt. I really do enjoy this tool. (I do have this and sql-compare
plus sql backup from red gate, they tend to really put out quality software


On Nov 13, 2007 9:25 AM, jwcolby <jwcolby at colbyconsulting.com> wrote:

> My client is asking if there is a tool I can buy to make me more
> productive
> in building the queries for the analysis he is asking me to do.  Just a
> quick Google of "SQL Server query generator"  gets me these:
>
> http://www.querytool.com/?gclid=COXT2a-i2o8CFQNlHgodhSWX1Q
> http://sqlmanager.net/products/tools/querybuilder
> http://www.activequerybuilder.com/
>
> Has anyone ever used any of these or have any recommendations for other
> tools like these?
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


-- 
-Francisco
http://sqlthis.blogspot.com | Tsql and More...


From fuller.artful at gmail.com  Tue Nov 13 17:12:08 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Tue, 13 Nov 2007 18:12:08 -0500
Subject: [dba-SQLServer] Query builder
In-Reply-To: <b874372a0711131445j7ddde1b0m411b186dcb9413f8@mail.gmail.com>
References: <001201c8261a$24ba3f50$6c7aa8c0@M90>
	<b874372a0711131445j7ddde1b0m411b186dcb9413f8@mail.gmail.com>
Message-ID: <29f585dd0711131512h6b2f8697sdf9ed32a744d52b1@mail.gmail.com>

Red-Gate's Toolbelt is a fantastic package for a reasonable price. Also
check out the Apex toolset, available for less money but not quite as
full-featured (getting closer and closer, though).

A.

On 11/13/07, Francisco Tapia <fhtapia at gmail.com> wrote:
>
> If you're looking for tools I would check out the toolbelt from Red-Gate
> software
> http://www.red-gate.com/index.htm
>
> For standardizing your existing code you can use the sql refractor tool,
> but
> to build new queries quickly with intellisense-like technology, then use
> sql-prompt. I really do enjoy this tool. (I do have this and sql-compare
> plus sql backup from red gate, they tend to really put out quality
> software
>
>
>


From john at winhaven.net  Tue Nov 13 18:04:28 2007
From: john at winhaven.net (John Bartow)
Date: Tue, 13 Nov 2007 18:04:28 -0600
Subject: [dba-SQLServer] Show users for SQLServer
Message-ID: <200711140005.lAE05k7q003517@databaseadvisors.com>

Whats the quickest way to tell if someone is accessing a SQL Server DE DB on
the local PC?
 


From michael at ddisolutions.com.au  Tue Nov 13 18:53:03 2007
From: michael at ddisolutions.com.au (Michael Maddison)
Date: Wed, 14 Nov 2007 11:53:03 +1100
Subject: [dba-SQLServer] Performance of a unique index
References: <mailman.2929.1194966453.29181.dba-sqlserver@databaseadvisors.com><200711131525.lADFPSqY012614@databaseadvisors.com><29f585dd0711130743t24e96d40qc9068057872e34ed@mail.gmail.com>
	<000001c8260f$f7341650$6c7aa8c0@M90>
Message-ID: <59A61174B1F5B54B97FD4ADDE71E7D0128A081@ddi-01.DDI.local>

John,

Hi John,

BOL doesn't help, mentions nothing about performance and unique indexes.

This guy says unique indexes improve performance.
http://drsql.spaces.live.com/blog/cns!80677FB08B3162E4!1187.entry

However, in general its unlikely you would be able to make all your
indexes unique ;-)

How good are you getting at reading execution plans?

cheers


Michael M

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Wednesday, 14 November 2007 3:12 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Performance of a unique index

> The fastest index is the clustered index.

And in fact it missed the point of my question.  An index can be unique
or not unique.  I am asking specifically about these two things, not
anything else.  I have tables with DOZENS of indexes.  There can be only
one clustered index and I don't have any on these tables or it is on the
PKID (created by SQL Server when I created the PKID field and made it
the PK). 

So I am really not interested in what is the FASTEST index in the
universe, simply in whether there is ANY difference in speed between a
unique index and a non unique index.  IOW should I make all of my
indexes UNIQUE because they are faster, or should I make all of my
indexes NON UNIQUE because they are fastest or should I not care because
they are equal speed.

John W. Colby
Colby Consulting
www.ColbyConsulting.com
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
Fuller
Sent: Tuesday, November 13, 2007 10:43 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Performance of a unique index

This is correct, and is due to the fact that creating a clustered index
physically resorts the table into the sequence specified by the key.
Although, JC, be aware that this is going to take a while, given the
size of your table.

A.

On 11/13/07, Robert L. Stewart <robert at webedb.com> wrote:
>
> The fastest index is the clustered index.
>
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com




From michael at ddisolutions.com.au  Tue Nov 13 18:55:37 2007
From: michael at ddisolutions.com.au (Michael Maddison)
Date: Wed, 14 Nov 2007 11:55:37 +1100
Subject: [dba-SQLServer] Show users for SQLServer
References: <200711140005.lAE05k7q003517@databaseadvisors.com>
Message-ID: <59A61174B1F5B54B97FD4ADDE71E7D0128A082@ddi-01.DDI.local>

Look at current activity in EM? 


Michael M


This Email message is for the sole use of the intended recipient and may
contain confidential and privileged information. Any unauthorised
review, use, disclosure or distribution is prohibited. If you are not
the intended recipient, please contact the sender by reply Email and
destroy all copies as well as the original message. All views expressed
in this Email are those of the sender, except where specifically stated
otherwise, and do not necessarily reflect the views of DDi Solutions.
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of John
Bartow
Sent: Wednesday, 14 November 2007 11:04 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] Show users for SQLServer

Whats the quickest way to tell if someone is accessing a SQL Server DE
DB on the local PC?
 
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com




From jwcolby at colbyconsulting.com  Tue Nov 13 19:59:30 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Tue, 13 Nov 2007 20:59:30 -0500
Subject: [dba-SQLServer] Performance of a unique index
In-Reply-To: <59A61174B1F5B54B97FD4ADDE71E7D0128A081@ddi-01.DDI.local>
References: <mailman.2929.1194966453.29181.dba-sqlserver@databaseadvisors.com><200711131525.lADFPSqY012614@databaseadvisors.com><29f585dd0711130743t24e96d40qc9068057872e34ed@mail.gmail.com><000001c8260f$f7341650$6c7aa8c0@M90>
	<59A61174B1F5B54B97FD4ADDE71E7D0128A081@ddi-01.DDI.local>
Message-ID: <000a01c82661$ffd9b4c0$6c7aa8c0@M90>

>However, in general its unlikely you would be able to make all your indexes
unique ;-)

LOL, of course you are right there. 


John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Michael
Maddison
Sent: Tuesday, November 13, 2007 7:53 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Performance of a unique index

John,

Hi John,

BOL doesn't help, mentions nothing about performance and unique indexes.

This guy says unique indexes improve performance.
http://drsql.spaces.live.com/blog/cns!80677FB08B3162E4!1187.entry

However, in general its unlikely you would be able to make all your indexes
unique ;-)

How good are you getting at reading execution plans?

cheers


Michael M

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Wednesday, 14 November 2007 3:12 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Performance of a unique index

> The fastest index is the clustered index.

And in fact it missed the point of my question.  An index can be unique or
not unique.  I am asking specifically about these two things, not anything
else.  I have tables with DOZENS of indexes.  There can be only one
clustered index and I don't have any on these tables or it is on the PKID
(created by SQL Server when I created the PKID field and made it the PK). 

So I am really not interested in what is the FASTEST index in the universe,
simply in whether there is ANY difference in speed between a unique index
and a non unique index.  IOW should I make all of my indexes UNIQUE because
they are faster, or should I make all of my indexes NON UNIQUE because they
are fastest or should I not care because they are equal speed.

John W. Colby
Colby Consulting
www.ColbyConsulting.com
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
Fuller
Sent: Tuesday, November 13, 2007 10:43 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Performance of a unique index

This is correct, and is due to the fact that creating a clustered index
physically resorts the table into the sequence specified by the key.
Although, JC, be aware that this is going to take a while, given the size of
your table.

A.

On 11/13/07, Robert L. Stewart <robert at webedb.com> wrote:
>
> The fastest index is the clustered index.
>
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com


_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From darrend at nimble.com.au  Tue Nov 13 23:11:54 2007
From: darrend at nimble.com.au (Darren)
Date: Wed, 14 Nov 2007 16:11:54 +1100
Subject: [dba-SQLServer] Show users for SQLServer
In-Reply-To: <200711140005.lAE05k7q003517@databaseadvisors.com>
Message-ID: <200711140512.lAE5C8vA031668@databaseadvisors.com>

Hi John

See if this is any good for you it works form QA - Assuming you have access

You can write a wrapper in DAO and return the results - though don't ask me
about that :-)

select count(*)as 'NoOfProcesses' from master.dbo.sysprocesses
--Unrem the line below for specific dBs
--where dbid = db_id('YourdBNameHere') 

select distinct loginame from master.dbo.sysprocesses
where
--Unrem the line below for specific Users
-- loginame = 'userloginnamehere' and 
--Unrem the line below for specific Users
dbid = db_id(' YourdBNameHere ')

See ya

DD
-----Original Message-----
From: John Bartow [mailto:john at winhaven.net] 
Sent: Wednesday, 14 November 2007 11:04 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] Show users for SQLServer

Whats the quickest way to tell if someone is accessing a SQL Server DE DB on
the local PC?
 
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From jwcolby at colbyconsulting.com  Wed Nov 14 07:19:50 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Wed, 14 Nov 2007 08:19:50 -0500
Subject: [dba-SQLServer] Performance of a unique index
In-Reply-To: <59A61174B1F5B54B97FD4ADDE71E7D0128A081@ddi-01.DDI.local>
References: <mailman.2929.1194966453.29181.dba-sqlserver@databaseadvisors.com><200711131525.lADFPSqY012614@databaseadvisors.com><29f585dd0711130743t24e96d40qc9068057872e34ed@mail.gmail.com><000001c8260f$f7341650$6c7aa8c0@M90>
	<59A61174B1F5B54B97FD4ADDE71E7D0128A081@ddi-01.DDI.local>
Message-ID: <001f01c826c1$09fe8d40$6c7aa8c0@M90>

An interesting explanation.  Thanks. 


John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Michael
Maddison
Sent: Tuesday, November 13, 2007 7:53 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Performance of a unique index

John,

Hi John,

BOL doesn't help, mentions nothing about performance and unique indexes.

This guy says unique indexes improve performance.
http://drsql.spaces.live.com/blog/cns!80677FB08B3162E4!1187.entry

However, in general its unlikely you would be able to make all your indexes
unique ;-)

How good are you getting at reading execution plans?

cheers


Michael M

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Wednesday, 14 November 2007 3:12 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Performance of a unique index

> The fastest index is the clustered index.

And in fact it missed the point of my question.  An index can be unique or
not unique.  I am asking specifically about these two things, not anything
else.  I have tables with DOZENS of indexes.  There can be only one
clustered index and I don't have any on these tables or it is on the PKID
(created by SQL Server when I created the PKID field and made it the PK). 

So I am really not interested in what is the FASTEST index in the universe,
simply in whether there is ANY difference in speed between a unique index
and a non unique index.  IOW should I make all of my indexes UNIQUE because
they are faster, or should I make all of my indexes NON UNIQUE because they
are fastest or should I not care because they are equal speed.

John W. Colby
Colby Consulting
www.ColbyConsulting.com
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
Fuller
Sent: Tuesday, November 13, 2007 10:43 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Performance of a unique index

This is correct, and is due to the fact that creating a clustered index
physically resorts the table into the sequence specified by the key.
Although, JC, be aware that this is going to take a while, given the size of
your table.

A.

On 11/13/07, Robert L. Stewart <robert at webedb.com> wrote:
>
> The fastest index is the clustered index.
>
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com


_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From rsigmond at comcast.net  Wed Nov 14 09:55:59 2007
From: rsigmond at comcast.net (Randy Sigmond)
Date: Wed, 14 Nov 2007 10:55:59 -0500
Subject: [dba-SQLServer] SQL RunTime/Performance (newbie)
In-Reply-To: <001f01c826c1$09fe8d40$6c7aa8c0@M90>
Message-ID: <200711141556.lAEFuE0N030969@databaseadvisors.com>

John,

This might not be the proper format, but I have not posted in a very, very
long time and I cannot seem to find out how to post a question. So here it
goes.

I have been sitting on the wings learning from all of the emails that
receive from DBAdvisors.com and now I have a question of my own.

I am looking for some guidance on a couple of issues.

	1. SQL Performance Metrics
      2. SQL Run-Time Metrics

My current situation is calling for the identification and resolution to
track and increase an instance of SQL.

If you can assist I would be eternally grateful.

Randy Sigmond
Restech Online
www.restechonline.com



-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Wednesday, November 14, 2007 8:20 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Performance of a unique index

An interesting explanation.  Thanks. 


John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Michael
Maddison
Sent: Tuesday, November 13, 2007 7:53 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Performance of a unique index

John,

Hi John,

BOL doesn't help, mentions nothing about performance and unique indexes.

This guy says unique indexes improve performance.
http://drsql.spaces.live.com/blog/cns!80677FB08B3162E4!1187.entry

However, in general its unlikely you would be able to make all your indexes
unique ;-)

How good are you getting at reading execution plans?

cheers


Michael M

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Wednesday, 14 November 2007 3:12 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Performance of a unique index

> The fastest index is the clustered index.

And in fact it missed the point of my question.  An index can be unique or
not unique.  I am asking specifically about these two things, not anything
else.  I have tables with DOZENS of indexes.  There can be only one
clustered index and I don't have any on these tables or it is on the PKID
(created by SQL Server when I created the PKID field and made it the PK). 

So I am really not interested in what is the FASTEST index in the universe,
simply in whether there is ANY difference in speed between a unique index
and a non unique index.  IOW should I make all of my indexes UNIQUE because
they are faster, or should I make all of my indexes NON UNIQUE because they
are fastest or should I not care because they are equal speed.

John W. Colby
Colby Consulting
www.ColbyConsulting.com
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
Fuller
Sent: Tuesday, November 13, 2007 10:43 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Performance of a unique index

This is correct, and is due to the fact that creating a clustered index
physically resorts the table into the sequence specified by the key.
Although, JC, be aware that this is going to take a while, given the size of
your table.

A.

On 11/13/07, Robert L. Stewart <robert at webedb.com> wrote:
>
> The fastest index is the clustered index.
>
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com


_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com





From jwcolby at colbyconsulting.com  Wed Nov 14 10:10:17 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Wed, 14 Nov 2007 11:10:17 -0500
Subject: [dba-SQLServer] SQL RunTime/Performance (newbie)
In-Reply-To: <200711141556.lAEFuE0N030969@databaseadvisors.com>
References: <001f01c826c1$09fe8d40$6c7aa8c0@M90>
	<200711141556.lAEFuE0N030969@databaseadvisors.com>
Message-ID: <002f01c826d8$d952e8e0$6c7aa8c0@M90>

Randy,

First let me say that I am a relative nubee to SQL Server and am probably
not the one to ask for help.  Since you posted your question to the forum,
anyone who can help will pipe up. 

Second, I don't really understand your question. 

What does this mean?

>the identification and resolution to track and increase an instance of SQL.

I do know that there are tools for looking at the pieces and parts of SQL
Server, disk usage processor usage and the like.  I do not know how to do
that stuff myself without going searching for it.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Randy
Sigmond
Sent: Wednesday, November 14, 2007 10:56 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] SQL RunTime/Performance (newbie)

John,

This might not be the proper format, but I have not posted in a very, very
long time and I cannot seem to find out how to post a question. So here it
goes.

I have been sitting on the wings learning from all of the emails that
receive from DBAdvisors.com and now I have a question of my own.

I am looking for some guidance on a couple of issues.

	1. SQL Performance Metrics
      2. SQL Run-Time Metrics

My current situation is calling for the identification and resolution to
track and increase an instance of SQL.

If you can assist I would be eternally grateful.

Randy Sigmond
Restech Online
www.restechonline.com



-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Wednesday, November 14, 2007 8:20 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Performance of a unique index

An interesting explanation.  Thanks. 


John W. Colby
Colby Consulting
www.ColbyConsulting.com
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Michael
Maddison
Sent: Tuesday, November 13, 2007 7:53 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Performance of a unique index

John,

Hi John,

BOL doesn't help, mentions nothing about performance and unique indexes.

This guy says unique indexes improve performance.
http://drsql.spaces.live.com/blog/cns!80677FB08B3162E4!1187.entry

However, in general its unlikely you would be able to make all your indexes
unique ;-)

How good are you getting at reading execution plans?

cheers


Michael M

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Wednesday, 14 November 2007 3:12 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Performance of a unique index

> The fastest index is the clustered index.

And in fact it missed the point of my question.  An index can be unique or
not unique.  I am asking specifically about these two things, not anything
else.  I have tables with DOZENS of indexes.  There can be only one
clustered index and I don't have any on these tables or it is on the PKID
(created by SQL Server when I created the PKID field and made it the PK). 

So I am really not interested in what is the FASTEST index in the universe,
simply in whether there is ANY difference in speed between a unique index
and a non unique index.  IOW should I make all of my indexes UNIQUE because
they are faster, or should I make all of my indexes NON UNIQUE because they
are fastest or should I not care because they are equal speed.

John W. Colby
Colby Consulting
www.ColbyConsulting.com
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
Fuller
Sent: Tuesday, November 13, 2007 10:43 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Performance of a unique index

This is correct, and is due to the fact that creating a clustered index
physically resorts the table into the sequence specified by the key.
Although, JC, be aware that this is going to take a while, given the size of
your table.

A.

On 11/13/07, Robert L. Stewart <robert at webedb.com> wrote:
>
> The fastest index is the clustered index.
>
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com


_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From fuller.artful at gmail.com  Wed Nov 14 10:22:04 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Wed, 14 Nov 2007 11:22:04 -0500
Subject: [dba-SQLServer] SQL RunTime/Performance (newbie)
In-Reply-To: <200711141556.lAEFuE0N030969@databaseadvisors.com>
References: <001f01c826c1$09fe8d40$6c7aa8c0@M90>
	<200711141556.lAEFuE0N030969@databaseadvisors.com>
Message-ID: <29f585dd0711140822g3f1e4ef9lc798ba35ba4c8cde@mail.gmail.com>

Hi Randy,

First, to pose a question, just send a new email addressed to
dba-sqlserver at databaseadvisors.com. Give it a subject appropriate to the
question, click Send and wait for answers.

Second, here are a few URLs to read:

http://www.sql-server-performance.com/articles/per/tuning_for_executives_p1.aspx
http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1185283,00.html
http://msdn2.microsoft.com/en-us/library/ms189081.aspx

hth,
Arthur

On 11/14/07, Randy Sigmond <rsigmond at comcast.net> wrote:
>
> John,
>
> This might not be the proper format, but I have not posted in a very, very
> long time and I cannot seem to find out how to post a question. So here it
> goes.
>
> I have been sitting on the wings learning from all of the emails that
> receive from DBAdvisors.com and now I have a question of my own.
>
> I am looking for some guidance on a couple of issues.
>
>         1. SQL Performance Metrics
>       2. SQL Run-Time Metrics
>
>
>


From rsigmond at comcast.net  Wed Nov 14 11:29:52 2007
From: rsigmond at comcast.net (Randy Sigmond)
Date: Wed, 14 Nov 2007 12:29:52 -0500
Subject: [dba-SQLServer] SQL RunTime/Performance (newbie)
In-Reply-To: <29f585dd0711140822g3f1e4ef9lc798ba35ba4c8cde@mail.gmail.com>
Message-ID: <200711141730.lAEHU87k020037@databaseadvisors.com>

John,

The goal of my exercise is to capture run-time/performance information
remotely from SQL and extract (via Store Procedures or Dynamic Views) the
information into a local database for analysis.  This will provide a status
of the server and allow for the identification of problem areas that can
then be handled on the remote server.

Arthur,

Thanks for the links, but do you know of any specific (sp or dmv) that you
know of that will provide run-time information. Being relatively new to SQL
I am still struggling with the understanding of run-time environment.

Any help would be greatly appreciated.

Randy Sigmond



-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
Fuller
Sent: Wednesday, November 14, 2007 11:22 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] SQL RunTime/Performance (newbie)

Hi Randy,

First, to pose a question, just send a new email addressed to
dba-sqlserver at databaseadvisors.com. Give it a subject appropriate to the
question, click Send and wait for answers.

Second, here are a few URLs to read:

http://www.sql-server-performance.com/articles/per/tuning_for_executives_p1.
aspx
http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1185283,00.html
http://msdn2.microsoft.com/en-us/library/ms189081.aspx

hth,
Arthur

On 11/14/07, Randy Sigmond <rsigmond at comcast.net> wrote:
>
> John,
>
> This might not be the proper format, but I have not posted in a very, very
> long time and I cannot seem to find out how to post a question. So here it
> goes.
>
> I have been sitting on the wings learning from all of the emails that
> receive from DBAdvisors.com and now I have a question of my own.
>
> I am looking for some guidance on a couple of issues.
>
>         1. SQL Performance Metrics
>       2. SQL Run-Time Metrics
>
>
>
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com





From fhtapia at gmail.com  Wed Nov 14 12:16:16 2007
From: fhtapia at gmail.com (Francisco Tapia)
Date: Wed, 14 Nov 2007 10:16:16 -0800
Subject: [dba-SQLServer] SQL RunTime/Performance (newbie)
In-Reply-To: <200711141730.lAEHU87k020037@databaseadvisors.com>
References: <29f585dd0711140822g3f1e4ef9lc798ba35ba4c8cde@mail.gmail.com>
	<200711141730.lAEHU87k020037@databaseadvisors.com>
Message-ID: <b874372a0711141016q49910c7ava87c25d9abba6473@mail.gmail.com>

for capturing metrics you can download Idera's Diagnostic manager wich runs
on another server, then it simply runs sql statments to find the metrics you
are looking for, I would run a sql trace and capture these during your trial
period.  I personnallly just use their product as it provides a very useful
GUI to view all my problematic Sql Server instances.  Not to mention this
helps me find tables that need defragging and schedule such tasks for after
hours.

hope this helps

(www.idera.com)

If you don't want to install 3rd party software, there are scripts you can
find on www.sqlservercentral.com that will provide you with the data you
need, also I'd take a look at www.dbajournal.com for more useful
articles/scrpts to gather the information that you want.

--
Francisco

On Nov 14, 2007 9:29 AM, Randy Sigmond <rsigmond at comcast.net> wrote:

> John,
>
> The goal of my exercise is to capture run-time/performance information
> remotely from SQL and extract (via Store Procedures or Dynamic Views) the
> information into a local database for analysis.  This will provide a
> status
> of the server and allow for the identification of problem areas that can
> then be handled on the remote server.
>
> Arthur,
>
> Thanks for the links, but do you know of any specific (sp or dmv) that you
> know of that will provide run-time information. Being relatively new to
> SQL
> I am still struggling with the understanding of run-time environment.
>
> Any help would be greatly appreciated.
>
> Randy Sigmond
>
>
>
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
> Fuller
> Sent: Wednesday, November 14, 2007 11:22 AM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] SQL RunTime/Performance (newbie)
>
> Hi Randy,
>
> First, to pose a question, just send a new email addressed to
> dba-sqlserver at databaseadvisors.com. Give it a subject appropriate to the
> question, click Send and wait for answers.
>
> Second, here are a few URLs to read:
>
>
> http://www.sql-server-performance.com/articles/per/tuning_for_executives_p1
> .
> aspx
>
> http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1185283,00.html
> http://msdn2.microsoft.com/en-us/library/ms189081.aspx
>
> hth,
> Arthur
>
> On 11/14/07, Randy Sigmond <rsigmond at comcast.net> wrote:
> >
> > John,
> >
> > This might not be the proper format, but I have not posted in a very,
> very
> > long time and I cannot seem to find out how to post a question. So here
> it
> > goes.
> >
> > I have been sitting on the wings learning from all of the emails that
> > receive from DBAdvisors.com and now I have a question of my own.
> >
> > I am looking for some guidance on a couple of issues.
> >
> >         1. SQL Performance Metrics
> >       2. SQL Run-Time Metrics
> >
> >
> >
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


-- 
-Francisco
http://sqlthis.blogspot.com | Tsql and More...


From rsigmond at comcast.net  Wed Nov 14 13:46:29 2007
From: rsigmond at comcast.net (Randy Sigmond)
Date: Wed, 14 Nov 2007 14:46:29 -0500
Subject: [dba-SQLServer] SQL RunTime/Performance (newbie)
In-Reply-To: <b874372a0711141016q49910c7ava87c25d9abba6473@mail.gmail.com>
Message-ID: <200711141947.lAEJlkMl029177@databaseadvisors.com>

Francisco,

Thanks for the info.

Randy


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Francisco
Tapia
Sent: Wednesday, November 14, 2007 1:16 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] SQL RunTime/Performance (newbie)

for capturing metrics you can download Idera's Diagnostic manager wich runs
on another server, then it simply runs sql statments to find the metrics you
are looking for, I would run a sql trace and capture these during your trial
period.  I personnallly just use their product as it provides a very useful
GUI to view all my problematic Sql Server instances.  Not to mention this
helps me find tables that need defragging and schedule such tasks for after
hours.

hope this helps

(www.idera.com)

If you don't want to install 3rd party software, there are scripts you can
find on www.sqlservercentral.com that will provide you with the data you
need, also I'd take a look at www.dbajournal.com for more useful
articles/scrpts to gather the information that you want.

--
Francisco

On Nov 14, 2007 9:29 AM, Randy Sigmond <rsigmond at comcast.net> wrote:

> John,
>
> The goal of my exercise is to capture run-time/performance information
> remotely from SQL and extract (via Store Procedures or Dynamic Views) the
> information into a local database for analysis.  This will provide a
> status
> of the server and allow for the identification of problem areas that can
> then be handled on the remote server.
>
> Arthur,
>
> Thanks for the links, but do you know of any specific (sp or dmv) that you
> know of that will provide run-time information. Being relatively new to
> SQL
> I am still struggling with the understanding of run-time environment.
>
> Any help would be greatly appreciated.
>
> Randy Sigmond
>
>
>
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
> Fuller
> Sent: Wednesday, November 14, 2007 11:22 AM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] SQL RunTime/Performance (newbie)
>
> Hi Randy,
>
> First, to pose a question, just send a new email addressed to
> dba-sqlserver at databaseadvisors.com. Give it a subject appropriate to the
> question, click Send and wait for answers.
>
> Second, here are a few URLs to read:
>
>
>
http://www.sql-server-performance.com/articles/per/tuning_for_executives_p1
> .
> aspx
>
>
http://searchsqlserver.techtarget.com/tip/0,289483,sid87_gci1185283,00.html
> http://msdn2.microsoft.com/en-us/library/ms189081.aspx
>
> hth,
> Arthur
>
> On 11/14/07, Randy Sigmond <rsigmond at comcast.net> wrote:
> >
> > John,
> >
> > This might not be the proper format, but I have not posted in a very,
> very
> > long time and I cannot seem to find out how to post a question. So here
> it
> > goes.
> >
> > I have been sitting on the wings learning from all of the emails that
> > receive from DBAdvisors.com and now I have a question of my own.
> >
> > I am looking for some guidance on a couple of issues.
> >
> >         1. SQL Performance Metrics
> >       2. SQL Run-Time Metrics
> >
> >
> >
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


-- 
-Francisco
http://sqlthis.blogspot.com | Tsql and More...
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com





From jwcolby at colbyconsulting.com  Thu Nov 15 05:39:43 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Thu, 15 Nov 2007 06:39:43 -0500
Subject: [dba-SQLServer] What's happening here
Message-ID: <008401c8277c$37f28dd0$6c7aa8c0@M90>

I am trying to copy data from a table in one db to a table in another db,
same server.  To move 100K records takes 5 seconds.  To move 400K records
takes 2 minutes and counting.  Why is 4 times as much data taking 30 (PLUS!)
times longer

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From fhtapia at gmail.com  Thu Nov 15 17:30:53 2007
From: fhtapia at gmail.com (Francisco Tapia)
Date: Thu, 15 Nov 2007 15:30:53 -0800
Subject: [dba-SQLServer] What's happening here
In-Reply-To: <008401c8277c$37f28dd0$6c7aa8c0@M90>
References: <008401c8277c$37f28dd0$6c7aa8c0@M90>
Message-ID: <b874372a0711151530y303ce6c0u5ae0306277141231@mail.gmail.com>

What does the destination table look like?  How many indexes do you have?,
where is the database files physically located, if on the same channel then
you may have a throughput problem.  I would use the monitor tool and observe
what the disk I/O looks like while you're doing these loads.  It may also be
that 100K records load to ram then to disk where as 400k is too big.

On Nov 15, 2007 3:39 AM, jwcolby <jwcolby at colbyconsulting.com> wrote:

> I am trying to copy data from a table in one db to a table in another db,
> same server.  To move 100K records takes 5 seconds.  To move 400K records
> takes 2 minutes and counting.  Why is 4 times as much data taking 30
> (PLUS!)
> times longer
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


-- 
-Francisco
http://sqlthis.blogspot.com | Tsql and More...


From jwcolby at colbyconsulting.com  Fri Nov 16 07:30:19 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Fri, 16 Nov 2007 08:30:19 -0500
Subject: [dba-SQLServer] Grouping values in crosstab
Message-ID: <002101c82854$d5b1c3a0$6c7aa8c0@M90>

You might remember I asked if it is possible to group values in a field
directly in a crosstab.

For example a crosstab of length of boat by state where you group 7-15 the
count of the values (lengths) in a crosstab column called 7 to 15.  Well...
I tried it directly in the crosstab.

SELECT St as USState, [7,8,9,10,11,12,13,14] as '7 To 14'
FROM(
SELECT     IR3863.dbo.vBaseBoatLength.St,
IR3863.dbo.vBaseBoatLength.Boat_Length_4_through_50_feet
FROM       IR3863.dbo.vBaseBoatLength ) tmpBoatLength
PIVOT 
(
COUNT(tmpBoatLength.Boat_Length_4_through_50_feet)
FOR tmpBoatLength.Boat_Length_4_through_50_feet IN([7,8,9,10,11,12,13,14]))
AS tmpBL
ORDER BY USState

vBaseBoatLength pulls the ST and Boat_Length_4_through_50_feet fields.

The query did not complain and is currently running.  I will report back
when I get the counts, which I will then cross check against a simple
count() where IN() query, but it certainly looks like it might be working.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From jwcolby at colbyconsulting.com  Mon Nov 19 13:29:13 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Mon, 19 Nov 2007 14:29:13 -0500
Subject: [dba-SQLServer] Action Pack Subscribers
Message-ID: <00d101c82ae2$784fcb90$6c7aa8c0@M90>

For those of you doing Web stuff I just found this:

https://partner.microsoft.com/us/40047166

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From jwcolby at colbyconsulting.com  Wed Nov 21 15:04:53 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Wed, 21 Nov 2007 16:04:53 -0500
Subject: [dba-SQLServer] Optimizing queries with in() - SQL Server 2005
Message-ID: <00b401c82c82$29e9d4e0$6c7aa8c0@M90>

I have a lot of queries where I have to look for multiple values.  I have
been using an IN() clause but I am advised that is very slow.  OTOH I built
two queries that use an IN() in one query and a bunch of ORs in the other
and over a 56 million record table they were both so fast I couldn't see the
difference (Indexed column, containing values 1-9 and A-T (under 2 sec)

Any comments?

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From dwaters at usinternet.com  Wed Nov 21 16:24:40 2007
From: dwaters at usinternet.com (Dan Waters)
Date: Wed, 21 Nov 2007 16:24:40 -0600
Subject: [dba-SQLServer] Optimizing queries with in() - SQL Server 2005
In-Reply-To: <00b401c82c82$29e9d4e0$6c7aa8c0@M90>
Message-ID: <20071121222504.E51BF25743@smtp-out-01.usinternet.com>

John,

>From what I remember (and have done) the use of an IN clause is the same as
a sub query (or sequential queries).

I have heard that a NOT IN clause is slow because all values must be
compared against the NOT IN list.  

Dan

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Wednesday, November 21, 2007 3:05 PM
To: dba-sqlserver at databaseadvisors.com; 'Access Developers discussion and
problem solving'
Subject: [dba-SQLServer] Optimizing queries with in() - SQL Server 2005

I have a lot of queries where I have to look for multiple values.  I have
been using an IN() clause but I am advised that is very slow.  OTOH I built
two queries that use an IN() in one query and a bunch of ORs in the other
and over a 56 million record table they were both so fast I couldn't see the
difference (Indexed column, containing values 1-9 and A-T (under 2 sec)

Any comments?

John W. Colby
Colby Consulting
www.ColbyConsulting.com 

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From jwcolby at colbyconsulting.com  Fri Nov 23 09:56:10 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Fri, 23 Nov 2007 10:56:10 -0500
Subject: [dba-SQLServer] SQL Server 2005 - View to table
Message-ID: <001b01c82de9$5e840780$6c7aa8c0@M90>

In processing orders for "the big database" I often end up with some rather
complex queries, which take a loooong time to complete (> 30 minutes) and
results in a small number of records (anywhere from a few million to tens of
thousands) pulled from a large records set (50 million).  In any case, it is
usually helpful to pull the resulting data into a table for a variety of
reasons, starting with the fact that I need to be able to sort.
Additionally I need to be able to select a subset of THOSE records, perhaps
just 10K of the possible records, and TRACK which records were already used.

So, I am trying to use the export wizard to use the vOrder view as the
source, and send the data to a tblOrder in the SAME SQL Server database.
IOW I build a database for each order, build up the views using data from
tables out in other databases, then build a final view that "puts it all
together", and finally save the result set to a table in the order database.


It seems like it should work, and in fact it seems to be trying to work, but
is currently hung on "setting source connection".  Who knows, it may be
trying to run the query, and in 1/2 hour when that is completed, it may
march onwards.  

My question, is this a valid thing to do?  SQL Server should be able to
handle this right?  Is there a better way to do this?

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From fuller.artful at gmail.com  Fri Nov 23 10:23:28 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Fri, 23 Nov 2007 11:23:28 -0500
Subject: [dba-SQLServer] SQL Server 2005 - View to table
In-Reply-To: <001b01c82de9$5e840780$6c7aa8c0@M90>
References: <001b01c82de9$5e840780$6c7aa8c0@M90>
Message-ID: <29f585dd0711230823h477b4ee3hd9eb56f466a82deb@mail.gmail.com>

Um, why not just SELECT INTO newTable FROM viewName?

Arthur

On 11/23/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
> In processing orders for "the big database" I often end up with some
> rather
> complex queries, which take a loooong time to complete (> 30 minutes) and
> results in a small number of records (anywhere from a few million to tens
> of
> thousands) pulled from a large records set (50 million).  In any case, it
> is
> usually helpful to pull the resulting data into a table for a variety of
> reasons, starting with the fact that I need to be able to sort.
> Additionally I need to be able to select a subset of THOSE records,
> perhaps
> just 10K of the possible records, and TRACK which records were already
> used.
>
> So, I am trying to use the export wizard to use the vOrder view as the
> source, and send the data to a tblOrder in the SAME SQL Server database.
> IOW I build a database for each order, build up the views using data from
> tables out in other databases, then build a final view that "puts it all
> together", and finally save the result set to a table in the order
> database.
>
>
> It seems like it should work, and in fact it seems to be trying to work,
> but
> is currently hung on "setting source connection".  Who knows, it may be
> trying to run the query, and in 1/2 hour when that is completed, it may
> march onwards.
>
> My question, is this a valid thing to do?  SQL Server should be able to
> handle this right?  Is there a better way to do this?
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


From jwcolby at colbyconsulting.com  Fri Nov 23 11:04:22 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Fri, 23 Nov 2007 12:04:22 -0500
Subject: [dba-SQLServer] SQL Server 2005 - View to table
In-Reply-To: <29f585dd0711230823h477b4ee3hd9eb56f466a82deb@mail.gmail.com>
References: <001b01c82de9$5e840780$6c7aa8c0@M90>
	<29f585dd0711230823h477b4ee3hd9eb56f466a82deb@mail.gmail.com>
Message-ID: <002001c82df2$e5b97010$6c7aa8c0@M90>

Indeed why not?  The only real reason is that newTable does not exist yet
and I would have to create it by hand. 


John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
Fuller
Sent: Friday, November 23, 2007 11:23 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] SQL Server 2005 - View to table

Um, why not just SELECT INTO newTable FROM viewName?

Arthur



From fuller.artful at gmail.com  Fri Nov 23 11:08:04 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Fri, 23 Nov 2007 12:08:04 -0500
Subject: [dba-SQLServer] SQL Server 2005 - View to table
In-Reply-To: <002001c82df2$e5b97010$6c7aa8c0@M90>
References: <001b01c82de9$5e840780$6c7aa8c0@M90>
	<29f585dd0711230823h477b4ee3hd9eb56f466a82deb@mail.gmail.com>
	<002001c82df2$e5b97010$6c7aa8c0@M90>
Message-ID: <29f585dd0711230908g50c10d86ld758b8764ff2a7e1@mail.gmail.com>

No you wouldn't! SELECT INTO creates the table.

On 11/23/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
> Indeed why not?  The only real reason is that newTable does not exist yet
> and I would have to create it by hand.
>
>


From jwcolby at colbyconsulting.com  Fri Nov 23 11:15:17 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Fri, 23 Nov 2007 12:15:17 -0500
Subject: [dba-SQLServer] SQL Server 2005 - View to table
In-Reply-To: <29f585dd0711230908g50c10d86ld758b8764ff2a7e1@mail.gmail.com>
References: <001b01c82de9$5e840780$6c7aa8c0@M90><29f585dd0711230823h477b4ee3hd9eb56f466a82deb@mail.gmail.com><002001c82df2$e5b97010$6c7aa8c0@M90>
	<29f585dd0711230908g50c10d86ld758b8764ff2a7e1@mail.gmail.com>
Message-ID: <002101c82df4$6bdfac30$6c7aa8c0@M90>

With the same datatypes and widths?  The things I should know before I do
this job.  ;-) 


John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
Fuller
Sent: Friday, November 23, 2007 12:08 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] SQL Server 2005 - View to table

No you wouldn't! SELECT INTO creates the table.

On 11/23/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
> Indeed why not?  The only real reason is that newTable does not exist 
> yet and I would have to create it by hand.
>
>
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From jwcolby at colbyconsulting.com  Fri Nov 23 11:18:45 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Fri, 23 Nov 2007 12:18:45 -0500
Subject: [dba-SQLServer] SQL Server 2005 - Set default data types
In-Reply-To: <29f585dd0711230908g50c10d86ld758b8764ff2a7e1@mail.gmail.com>
References: <001b01c82de9$5e840780$6c7aa8c0@M90><29f585dd0711230823h477b4ee3hd9eb56f466a82deb@mail.gmail.com><002001c82df2$e5b97010$6c7aa8c0@M90>
	<29f585dd0711230908g50c10d86ld758b8764ff2a7e1@mail.gmail.com>
Message-ID: <002201c82df4$e7d7aa40$6c7aa8c0@M90>

 Is there a way to set the defaults for data types in SQL Server 2005 when
creating tables.  IOW, if I set a column to char() can I make it Char(1)
instead of Char(10)?  If so how?


John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
Fuller
Sent: Friday, November 23, 2007 12:08 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] SQL Server 2005 - View to table

No you wouldn't! SELECT INTO creates the table.

On 11/23/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
> Indeed why not?  The only real reason is that newTable does not exist 
> yet and I would have to create it by hand.
>
>
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From fuller.artful at gmail.com  Fri Nov 23 12:55:21 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Fri, 23 Nov 2007 13:55:21 -0500
Subject: [dba-SQLServer] SQL Server 2005 - View to table
In-Reply-To: <002101c82df4$6bdfac30$6c7aa8c0@M90>
References: <001b01c82de9$5e840780$6c7aa8c0@M90>
	<29f585dd0711230823h477b4ee3hd9eb56f466a82deb@mail.gmail.com>
	<002001c82df2$e5b97010$6c7aa8c0@M90>
	<29f585dd0711230908g50c10d86ld758b8764ff2a7e1@mail.gmail.com>
	<002101c82df4$6bdfac30$6c7aa8c0@M90>
Message-ID: <29f585dd0711231055p1fd77220sce2fd8fbadf0f2a1@mail.gmail.com>

Yepper.

On 11/23/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
> With the same datatypes and widths?  The things I should know before I do
> this job.  ;-)
>


From fuller.artful at gmail.com  Fri Nov 23 14:12:00 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Fri, 23 Nov 2007 15:12:00 -0500
Subject: [dba-SQLServer] SQL Server 2005 - Set default data types
In-Reply-To: <002201c82df4$e7d7aa40$6c7aa8c0@M90>
References: <001b01c82de9$5e840780$6c7aa8c0@M90>
	<29f585dd0711230823h477b4ee3hd9eb56f466a82deb@mail.gmail.com>
	<002001c82df2$e5b97010$6c7aa8c0@M90>
	<29f585dd0711230908g50c10d86ld758b8764ff2a7e1@mail.gmail.com>
	<002201c82df4$e7d7aa40$6c7aa8c0@M90>
Message-ID: <29f585dd0711231212l5206cfen921efc1394ae85@mail.gmail.com>

To my knowledge, there are two ways, one costing money and the other not.

I have ranted about the first approach before, but I'll rant again. Tools
such as ERwin, PowerDesigner, DeZign and so on incorporate the concept of
Domains. Think of a domain as a column spec that is not tied to a table.
Once you've defined a few of these, then when defining tables you can use
said Domains as if they were a native data type. This is fantastic. You can,
for example, redefine a domain to be char(50) from varchar(100) and then
regenerate the db with all occurrences of said domain automatically
converting.

The no-fee way to do this is to modify the modeldb database that is
installed and from which all subsequent dbs are modelled. Thus its name. You
can create a table herein that contains lots of various column definitions,
right down to all their various specs. That table will get created in every
subsequent db you create. From there, you can go into Modify (said table),
select a row of interest, copy and paste it into your table of real
interest. This is a clumsy but free way to achieve what you want.

As for me, I prefer to pay the money and get the right design tools. My
personal favourite is PowerDesigner, but in the past several jobs I've had,
ERwin was the order of the day, so the fact is that I have become more adept
at ERwin than at PowerDesigner. I will say this: I wouldn't even dream of
designing a db comprising more than 20 tables without such a tool in hand,
and the more tables the more I adhere to this principle. I've done some
rather large designs involving 500 or so tables, and anyone who would try
this without such a tool in hand is IMO in need of a new profession.

Scaling this notion down to strictly Access MDB back-ends, I hold to the
principle that a false table should be created that contains all the
foreign-key specs and simple column specs for all the tables. For example,
the false table could contain a column called CustomerID, that is a
combo-box with two columns, the first width being zero, the caption reading
"Customer" and so on. Spend a lot of time on this false table. Define
everything that you can. Thereafter, for every new table you create you can
open the false table in design mode, select the relevant columns for any new
table, copy and paste. Do it once, then inherit.

Admittedly, this no-charge approach is a tad clumsy, and revisions to the
false domains don't automatically cascade, which is the reason why I so
ardently believe in tools such as PowerDesigner, ERwin and DeZign. They make
the db revisions effortless. Imagine 30 occurrences of a domain called Name
(in Products, in Customers, in Vendors, and so on). Change the domain
definition to varchar(50) and regen the db and every occurrence is updated.
That is power. Change a phone-number spec in every table from char(10) to
varchar(20) in one swoop. Yes!

This is not to slight the "change modeldb" approach. I have written about
this (c.f. TechRepublic.com) and it's especially effective if you're a
freelancer who does relatively similar apps over and over. (I.e. your apps
all have tables called Customers, Orders, OrderDetails and Products).
Thoroughly define them once, place them in modeldb, and then every
subsequent db you create will inherit these definitions. Of course you can
delete the irrelevant ones and modify the saved ones to suit the immediate
problem.

The Domains facility just takes this concept one level deeper. You can
define columns for re-use, rather than just tables.

Arthur

On 11/23/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
> Is there a way to set the defaults for data types in SQL Server 2005 when
> creating tables.  IOW, if I set a column to char() can I make it Char(1)
> instead of Char(10)?  If so how?
>
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
> Fuller
> Sent: Friday, November 23, 2007 12:08 PM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] SQL Server 2005 - View to table
>
> No you wouldn't! SELECT INTO creates the table.
>
> On 11/23/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
> >
> > Indeed why not?  The only real reason is that newTable does not exist
> > yet and I would have to create it by hand.
> >
> >
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


From jwcolby at colbyconsulting.com  Fri Nov 23 14:27:28 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Fri, 23 Nov 2007 15:27:28 -0500
Subject: [dba-SQLServer] SQL Server 2005 - Set default data types
In-Reply-To: <29f585dd0711231212l5206cfen921efc1394ae85@mail.gmail.com>
References: <001b01c82de9$5e840780$6c7aa8c0@M90><29f585dd0711230823h477b4ee3hd9eb56f466a82deb@mail.gmail.com><002001c82df2$e5b97010$6c7aa8c0@M90><29f585dd0711230908g50c10d86ld758b8764ff2a7e1@mail.gmail.com><002201c82df4$e7d7aa40$6c7aa8c0@M90>
	<29f585dd0711231212l5206cfen921efc1394ae85@mail.gmail.com>
Message-ID: <003201c82e0f$44de36e0$6c7aa8c0@M90>

I do love to hear you rant Arthur!

;-) 


John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
Fuller
Sent: Friday, November 23, 2007 3:12 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] SQL Server 2005 - Set default data types

To my knowledge, there are two ways, one costing money and the other not.

I have ranted about the first approach before, but I'll rant again. Tools
such as ERwin, PowerDesigner, DeZign and so on incorporate the concept of
Domains. Think of a domain as a column spec that is not tied to a table.
Once you've defined a few of these, then when defining tables you can use
said Domains as if they were a native data type. This is fantastic. You can,
for example, redefine a domain to be char(50) from varchar(100) and then
regenerate the db with all occurrences of said domain automatically
converting.

The no-fee way to do this is to modify the modeldb database that is
installed and from which all subsequent dbs are modelled. Thus its name. You
can create a table herein that contains lots of various column definitions,
right down to all their various specs. That table will get created in every
subsequent db you create. From there, you can go into Modify (said table),
select a row of interest, copy and paste it into your table of real
interest. This is a clumsy but free way to achieve what you want.

As for me, I prefer to pay the money and get the right design tools. My
personal favourite is PowerDesigner, but in the past several jobs I've had,
ERwin was the order of the day, so the fact is that I have become more adept
at ERwin than at PowerDesigner. I will say this: I wouldn't even dream of
designing a db comprising more than 20 tables without such a tool in hand,
and the more tables the more I adhere to this principle. I've done some
rather large designs involving 500 or so tables, and anyone who would try
this without such a tool in hand is IMO in need of a new profession.

Scaling this notion down to strictly Access MDB back-ends, I hold to the
principle that a false table should be created that contains all the
foreign-key specs and simple column specs for all the tables. For example,
the false table could contain a column called CustomerID, that is a
combo-box with two columns, the first width being zero, the caption reading
"Customer" and so on. Spend a lot of time on this false table. Define
everything that you can. Thereafter, for every new table you create you can
open the false table in design mode, select the relevant columns for any new
table, copy and paste. Do it once, then inherit.

Admittedly, this no-charge approach is a tad clumsy, and revisions to the
false domains don't automatically cascade, which is the reason why I so
ardently believe in tools such as PowerDesigner, ERwin and DeZign. They make
the db revisions effortless. Imagine 30 occurrences of a domain called Name
(in Products, in Customers, in Vendors, and so on). Change the domain
definition to varchar(50) and regen the db and every occurrence is updated.
That is power. Change a phone-number spec in every table from char(10) to
varchar(20) in one swoop. Yes!

This is not to slight the "change modeldb" approach. I have written about
this (c.f. TechRepublic.com) and it's especially effective if you're a
freelancer who does relatively similar apps over and over. (I.e. your apps
all have tables called Customers, Orders, OrderDetails and Products).
Thoroughly define them once, place them in modeldb, and then every
subsequent db you create will inherit these definitions. Of course you can
delete the irrelevant ones and modify the saved ones to suit the immediate
problem.

The Domains facility just takes this concept one level deeper. You can
define columns for re-use, rather than just tables.

Arthur

On 11/23/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
> Is there a way to set the defaults for data types in SQL Server 2005 
> when creating tables.  IOW, if I set a column to char() can I make it 
> Char(1) instead of Char(10)?  If so how?
>
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of 
> Arthur Fuller
> Sent: Friday, November 23, 2007 12:08 PM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] SQL Server 2005 - View to table
>
> No you wouldn't! SELECT INTO creates the table.
>
> On 11/23/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
> >
> > Indeed why not?  The only real reason is that newTable does not 
> > exist yet and I would have to create it by hand.
> >
> >
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From fuller.artful at gmail.com  Fri Nov 23 14:33:48 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Fri, 23 Nov 2007 15:33:48 -0500
Subject: [dba-SQLServer] SQL Server 2005 - Set default data types
In-Reply-To: <003201c82e0f$44de36e0$6c7aa8c0@M90>
References: <001b01c82de9$5e840780$6c7aa8c0@M90>
	<29f585dd0711230823h477b4ee3hd9eb56f466a82deb@mail.gmail.com>
	<002001c82df2$e5b97010$6c7aa8c0@M90>
	<29f585dd0711230908g50c10d86ld758b8764ff2a7e1@mail.gmail.com>
	<002201c82df4$e7d7aa40$6c7aa8c0@M90>
	<29f585dd0711231212l5206cfen921efc1394ae85@mail.gmail.com>
	<003201c82e0f$44de36e0$6c7aa8c0@M90>
Message-ID: <29f585dd0711231233v18e59f64y7b32e7122a27bb80@mail.gmail.com>

Oh! One more thing. If you decide to remodel modeldb, then make a backup!
Call it _modeldb or whatever, but you want to ensure that your remodelling
does not get overwritten by any subsequent update.

A.

On 11/23/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
> I do love to hear you rant Arthur!
>
> ;-)
>


From fuller.artful at gmail.com  Mon Nov 26 11:35:32 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Mon, 26 Nov 2007 12:35:32 -0500
Subject: [dba-SQLServer] November Katmai CTP
Message-ID: <29f585dd0711260935n5b6eb17id322638d87ff8a72@mail.gmail.com>

Has anyone on this list succeeded in installing this? I've now failed on two
machines, trying to install it side-by-side with SQL 2005, and no go. I'm
now going to try removing SQL 2005 and then installing SQL 2008 (Katmai) and
see if that works. I think I have wasted about three days thus far trying to
make this work, and I'm not talking 8-hour days. I am growing increasingly
frustrated.

A.


From ssharkins at gmail.com  Mon Nov 26 12:52:31 2007
From: ssharkins at gmail.com (Susan Harkins)
Date: Mon, 26 Nov 2007 13:52:31 -0500
Subject: [dba-SQLServer] November Katmai CTP
References: <29f585dd0711260935n5b6eb17id322638d87ff8a72@mail.gmail.com>
Message-ID: <009d01c8305d$8171cdb0$4b3a8343@SusanOne>

Arthur, does the documentation say it's Okay to install it on the same 
system? I don't even try anymore -- SQL Server versions/betas are so picky 
that I just don't even try.

Susan H.


> Has anyone on this list succeeded in installing this? I've now failed on 
> two
> machines, trying to install it side-by-side with SQL 2005, and no go. I'm
> now going to try removing SQL 2005 and then installing SQL 2008 (Katmai) 
> and
> see if that works. I think I have wasted about three days thus far trying 
> to
> make this work, and I'm not talking 8-hour days. I am growing increasingly
> frustrated.
>
> A.
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
> 



From jwcolby at colbyconsulting.com  Wed Nov 28 19:07:03 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Wed, 28 Nov 2007 20:07:03 -0500
Subject: [dba-SQLServer] Covering Indexes
Message-ID: <011801c83224$27d4ad40$647aa8c0@M90>

I need to understand covering indexes.  One of my databases has fields such
as 

PresenceOfChildren_00_02
PresenceOfChildren_03_05
PresenceOfChildren_06_10

Etc.  Thus what I need to know is do I need an individual index on each
field?  I get requests for data using selection criteria on just one, and
also sometimes on more than one of these fields.  If I have an index on all
of these fields together, will that help a query with selection criteria for
a single one of these fields?  On 3 out of 7 of these fields etc?

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From michael at ddisolutions.com.au  Wed Nov 28 19:45:35 2007
From: michael at ddisolutions.com.au (Michael Maddison)
Date: Thu, 29 Nov 2007 12:45:35 +1100
Subject: [dba-SQLServer] Covering Indexes
References: <011801c83224$27d4ad40$647aa8c0@M90>
Message-ID: <59A61174B1F5B54B97FD4ADDE71E7D0128A142@ddi-01.DDI.local>

Hi John,

It depends...

I've used covering indexes occasionally but only where all participants
are used say >50% of the time. 

IIRC the covering index was used only when each field is actually used.
I think the column order was important too!

What I do do is check the execution plan for every Select statement I
run on SQL when I create it.
I try and get 100% seek action happening, either CI Seek or Seek.
In your case with your db from hell I suspect your are just going to
have to test to see what works best for each situation.

Good luck

Michael M

Subject: [dba-SQLServer] Covering Indexes

I need to understand covering indexes.  One of my databases has fields
such as 

PresenceOfChildren_00_02
PresenceOfChildren_03_05
PresenceOfChildren_06_10

Etc.  Thus what I need to know is do I need an individual index on each
field?  I get requests for data using selection criteria on just one,
and also sometimes on more than one of these fields.  If I have an index
on all of these fields together, will that help a query with selection
criteria for a single one of these fields?  On 3 out of 7 of these
fields etc?

John W. Colby
Colby Consulting
www.ColbyConsulting.com 

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com




From jwcolby at colbyconsulting.com  Wed Nov 28 20:42:02 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Wed, 28 Nov 2007 21:42:02 -0500
Subject: [dba-SQLServer] Covering Indexes - Q2
Message-ID: <011f01c83231$6cc168a0$647aa8c0@M90>

OK, so I have done a little reading on covering indexes.  Now, I have 7
"presence of adults AA to BB" fields where AA and BB are ages - 18-24, 25-34
etc.

I have many cases where the client asks for ("PresenceOfAdults_18_24 OR
PresenceOfAdults_25_34") AND NarrowIncomeBand IN('A','B','C','D') AND XXXX.
These are essentially two different select queries.

Possible strategies: 

1) TWO subqueries - 
	SELECT PKID FROM tblXXX WHERE (PresenceOfAdults_18_24 = 'Y' OR
PresenceOfAdults_25_34='Y')
	SELECT PKID FROM tblXXX WHERE NarrowIncomeBand IN('A','B','C','D')

Then JOIN the two queries on the PKID

2) One big query with the where clause handles both "subqueries".

If I want to use strategy 1, should I 

1) Create "cover queries" with the PKID and all of the PresenceOfAdults
fields in one cover query?  If so should the PKID be first or last field in
the index?
2) Create 7 different "cover queries" where the PKID and one
PresenceOfAdults field is combined.  If so should the PKID be first or last
field in the index?
3) Create 7 non cover queries containing just a single PresenceOfAdults
field.

To this point I have simply indexed each field that I want to do searches
on.  However I have situations where the client just asks for a single one
of these PresenceOfAdults fields and then other completely non-related
fields (NarrowIncomeBand, Gender, Waterski).  This stuff is taking a long
time to complete (30 minutes or even more).

I am having a tough time figuring out how to even test this stuff.  I have
not figured out the query analyzer though I am headed there.  Can I have two
different indexes using different strategies and look at the execution plan
to see whether one or the other or neither is used?

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From michael at ddisolutions.com.au  Thu Nov 29 01:11:40 2007
From: michael at ddisolutions.com.au (Michael Maddison)
Date: Thu, 29 Nov 2007 18:11:40 +1100
Subject: [dba-SQLServer] Covering Indexes - Q2
References: <011f01c83231$6cc168a0$647aa8c0@M90>
Message-ID: <59A61174B1F5B54B97FD4ADDE71E7D0128A145@ddi-01.DDI.local>

John,

QA is your friend ;-)  Go and test in QA, it's the only place you'll
likely get a definative answer.

Part of the problem is I'm guessing that most on this list are
developers not DBA's.  Your questions are leaning into the DBA realm
IMO.
The other issue is that what works on my setup may be different on
yours.  SQL will optimise sql statements based not only on
what indexes are available but # of processors, memory, # of rows, # of
joins etc etc.

'If so should the PKID be first or last field in the index?'  I've found
no benefit from using a PKID (Clustered) as part of a covering index.
I think it is redundant to do so anyway.  

Not much help I know.

Hope it goes well for you, you should be able to advertise yourself as a
SQL dba by the time you get this all down pat.

cheers


Michael M

OK, so I have done a little reading on covering indexes.  Now, I have 7
"presence of adults AA to BB" fields where AA and BB are ages - 18-24,
25-34 etc.

I have many cases where the client asks for ("PresenceOfAdults_18_24 OR
PresenceOfAdults_25_34") AND NarrowIncomeBand IN('A','B','C','D') AND
XXXX.
These are essentially two different select queries.

Possible strategies: 

1) TWO subqueries - 
	SELECT PKID FROM tblXXX WHERE (PresenceOfAdults_18_24 = 'Y' OR
PresenceOfAdults_25_34='Y')
	SELECT PKID FROM tblXXX WHERE NarrowIncomeBand
IN('A','B','C','D')

Then JOIN the two queries on the PKID

2) One big query with the where clause handles both "subqueries".

If I want to use strategy 1, should I 

1) Create "cover queries" with the PKID and all of the PresenceOfAdults
fields in one cover query?  If so should the PKID be first or last field
in the index?
2) Create 7 different "cover queries" where the PKID and one
PresenceOfAdults field is combined.  If so should the PKID be first or
last field in the index?
3) Create 7 non cover queries containing just a single PresenceOfAdults
field.

To this point I have simply indexed each field that I want to do
searches on.  However I have situations where the client just asks for a
single one of these PresenceOfAdults fields and then other completely
non-related fields (NarrowIncomeBand, Gender, Waterski).  This stuff is
taking a long time to complete (30 minutes or even more).

I am having a tough time figuring out how to even test this stuff.  I
have not figured out the query analyzer though I am headed there.  Can I
have two different indexes using different strategies and look at the
execution plan to see whether one or the other or neither is used?

John W. Colby
Colby Consulting
www.ColbyConsulting.com 

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com




From jwcolby at colbyconsulting.com  Thu Nov 29 07:17:40 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Thu, 29 Nov 2007 08:17:40 -0500
Subject: [dba-SQLServer] How are indexes built
Message-ID: <013101c8328a$38ba7ac0$647aa8c0@M90>

I am in the tail end of rebuilding the "fact table" for the big database
from hell.  Long ago Arthur managed to get me an "optimum field size" for
each of the fields.  I stripped off a ton (100?) fields out at the beginning
of the table which were very old address validation stuff, and then build a
new table without those fields, and with the rest of the fields set to
exactly the right size to fit the data - usually char(1) rather than the
default varchar(50) which the old table used.  I am now in the "index it"
phase.  Keeping in mind that this data is never updated, once the data is in
place indexes do not have to deal with the insertion problem.

One issue that I have is that in order to keep the speed up, I did not
define a PK field or any indexes before I inserted the data.  Now the data
is so huge that I cannot get it to build (designate) a PK field without a
timeout, or at least it will not work from the built in table modify wizard.
It starts chugging away and then comes back a couple of minutes later with a
timeout message and fails to complete.  So I do not have a real PK.  I do
have a field that contains the data (int) that is the number that represents
a record (the PK field), or is just not actually considered a PK by SQL
Server and I am not sure how to make SQL Server turn it into a PK.  I think
I can do so with an actual SQL statement run as a query but I will have to
research the syntax.  For some reason, SQL Server will run QUERIES to
completion, even if they take hours, but it will cause timeouts for any of
the built in wizards that attempt to modify a table, or for that matter will
time out views if they take too long.  Cut the view SQL into a query and it
will run to completion.  Obviously one of many things I do not understand
about my tool.

So... I am trying to build up indexes to help me with select WHERE clauses
for this beast.  I have discussed some of the types of where clauses I get,
IN(a,b,c,d,e) for a single field, Fld1=A and Fld2=C, etc.  In order to bring
sanity to the table and allow me to test pieces of these select queries, I
am starting to use a strategy of building sub queries to handle the pieces
of a complex where clause, and then using a JOIN for the AND.  In order to
do this I need indexes on the fields used in each sub query.  It is possible
to create cover queries where I include the PKID (field) and the field used
in the select.

I really need to build a clustered index on the PKID field (I think) since
that is what I use to actually reference the entire record, for those cases
where it has to pull data not indexed or where an index is ignored.  I will
need to do that "over the weekend" I think given the physical sort involved.
Will it have to completely rebuild all of my other indexes as well?  I
suspect so.  I really need a single SP that will drop all of my indexes and
another to rebuild all of my indexes.  Then I could just "drop the names" in
an SP and cause the whole lot to build.

I think I am going to have to join a group specializing in SQL Server in
order to get these kinds of questions answered.  Kind of a scary prospect.
I am so "developer oriented" and so ignorant about the workings of the SQL
Server innards.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From Mwp.Reid at qub.ac.uk  Thu Nov 29 07:32:13 2007
From: Mwp.Reid at qub.ac.uk (Martin W Reid)
Date: Thu, 29 Nov 2007 13:32:13 +0000
Subject: [dba-SQLServer] How are indexes built
In-Reply-To: <013101c8328a$38ba7ac0$647aa8c0@M90>
References: <013101c8328a$38ba7ac0$647aa8c0@M90>
Message-ID: <E59F7B6A13672C408C58831FF0622B31094F9788D9@EX2K7-VIRT-1.ads.qub.ac.uk>

John

You may find this useful

http://www.mssqlcity.com/Articles/Adm/index_fragmentation.htm


Martin


Martin WP Reid
Information Services
Queen's University
Riddel Hall
185 Stranmillis Road
Belfast
BT9 5EE
Tel : 02890974465
Email : mwp.reid at qub.ac.uk
________________________________________
From: dba-sqlserver-bounces at databaseadvisors.com [dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby [jwcolby at colbyconsulting.com]
Sent: 29 November 2007 13:17
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] How are indexes built

I am in the tail end of rebuilding the "fact table" for the big database
from hell.  Long ago Arthur managed to get me an "optimum field size" for
each of the fields.  I stripped off a ton (100?) fields out at the beginning
of the table which were very old address validation stuff, and then build a
new table without those fields, and with the rest of the fields set to
exactly the right size to fit the data - usually char(1) rather than the
default varchar(50) which the old table used.  I am now in the "index it"
phase.  Keeping in mind that this data is never updated, once the data is in
place indexes do not have to deal with the insertion problem.

One issue that I have is that in order to keep the speed up, I did not
define a PK field or any indexes before I inserted the data.  Now the data
is so huge that I cannot get it to build (designate) a PK field without a
timeout, or at least it will not work from the built in table modify wizard.
It starts chugging away and then comes back a couple of minutes later with a
timeout message and fails to complete.  So I do not have a real PK.  I do
have a field that contains the data (int) that is the number that represents
a record (the PK field), or is just not actually considered a PK by SQL
Server and I am not sure how to make SQL Server turn it into a PK.  I think
I can do so with an actual SQL statement run as a query but I will have to
research the syntax.  For some reason, SQL Server will run QUERIES to
completion, even if they take hours, but it will cause timeouts for any of
the built in wizards that attempt to modify a table, or for that matter will
time out views if they take too long.  Cut the view SQL into a query and it
will run to completion.  Obviously one of many things I do not understand
about my tool.

So... I am trying to build up indexes to help me with select WHERE clauses
for this beast.  I have discussed some of the types of where clauses I get,
IN(a,b,c,d,e) for a single field, Fld1=A and Fld2=C, etc.  In order to bring
sanity to the table and allow me to test pieces of these select queries, I
am starting to use a strategy of building sub queries to handle the pieces
of a complex where clause, and then using a JOIN for the AND.  In order to
do this I need indexes on the fields used in each sub query.  It is possible
to create cover queries where I include the PKID (field) and the field used
in the select.

I really need to build a clustered index on the PKID field (I think) since
that is what I use to actually reference the entire record, for those cases
where it has to pull data not indexed or where an index is ignored.  I will
need to do that "over the weekend" I think given the physical sort involved.
Will it have to completely rebuild all of my other indexes as well?  I
suspect so.  I really need a single SP that will drop all of my indexes and
another to rebuild all of my indexes.  Then I could just "drop the names" in
an SP and cause the whole lot to build.

I think I am going to have to join a group specializing in SQL Server in
order to get these kinds of questions answered.  Kind of a scary prospect.
I am so "developer oriented" and so ignorant about the workings of the SQL
Server innards.

John W. Colby
Colby Consulting
www.ColbyConsulting.com

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From fuller.artful at gmail.com  Thu Nov 29 08:02:26 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Thu, 29 Nov 2007 09:02:26 -0500
Subject: [dba-SQLServer] How are indexes built
In-Reply-To: <E59F7B6A13672C408C58831FF0622B31094F9788D9@EX2K7-VIRT-1.ads.qub.ac.uk>
References: <013101c8328a$38ba7ac0$647aa8c0@M90>
	<E59F7B6A13672C408C58831FF0622B31094F9788D9@EX2K7-VIRT-1.ads.qub.ac.uk>
Message-ID: <29f585dd0711290602o7a71a60aj8fb291ca0dc0d8f8@mail.gmail.com>

JC:

First of all, you need to understand what a clustered index is, and what it
is not. Perhaps you already know, but in case not, let me try to explain, in
perhaps simplistic terms.

Creating a clustered index physically re-orders the table according to the
order of said index. That will take a while, given the size of your table.
It will also consume (temporarily) a large amount of disk space, since it
has to re-order the table in tempdb and then write it back to yourdb.

>From what I have gathered about your app, I see not a single advantage to
your creation of a clustered index. A clustered index (again typically)
would be most useful in a compound-index situation, i.e. index on Order
Number + Order Detail Number, so gathering up the Order Details would
require minimal visits to the tables. Your case is much different than this,
and AFAIS you would gain nothing by creating a clustered index, and
conversely, lose all the time it will require to physically re-order said
table.

IMO, your largest problem is the width of the table. Whenever I detect
several hundred columns, I detect a wrong approach. We have previously
discussed this, and I hold my ground. All these columns (or at least many of
them) ought to be rows in a child table, not columns in the principal table.
Then you could creatively use indexes. Imagine a hundred columns whose
contents are Y/N/null. No point in recording the nulls; only the Y/Ns are
significant. Give all the current columns a PK and a meaningful description
in the "attributes" table, and then index said PK. Yes, this will result in
many millions of rows, one for every Y/N attribute in your big fat table.
But it will make queries such as attribute A + attribute B + attribute C -
attribute D much simpler. This would translate in the new scheme to an
EXISTS and a NOT EXISTS clause, and since all this could be handled by the
index, relatively few disk hits would be required (relative to the
full-table scans your current model requires for almost every query).

I know you receive new records occasionally, and porting said new records to
this model will involve creating new rows in said child table and then
populating them with the PK from the user, the PK from the new attribute,
and the immediate value.

I would vastly prefer going down that road to the full-table-scan scenarios
you are currently locked into.

Arthur

On 11/29/07, Martin W Reid <Mwp.Reid at qub.ac.uk> wrote:
>
> John
>
> You may find this useful
>
> http://www.mssqlcity.com/Articles/Adm/index_fragmentation.htm
>
>
> Martin
>
>
> Martin WP Reid
> Information Services
> Queen's University
> Riddel Hall
> 185 Stranmillis Road
> Belfast
> BT9 5EE
> Tel : 02890974465
> Email : mwp.reid at qub.ac.uk
> ________________________________________
> From: dba-sqlserver-bounces at databaseadvisors.com [
> dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby [
> jwcolby at colbyconsulting.com]
> Sent: 29 November 2007 13:17
> To: dba-sqlserver at databaseadvisors.com
> Subject: [dba-SQLServer] How are indexes built
>
> I am in the tail end of rebuilding the "fact table" for the big database
> from hell.  Long ago Arthur managed to get me an "optimum field size" for
> each of the fields.  I stripped off a ton (100?) fields out at the
> beginning
> of the table which were very old address validation stuff, and then build
> a
> new table without those fields, and with the rest of the fields set to
> exactly the right size to fit the data - usually char(1) rather than the
> default varchar(50) which the old table used.  I am now in the "index it"
> phase.  Keeping in mind that this data is never updated, once the data is
> in
> place indexes do not have to deal with the insertion problem.
>
> One issue that I have is that in order to keep the speed up, I did not
> define a PK field or any indexes before I inserted the data.  Now the data
> is so huge that I cannot get it to build (designate) a PK field without a
> timeout, or at least it will not work from the built in table modify
> wizard.
> It starts chugging away and then comes back a couple of minutes later with
> a
> timeout message and fails to complete.  So I do not have a real PK.  I do
> have a field that contains the data (int) that is the number that
> represents
> a record (the PK field), or is just not actually considered a PK by SQL
> Server and I am not sure how to make SQL Server turn it into a PK.  I
> think
> I can do so with an actual SQL statement run as a query but I will have to
> research the syntax.  For some reason, SQL Server will run QUERIES to
> completion, even if they take hours, but it will cause timeouts for any of
> the built in wizards that attempt to modify a table, or for that matter
> will
> time out views if they take too long.  Cut the view SQL into a query and
> it
> will run to completion.  Obviously one of many things I do not understand
> about my tool.
>
> So... I am trying to build up indexes to help me with select WHERE clauses
> for this beast.  I have discussed some of the types of where clauses I
> get,
> IN(a,b,c,d,e) for a single field, Fld1=A and Fld2=C, etc.  In order to
> bring
> sanity to the table and allow me to test pieces of these select queries, I
> am starting to use a strategy of building sub queries to handle the pieces
> of a complex where clause, and then using a JOIN for the AND.  In order to
> do this I need indexes on the fields used in each sub query.  It is
> possible
> to create cover queries where I include the PKID (field) and the field
> used
> in the select.
>
> I really need to build a clustered index on the PKID field (I think) since
> that is what I use to actually reference the entire record, for those
> cases
> where it has to pull data not indexed or where an index is ignored.  I
> will
> need to do that "over the weekend" I think given the physical sort
> involved.
> Will it have to completely rebuild all of my other indexes as well?  I
> suspect so.  I really need a single SP that will drop all of my indexes
> and
> another to rebuild all of my indexes.  Then I could just "drop the names"
> in
> an SP and cause the whole lot to build.
>
> I think I am going to have to join a group specializing in SQL Server in
> order to get these kinds of questions answered.  Kind of a scary prospect.
> I am so "developer oriented" and so ignorant about the workings of the SQL
> Server innards.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


From jwcolby at colbyconsulting.com  Thu Nov 29 09:25:10 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Thu, 29 Nov 2007 10:25:10 -0500
Subject: [dba-SQLServer] How are indexes built
In-Reply-To: <29f585dd0711290602o7a71a60aj8fb291ca0dc0d8f8@mail.gmail.com>
References: <013101c8328a$38ba7ac0$647aa8c0@M90><E59F7B6A13672C408C58831FF0622B31094F9788D9@EX2K7-VIRT-1.ads.qub.ac.uk>
	<29f585dd0711290602o7a71a60aj8fb291ca0dc0d8f8@mail.gmail.com>
Message-ID: <013e01c8329c$084c1530$647aa8c0@M90>

Arthur,

First of all thanks for the response.  

First of all some terminology.  

1) HSIDRaw is the original HSID file (database from hell) as imported from
the text files provided by the client.  Roughly 65 million records.
2) AZHSID is a table created by pulling the name / address AND PKID from
HSID Raw.  That data was sent out for address validation processing (AccuZip
- thus AZXXX).  The data returned from address validation is guaranteed
deliverable addresses, plus some additional data fields having to do with
the address validation process.  Roughly 51 million records after deleting
the undeliverable records.  NOTICE that the records in AZHSID have all of
the valid ADDRESS information but none of the SELECTION data.  HSIDRaw has
all of the valid SELECTION data but none of the valid ADDRESS data.  

In order to perform the whole process, I use HSIDRaw to pull fields for
selection, INCLUDING the PKID field.  I perform selections and get a
resulting PKID set from HSIDRaw which is "the records selected".  I then
join that result set to HSIDRaw in order to: 

a) narrow down to just the records with valid deliverable addresses (for
counts).
b) Pull valid deliverable ADDRESS information should this be a real order
for addresses.

Thus the two tables work together to form a unified whole system

To address your points:

>From what I have gathered about your app, I see not a single advantage to
your creation of a clustered index. 

1) A clustered index (from my understanding) is a physical order by the PK
as you explained, in this case the "autonumber" int field set up originally
on HSIDRaw.  That PK is then used in AZHSID to allow joining back to HSIDRaw
when required.  My understanding is that the clustered index has the entire
record in it (all of the fields), thus once you find the record you "are
there" and can go get data from any field.  This would be helpful in any
case where the field of interest is not indexed separately.  Obviously with
hundreds of fields, not every field will have indexes.  So the "advantage"
would be in those cases where the individual field did not have an index buy
a where is being performed on that field.  Or so it would seem.

>IMO, your largest problem is the width of the table. Whenever I detect
several hundred columns, I detect a wrong approach.

2) Yes, and obviously.  Unfortunately it is beyond my power to correct this.
You and I did discuss moving this out to a "normalized" system where each
field of each column is just a record in a single table.  I agree that this
would likely allow a huge performance increase, unfortunately it is beyond
my capabilities to perform this normalization.

>I know you receive new records occasionally

3) No in fact these tables NEVER!!! change (OK I do have one table that I
get updates to).  These are data tables that I got years ago, imported them
to SQL Server, and have only ever USED since the import.  So I do NOT update
HSIDRaw, it is carved in stone.  AZHSID will be updated, but that is the
address table, not the "fact (SELECTION) table".

4) I am in the process of rebuilding HSIDRaw by tearing out the first 100 or
so fields which were old "address validation" fields and no longer valid.
Additionally I am using the data you provided for the "optimum width" of
each field in HSIDRaw to build a new HSIDRaw table with ONLY the selection
fields plus the PKID, and the selection fields optimized to the correct data
type - char(1) in most cases.  Oh, and I also removed all of the HSIDRaw
records not found in AZHSID, i.e. which do not have a deliverable address.
Thus the AZHISD and HSIDRaw now have exactly the same PKIDs.  Before doing
this, AZHSID had 51 million and HSIDRaw had 65 million records.  Now HSIDRaw
has 51 million records as well.

Since HSIDRaw is now "cleaned up" with the first 100 fields deleted and the
remaining fields "optimized" for the correct data type, and the useless
undeliverable records deleted, I hope to make it even more useful by
correctly indexing the selection fields.

Yes, a change to the "normalized" method that you and I discussed would be
nice but unless and until I can figure out how to do that, it is not helpful
to keep pounding away that "that is the correct way to do things".  I have
to deal with reality, and the reality is that I can't do the normalization.


So let's discuss what I can do.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
Fuller
Sent: Thursday, November 29, 2007 9:02 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] How are indexes built

JC:

First of all, you need to understand what a clustered index is, and what it
is not. Perhaps you already know, but in case not, let me try to explain, in
perhaps simplistic terms.

Creating a clustered index physically re-orders the table according to the
order of said index. That will take a while, given the size of your table.
It will also consume (temporarily) a large amount of disk space, since it
has to re-order the table in tempdb and then write it back to yourdb.

>From what I have gathered about your app, I see not a single advantage 
>to
your creation of a clustered index. A clustered index (again typically)
would be most useful in a compound-index situation, i.e. index on Order
Number + Order Detail Number, so gathering up the Order Details would
require minimal visits to the tables. Your case is much different than this,
and AFAIS you would gain nothing by creating a clustered index, and
conversely, lose all the time it will require to physically re-order said
table.

IMO, your largest problem is the width of the table. Whenever I detect
several hundred columns, I detect a wrong approach. We have previously
discussed this, and I hold my ground. All these columns (or at least many of
them) ought to be rows in a child table, not columns in the principal table.
Then you could creatively use indexes. Imagine a hundred columns whose
contents are Y/N/null. No point in recording the nulls; only the Y/Ns are
significant. Give all the current columns a PK and a meaningful description
in the "attributes" table, and then index said PK. Yes, this will result in
many millions of rows, one for every Y/N attribute in your big fat table.
But it will make queries such as attribute A + attribute B + attribute C -
attribute D much simpler. This would translate in the new scheme to an
EXISTS and a NOT EXISTS clause, and since all this could be handled by the
index, relatively few disk hits would be required (relative to the
full-table scans your current model requires for almost every query).

I know you receive new records occasionally, and porting said new records to
this model will involve creating new rows in said child table and then
populating them with the PK from the user, the PK from the new attribute,
and the immediate value.

I would vastly prefer going down that road to the full-table-scan scenarios
you are currently locked into.

Arthur




From jwcolby at colbyconsulting.com  Thu Nov 29 12:45:55 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Thu, 29 Nov 2007 13:45:55 -0500
Subject: [dba-SQLServer] Shrink file - Reorganize pages before releasing
	unused space
Message-ID: <015b01c832b8$1378bc30$647aa8c0@M90>

Does anyone know if this process is done "in place", i.e. if it is similar
to a defrag on a hard disk where the existing file is used and data inside
of the file is simply moved around?  Or is the data in the file copied out
into a new file?  I started this running and wile it claims to be working
(the little "executing" ring is going round) I do not see any indication
that the available disk space on any system drive is changing.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From ridermark at gmail.com  Thu Nov 29 13:02:14 2007
From: ridermark at gmail.com (Mark Rider)
Date: Thu, 29 Nov 2007 13:02:14 -0600
Subject: [dba-SQLServer] Shrink file - Reorganize pages before releasing
	unused space
In-Reply-To: <015b01c832b8$1378bc30$647aa8c0@M90>
References: <015b01c832b8$1378bc30$647aa8c0@M90>
Message-ID: <a74f31780711291102k555fe174va545e05687234bce@mail.gmail.com>

In my experience with this the disk space does not show a difference until
the process is well underway, and sometimes not until it is complete.

As to how it does what it does, I will leave that to the Gurus on the list!



On Nov 29, 2007 12:45 PM, jwcolby <jwcolby at colbyconsulting.com> wrote:

> Does anyone know if this process is done "in place", i.e. if it is similar
> to a defrag on a hard disk where the existing file is used and data inside
> of the file is simply moved around?  Or is the data in the file copied out
> into a new file?  I started this running and wile it claims to be working
> (the little "executing" ring is going round) I do not see any indication
> that the available disk space on any system drive is changing.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


-- 
Mark Rider
http://dfwmdug.org

Don't anthropomorphize computers.
They don't like it.


From jwcolby at colbyconsulting.com  Fri Nov 30 13:04:15 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Fri, 30 Nov 2007 14:04:15 -0500
Subject: [dba-SQLServer] Weird table name restriction
Message-ID: <002501c83383$cde18360$647aa8c0@M90>

I just discovered that SQL Server (or VB.Net) does not like dashes in table
names.

If I use a table name "ZIP4-AA_X", the BulkCopy.WriteToServer throws an
error "can't access destination table" but if I remove the dash "ZIP4AA_X"
it works just fine.

The problem is that I take the name of the datafile, strip off the extension
and use that as my table name.  Thus I now have to start doing edits of the
file name before I can use it as a field name.

The hoops we have to jump through...

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From Patricia.O'Connor at otda.state.ny.us  Fri Nov 30 13:16:21 2007
From: Patricia.O'Connor at otda.state.ny.us (O'Connor, Patricia (OTDA))
Date: Fri, 30 Nov 2007 14:16:21 -0500
Subject: [dba-SQLServer] Weird table name restriction
References: <002501c83383$cde18360$647aa8c0@M90>
Message-ID: <01DBAB52E30A9A4AB3D94EF8029EDBE80253C1B7@EXCNYSM0A1AI.nysemail.nyenet>

Know where you are coming from.  
For YEARS I sent out NAMING CONVENTIONS that have told coworkers to NOT name files with dashes, special characters, start with numbers, even to not use spaces but to use HelloMyFile or Hello_My_File.
 
I have also told them to still think of naming fields differently in the 1st 8 characters. strLName instead of  str_Name_Last.  There are so many 3rd party softwares that will not transfer into or out of MS products becuase of names 
I am constantly fixing messes, renaming files, etc. 
 
*************************************************************
* Patricia E. O'Connor
* Associate Computer Programmer/Analyst
* OTDA - BDMA
* (W) mailto:Patricia.O'Connor at otda.state.ny.us
* (W) mailto:aa1160 at otda.state.ny.us
***********************************************************


--------------------------------------------------------
This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments.  Please notify the sender immediately by reply e-mail and delete the e-mail from your system. 


________________________________


From: dba-sqlserver-bounces at databaseadvisors.com on behalf of jwcolby
Sent: Fri 11/30/2007 2:04 PM
To: dba-sqlserver at databaseadvisors.com; dba-vb at databaseadvisors.com
Subject: [dba-SQLServer] Weird table name restriction



I just discovered that SQL Server (or VB.Net) does not like dashes in table
names.

If I use a table name "ZIP4-AA_X", the BulkCopy.WriteToServer throws an
error "can't access destination table" but if I remove the dash "ZIP4AA_X"
it works just fine.

The problem is that I take the name of the datafile, strip off the extension
and use that as my table name.  Thus I now have to start doing edits of the
file name before I can use it as a field name.

The hoops we have to jump through...

John W. Colby
Colby Consulting
www.ColbyConsulting.com

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com <http://www.databaseadvisors.com/>




From jwcolby at colbyconsulting.com  Fri Nov 30 13:43:30 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Fri, 30 Nov 2007 14:43:30 -0500
Subject: [dba-SQLServer] Reserved words
Message-ID: <002f01c83389$497a0a10$647aa8c0@M90>

Does anyone know if the reserved words in SQL Server (can't be used in table
names etc) are in a table anywhere (in sql server)?  I have code that builds
tables and it really needs to check the proposed table name to make sure
that the name isn't a reserved word, and that it does not have special
characters.  I have had TWO times now where I was hunting down errors caused
by issues with what is valid in a table name.

I could build a table of reserved words but if any new ones are added my
list would be short.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From jwcolby at colbyconsulting.com  Fri Nov 30 23:04:05 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Sat, 1 Dec 2007 00:04:05 -0500
Subject: [dba-SQLServer] Truncate a log file from code
Message-ID: <004701c833d7$99526c00$647aa8c0@M90>

I am doing an entire directory of files, using SQLBulkCopy to import the
text files into a temp table, and from there into a permanent table.  The
log file is about the same size as the data file.  Is it possible to
truncate the log file after every file import in order to minimize the disk
impact?  If so can you point me to example code?

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From pcs at azizaz.com  Fri Nov 30 23:37:15 2007
From: pcs at azizaz.com (pcs at azizaz.com)
Date: Sat,  1 Dec 2007 15:37:15 +1000 (EST)
Subject: [dba-SQLServer]  Temporary Table - Impact on SQL Db size
Message-ID: <20071201153715.DIX24665@dommail.onthenet.com.au>

Hi all,

SQL2005 :
If I daily create a table, populate it with a bunch of data,
use it to perform some updates and then drop it - will this
just keep growing the database or will SQL Server manage the
disk space.... I am asking the question as my experience with
Access Dbs is that ever so often you had to compact the Db if
you did something like this.... Does SQL Server handle this
better, i.e. without user intervention?

Regards
Borge