Showing posts with label benefits. Show all posts
Showing posts with label benefits. Show all posts

Friday, February 24, 2012

Benefits/drawbacks with NVarChar(max)

Hi,

I wonder if there are any drawbacks with NVarChar(max) contra e.g. NVarChar(40) when it comes to performance and amount of storage used?

Are there other arguments to use e.g. NVarChar(40) than that you have more control of how long the strings are when you set the upper limit?

I'm using Sql Server 2005.

Tomsi

Hey Tomsi. Using any of the (max) datatypes will basically tell the server that the data in that column could possibly grow to 2gb if desired. To achieve this, the database engine will evaluate the size of the data being inserted/updated into the column and store it appropriately depending on the size. If the size of the data being stored will fit in-row with the rest of the data for that row (i.e. if it's less than 8k minus the size of the other columns in the row give or take some other considerations), then SQL Server will store the data in-row with the rest of the row data. If it is larger than that and can't be stored in-row with the rest of the row's data, then SQL Server will store a pointer in the row with the data that points to the location of the actual data elsewhere. During read/write operations for that row from now on, the engine will have to jump from the pointer to the data, get/update the data, then jump back to the pointer, so read/write time is slowed in this case.

You'll also see a slight additional overhead for determining if the data can fit in row or not, but that will be miniscule.

General recommendation would be that if you know the size of the data will never exceed 'x', and x is <= ~8000 bytes, then use nvarchar(x)...if the data will in some cases or always exceed that size, then use the (max) indicator...

You could see this article for a bit more info and go from there

http://msdn2.microsoft.com/en-us/library/ms178158.aspx

HTH

benefits/disadvantages of activex/sql-dmo

i have just setup my main sql server as a central publisher/distributor and a number of laptops (only connect to network once a week) with msde as annonymous pull subscribers, using merge replication. Using windows synchronisation manager i have run the c
ommon conflicts i expect to occur and everything works ok.
Could anyone tell me the benefits/pitfalls of using SQL Merge Control or SQL-DMO, over Windows Syncronisation Manager?
Is there a way during syncronisation to determine which side publisher/subscriber has priority on each conflict as and when they occur?
Please bear in mind this is the first time I have worked with SQL Server and I am the only IT person in a small company so I am avoiding over-complicating things for users as much as possible. These message boards are brilliant for advice from people more
experienced than me.
Thanks for your help
SQL DMO is what the replication wizards use. Under the covers it runs replication stored procedures.
Think of the Active
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"James P" wrote:

> i have just setup my main sql server as a central publisher/distributor and a number of laptops (only connect to network once a week) with msde as annonymous pull subscribers, using merge replication. Using windows synchronisation manager i have run the
common conflicts i expect to occur and everything works ok.
> Could anyone tell me the benefits/pitfalls of using SQL Merge Control or SQL-DMO, over Windows Syncronisation Manager?
> Is there a way during syncronisation to determine which side publisher/subscriber has priority on each conflict as and when they occur?
> Please bear in mind this is the first time I have worked with SQL Server and I am the only IT person in a small company so I am avoiding over-complicating things for users as much as possible. These message boards are brilliant for advice from people mo
re experienced than me.
> Thanks for your help
>
|||sorry that last message was send prematurely.
Think of the ActiveX controls as a lightweight version of SQL DMO. Windows Synchronization Manager uses the ActiveX controls.
Here is a brief rundown of the differences. BTW - I only use SQL DMO, although its more complex to code with, it is more feature rich.
1) If you are building publications, you must use SQL-DMO. You cannot build publications or push subscriptions with ActiveX replication controls.
2) The ActiveX replication controls' functionality is limited to copying subscription databases (but not attaching them), managing the Snapshot and Distribution Agents, creating pull subscriptions, and reinitializing subscriptions.
3) Despite their limitations, the ActiveX replication controls have proven to be far more popular than SQL-DMO is as they contain only three classes, and are simpler to work with .
4) you can't control the ActiveX agents through the agents folder in EM.
To answer your specific question regarding priority in SQL DMO its the priority property of the MergePublication class, in ActiveX its the SubscriptionPriority and SubscriptionPriorityType of the SQLMerge class.
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
"James P" wrote:

> i have just setup my main sql server as a central publisher/distributor and a number of laptops (only connect to network once a week) with msde as annonymous pull subscribers, using merge replication. Using windows synchronisation manager i have run the
common conflicts i expect to occur and everything works ok.
> Could anyone tell me the benefits/pitfalls of using SQL Merge Control or SQL-DMO, over Windows Syncronisation Manager?
> Is there a way during syncronisation to determine which side publisher/subscriber has priority on each conflict as and when they occur?
> Please bear in mind this is the first time I have worked with SQL Server and I am the only IT person in a small company so I am avoiding over-complicating things for users as much as possible. These message boards are brilliant for advice from people mo
re experienced than me.
> Thanks for your help
>

benefits to use collations BIN vs windows

Hi
which are the real benefits to use collations BIN vs for example
Latin1_General_Ci_AS.
Or only it is for the order of the data, this always utilizing types of data
unicode.
ThankOn Tue, 9 Jan 2007 09:28:01 -0800, sqlextreme wrote:

>Hi
>which are the real benefits to use collations BIN vs for example
>Latin1_General_Ci_AS.
>Or only it is for the order of the data, this always utilizing types of dat
a
>unicode.
Hi sqlextreme,
The most important consideration should be how you generally want to
compare data. What do the users expect? Do they expect to find
"Washington" when entering "washington" as search string? Should
"Dsseldorf" be returned when searching "Dusseldorf"? Would they be
surprised to find "aaron" after "Zelazny" if the data is supposed to be
ordered?
The only advantage of using binary collation that I know of is that it's
(slightly) faster.
Hugo Kornelis, SQL Server MVP
My SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis

Benefits of using SQL over XML

Hi,

I have a question relating to XML and SQL. My company currently runs a website which allows its clients to log in, view their accounts and transaction history online. The website is totally read only with the exception of changing passwords.

The data is taken from our back office system overnight which runs an oracle 8i database (we cannot like our website to the database due to the agreement we have in place with our software supplier). The data is written to a CSV file which is then converted into XML. The XML file is saved to the webserver and is referenced by the website.

The structure of the website has a relationship where the Client has a Manager who can see their clients accounts, a Branch level that can see all of their Managers and the underlying clients and then finally a company level that sees everything.

We are finding that using XML is causing a real issue in performance and I was wondering if migrating the website to SQL server would improve the performance of the queries etc .

Any advice would be gratefully recieved

Lee

It really depends on two things: The application and the version of SQL Server you are using. For certain input/retrieval methods, XML can actually be faster than using direct database calls. SQL Server 2005 has native XML features, which you can read more about here:

http://www.sqlsummit.com/People/MRys.htm

Buck

|||

The thing is that our website is taking considerably longer to return results using XML. Our software provider can provide a website which uses Oracle and an example website using test data seems to query and return the data back in far less time then ours using XML. But this site is a lot more costly option and does not provide all the functionalty we require. The main reason for the performance increase is that we want to be able to use the website internally for our branches and front office staff, so performance is key it will have about 20 - 30 users. We are planning to do this because we are unable to restrict access to parts of our back office system from the front office staff. The problem with the performance of the website currently means that the staff will have to deal with a sluggish system.

Our website designer has said that he would have to rewrite the website to change it from XML to SQL, would XQuery be a simpler solution. We are within reason happy to purchase whatever software is required to make this work.

|||

Again, it all depends on how the application is coded. Simply changing from XML to an RDBMS query doesn't guarentee that one will be faster than the other. In other words, you can code an application to be faster in either case.

If performance is key, then for large data sets a database platform might be the way to go. If you need to share data between multiple systems, then XML might be the way to go. It all depends on your needs, but in either case you'll want to evaluate your code to ensure that it is as optimal as possible for your situation.

Benefits of upgrading SQL 7 to 2K

Could someone please let me know the specific 'benefits' of upgrading a SQL 7 system to a 2K? For instance if any of you have done this, did you notice a significant change within your system(s)?
Thanks!!!Well, as an Enterprise solution, 7.0 cannot be reliably clustered. Performance may improve on certain queries, but don't be surprised to see a degradation, though it's pretty rare. The most benefits are for applications that are either being newly developed or the ones that can be modified without infringing your support agreement with your vendor. The reason is added functionality. But if your system needs only backups and occasional reindexing, - don't fix what ain't broke :)|||There are lots of benefits to upgrading and many articles available on the subject...

Here are a few links that will give you some background:

http://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=28000409

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/whatsnew/wn_whatnew_7im0.asp?frame=true

CPN|||Originally posted by NotAvg1
Could someone please let me know the specific 'benefits' of upgrading a SQL 7 system to a 2K? For instance if any of you have done this, did you notice a significant change within your system(s)?

Thanks!!!

There are a few keywords, functions, etc. that are in 2K that aren't in 7. We have one vendors application that uses some of them, but they are good enough to have an MSDE version that we can use.

I would say that unless you are worried about clustering, or a specific application requires it, I don't think there is enough justification.

Besides I bet a 2K3 or 2K4 version is probably in alpha testing somewhere. That way you could just jump versions.

Sunday, February 19, 2012

benefits of SQL Server 2000

Could someone hit the high points of the benefits of using SQL Server (vs. other databases) with Visual Studio .NET and the .NET Framework.

ThanksThe biggest benefit is that Sql Server and MSDE have the greatest degree of integration with VS.Net and the .Net Framework. Having MSDE available is also a big plus because it makes it easy to deploy small scale applications using essentially the same database as Sql Server.

But the other major database products will work just fine with VS.Net.|||I don't mean to sound lazy, but could someone give me specifics such as examples of integration with VS.NET and functionality accomplished using SQL Server with .NET Framework. I'm trying to sell these products and was hoping to get out of doing all of the background research. I've used these products but I would like other people's opinions.

Thanks|||Wouldn't you be better able to sell them if you did the research yourself and had a better handle on the product?|||I'm trying to "sell" them as a platform to my company and would like examples that can be backed up by others, not just my own opinions.|||You might consider using come of the Case Studies as part of your research.

Microsoft Case Studies

Terri

Benefits of SQL authentication?

SQL2K
SP4
I can find lots of info regarding the justification to use WINNT instead of
SQL authentication. Are there any good reasons to use SQL authentication
instead?
TIA, ChrisRWeb applications, Mac or Linux users, or any situation where the users are
not members of the domain.
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
news:AFC675ED-FE57-41DD-8CF9-F494E112E95A@.microsoft.com...
> SQL2K
> SP4
> I can find lots of info regarding the justification to use WINNT instead
> of
> SQL authentication. Are there any good reasons to use SQL authentication
> instead?
> TIA, ChrisR|||Thanks, I should have been more specific. I know there are times when users
MUST use SQL auth. However, if it could go either way, what would the
benefits be to SQL auth?
"Arnie Rowland" wrote:

> Web applications, Mac or Linux users, or any situation where the users are
> not members of the domain.
> --
> Arnie Rowland, Ph.D.
> Westwood Consulting, Inc
> Most good judgment comes from experience.
> Most experience comes from bad judgment.
> - Anonymous
>
> "ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
> news:AFC675ED-FE57-41DD-8CF9-F494E112E95A@.microsoft.com...
>
>|||If you have a choice, the pros are for Windows authentication, and the cons
are for SQL Authentication.
I, honestly, can't recall situations where SQL Authentication is the best
choice over Windows Authentication -unless SQL Authentication is required
for some specific need.
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
news:F115C81F-55BA-46B1-A7AE-F156BD815A95@.microsoft.com...[vbcol=seagreen]
> Thanks, I should have been more specific. I know there are times when
> users
> MUST use SQL auth. However, if it could go either way, what would the
> benefits be to SQL auth?
>
> "Arnie Rowland" wrote:
>|||There aren't any benefits aside from needing to use it. You wouldn't
'choose' SQL Auth over Windows auth if you had both as a viable option -
ever. SQL Auth is a subset of Windows Auth - not vice versa.
"ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
news:F115C81F-55BA-46B1-A7AE-F156BD815A95@.microsoft.com...[vbcol=seagreen]
> Thanks, I should have been more specific. I know there are times when
> users
> MUST use SQL auth. However, if it could go either way, what would the
> benefits be to SQL auth?
>
> "Arnie Rowland" wrote:
>

Benefits of SQL authentication?

SQL2K
SP4
I can find lots of info regarding the justification to use WINNT instead of
SQL authentication. Are there any good reasons to use SQL authentication
instead?
TIA, ChrisRWeb applications, Mac or Linux users, or any situation where the users are
not members of the domain.
--
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
news:AFC675ED-FE57-41DD-8CF9-F494E112E95A@.microsoft.com...
> SQL2K
> SP4
> I can find lots of info regarding the justification to use WINNT instead
> of
> SQL authentication. Are there any good reasons to use SQL authentication
> instead?
> TIA, ChrisR|||Thanks, I should have been more specific. I know there are times when users
MUST use SQL auth. However, if it could go either way, what would the
benefits be to SQL auth?
"Arnie Rowland" wrote:
> Web applications, Mac or Linux users, or any situation where the users are
> not members of the domain.
> --
> Arnie Rowland, Ph.D.
> Westwood Consulting, Inc
> Most good judgment comes from experience.
> Most experience comes from bad judgment.
> - Anonymous
>
> "ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
> news:AFC675ED-FE57-41DD-8CF9-F494E112E95A@.microsoft.com...
> > SQL2K
> > SP4
> >
> > I can find lots of info regarding the justification to use WINNT instead
> > of
> > SQL authentication. Are there any good reasons to use SQL authentication
> > instead?
> >
> > TIA, ChrisR
>
>|||If you have a choice, the pros are for Windows authentication, and the cons
are for SQL Authentication.
I, honestly, can't recall situations where SQL Authentication is the best
choice over Windows Authentication -unless SQL Authentication is required
for some specific need.
--
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
news:F115C81F-55BA-46B1-A7AE-F156BD815A95@.microsoft.com...
> Thanks, I should have been more specific. I know there are times when
> users
> MUST use SQL auth. However, if it could go either way, what would the
> benefits be to SQL auth?
>
> "Arnie Rowland" wrote:
>> Web applications, Mac or Linux users, or any situation where the users
>> are
>> not members of the domain.
>> --
>> Arnie Rowland, Ph.D.
>> Westwood Consulting, Inc
>> Most good judgment comes from experience.
>> Most experience comes from bad judgment.
>> - Anonymous
>>
>> "ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
>> news:AFC675ED-FE57-41DD-8CF9-F494E112E95A@.microsoft.com...
>> > SQL2K
>> > SP4
>> >
>> > I can find lots of info regarding the justification to use WINNT
>> > instead
>> > of
>> > SQL authentication. Are there any good reasons to use SQL
>> > authentication
>> > instead?
>> >
>> > TIA, ChrisR
>>|||There aren't any benefits aside from needing to use it. You wouldn't
'choose' SQL Auth over Windows auth if you had both as a viable option -
ever. SQL Auth is a subset of Windows Auth - not vice versa.
"ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
news:F115C81F-55BA-46B1-A7AE-F156BD815A95@.microsoft.com...
> Thanks, I should have been more specific. I know there are times when
> users
> MUST use SQL auth. However, if it could go either way, what would the
> benefits be to SQL auth?
>
> "Arnie Rowland" wrote:
>> Web applications, Mac or Linux users, or any situation where the users
>> are
>> not members of the domain.
>> --
>> Arnie Rowland, Ph.D.
>> Westwood Consulting, Inc
>> Most good judgment comes from experience.
>> Most experience comes from bad judgment.
>> - Anonymous
>>
>> "ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
>> news:AFC675ED-FE57-41DD-8CF9-F494E112E95A@.microsoft.com...
>> > SQL2K
>> > SP4
>> >
>> > I can find lots of info regarding the justification to use WINNT
>> > instead
>> > of
>> > SQL authentication. Are there any good reasons to use SQL
>> > authentication
>> > instead?
>> >
>> > TIA, ChrisR
>>

benefits of full recovery**

Hi
What's the benefit usage to select Full recovery model for a database?
I know it's better to select simple mode for developement and test
enviroment.
But I don't know excatly how can the full recovery model be usefull for
critical enviroment?
Can any body give me an example?
Thanks alot
Maryam,
Here is a nice article:
http://insight.zdnet.co.uk/software/...4171-1,00.htm.
Dejan Sarka, SQL Server MVP
Associate Mentor
www.SolidQualityLearning.com
"maryam rezvani" <rezvani@.parskhazar.net> wrote in message
news:uWJq1njwEHA.3824@.TK2MSFTNGP15.phx.gbl...
> Hi
> What's the benefit usage to select Full recovery model for a database?
> I know it's better to select simple mode for developement and test
> enviroment.
> But I don't know excatly how can the full recovery model be usefull for
> critical enviroment?
> Can any body give me an example?
> Thanks alot
>
|||maryam rezvani wrote:
> Hi
> What's the benefit usage to select Full recovery model for a database?
> I know it's better to select simple mode for developement and test
> enviroment.
> But I don't know excatly how can the full recovery model be usefull
> for critical enviroment?
> Can any body give me an example?
> Thanks alot
short:
if your DB is in full recovery model, you will have to backup the log, if
you can several times/day. In case of a restore, you probably will not lose
any data, and you can recovery to the point in time (useful if someone
deletes something or some other human error)
long:
see BooksOnLine (mssql help)
|||Hi
By using 'FULL recovery' mode you will be able to restore your database at
point time
For example , you do a full backup on sunday night and every hour a log file
backup during the work day ,so on tuesday at 11 AM the database is crashed
..If you have the database in 'SIMPLE recovery' you will be able to get the
database back only from last backup (sunday night) ,that means you lost the
data of monday,tuesday . However , if you have 'FULL recovery' you have to
restore the last database backup and the apply all LOG backups till 11AM
(see more details in the BOL)
Another important point is
Let say you do a FULL backup database every sunday night and every hour a
LOG file backup. Now, you lost the FULL database backup of the second week
and the database is get corrupted now. So what would you do, you are about
to lost the data of two weeks ( if you do only FULL backup database (SIMPLE
recovery) ) ,but in that case you restore the last full backup (two weeks
ago) and the apply all LOG files you perfom till the corruption. You will
lost nothing because LOG file backup contains all info since last LOG file
backup.
"maryam rezvani" <rezvani@.parskhazar.net> wrote in message
news:uWJq1njwEHA.3824@.TK2MSFTNGP15.phx.gbl...
> Hi
> What's the benefit usage to select Full recovery model for a database?
> I know it's better to select simple mode for developement and test
> enviroment.
> But I don't know excatly how can the full recovery model be usefull for
> critical enviroment?
> Can any body give me an example?
> Thanks alot
>
|||Thanks
Do you mean that if I found that some false insertion happenning to a
special table
in 9:00 am and my db is in full recovery model so I can restore my db to the
point
exaclty before the false insertion through the log file?
but if I set my db to simple mode have to restore the previous backup
related to the day before(cause I back up my db every night)?
"Zarko Jovanovic" <mind_less_NOSPAM_@.bigfoot.com> wrote in message
news:1099553502.722414@.internet.fina.hr...
> maryam rezvani wrote:
> short:
> if your DB is in full recovery model, you will have to backup the log, if
> you can several times/day. In case of a restore, you probably will not
lose
> any data, and you can recovery to the point in time (useful if someone
> deletes something or some other human error)
> long:
> see BooksOnLine (mssql help)
>
|||Correct. But for the first scenario, you also need to perform regular transaction log backups. When
you restore a transaction log backup, you can stop at a certain point in time.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"maryam rezvani" <rezvani@.parskhazar.net> wrote in message
news:egP72OkwEHA.4004@.tk2msftngp13.phx.gbl...
> Thanks
> Do you mean that if I found that some false insertion happenning to a
> special table
> in 9:00 am and my db is in full recovery model so I can restore my db to the
> point
> exaclty before the false insertion through the log file?
> but if I set my db to simple mode have to restore the previous backup
> related to the day before(cause I back up my db every night)?
> "Zarko Jovanovic" <mind_less_NOSPAM_@.bigfoot.com> wrote in message
> news:1099553502.722414@.internet.fina.hr...
> lose
>

benefits of full recovery**

Hi
What's the benefit usage to select Full recovery model for a database?
I know it's better to select simple mode for developement and test
enviroment.
But I don't know excatly how can the full recovery model be usefull for
critical enviroment?
Can any body give me an example?
Thanks alotMaryam,
Here is a nice article:
http://insight.zdnet.co.uk/software...34171-1,00.htm.
Dejan Sarka, SQL Server MVP
Associate Mentor
www.SolidQualityLearning.com
"maryam rezvani" <rezvani@.parskhazar.net> wrote in message
news:uWJq1njwEHA.3824@.TK2MSFTNGP15.phx.gbl...
> Hi
> What's the benefit usage to select Full recovery model for a database?
> I know it's better to select simple mode for developement and test
> enviroment.
> But I don't know excatly how can the full recovery model be usefull for
> critical enviroment?
> Can any body give me an example?
> Thanks alot
>|||maryam rezvani wrote:
> Hi
> What's the benefit usage to select Full recovery model for a database?
> I know it's better to select simple mode for developement and test
> enviroment.
> But I don't know excatly how can the full recovery model be usefull
> for critical enviroment?
> Can any body give me an example?
> Thanks alot
short:
if your DB is in full recovery model, you will have to backup the log, if
you can several times/day. In case of a restore, you probably will not lose
any data, and you can recovery to the point in time (useful if someone
deletes something or some other human error)
long:
see BooksOnLine (mssql help)|||Hi
By using 'FULL recovery' mode you will be able to restore your database at
point time
For example , you do a full backup on sunday night and every hour a log file
backup during the work day ,so on tuesday at 11 AM the database is crashed
.If you have the database in 'SIMPLE recovery' you will be able to get the
database back only from last backup (sunday night) ,that means you lost the
data of monday,tuesday . However , if you have 'FULL recovery' you have to
restore the last database backup and the apply all LOG backups till 11AM
(see more details in the BOL)
Another important point is
Let say you do a FULL backup database every sunday night and every hour a
LOG file backup. Now, you lost the FULL database backup of the second week
and the database is get corrupted now. So what would you do, you are about
to lost the data of two weeks ( if you do only FULL backup database (SIMPLE
recovery) ) ,but in that case you restore the last full backup (two weeks
ago) and the apply all LOG files you perfom till the corruption. You will
lost nothing because LOG file backup contains all info since last LOG file
backup.
"maryam rezvani" <rezvani@.parskhazar.net> wrote in message
news:uWJq1njwEHA.3824@.TK2MSFTNGP15.phx.gbl...
> Hi
> What's the benefit usage to select Full recovery model for a database?
> I know it's better to select simple mode for developement and test
> enviroment.
> But I don't know excatly how can the full recovery model be usefull for
> critical enviroment?
> Can any body give me an example?
> Thanks alot
>|||Thanks
Do you mean that if I found that some false insertion happenning to a
special table
in 9:00 am and my db is in full recovery model so I can restore my db to the
point
exaclty before the false insertion through the log file?
but if I set my db to simple mode have to restore the previous backup
related to the day before(cause I back up my db every night)?
"Zarko Jovanovic" <mind_less_NOSPAM_@.bigfoot.com> wrote in message
news:1099553502.722414@.internet.fina.hr...
> maryam rezvani wrote:
> short:
> if your DB is in full recovery model, you will have to backup the log, if
> you can several times/day. In case of a restore, you probably will not
lose
> any data, and you can recovery to the point in time (useful if someone
> deletes something or some other human error)
> long:
> see BooksOnLine (mssql help)
>|||Correct. But for the first scenario, you also need to perform regular transa
ction log backups. When
you restore a transaction log backup, you can stop at a certain point in tim
e.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"maryam rezvani" <rezvani@.parskhazar.net> wrote in message
news:egP72OkwEHA.4004@.tk2msftngp13.phx.gbl...
> Thanks
> Do you mean that if I found that some false insertion happenning to a
> special table
> in 9:00 am and my db is in full recovery model so I can restore my db to t
he
> point
> exaclty before the false insertion through the log file?
> but if I set my db to simple mode have to restore the previous backup
> related to the day before(cause I back up my db every night)?
> "Zarko Jovanovic" <mind_less_NOSPAM_@.bigfoot.com> wrote in message
> news:1099553502.722414@.internet.fina.hr...
> lose
>

benefits of full recovery**

Hi
What's the benefit usage to select Full recovery model for a database?
I know it's better to select simple mode for developement and test
enviroment.
But I don't know excatly how can the full recovery model be usefull for
critical enviroment?
Can any body give me an example?
Thanks alotMaryam,
Here is a nice article:
http://insight.zdnet.co.uk/software/developer/0,39020469,2134171-1,00.htm.
--
Dejan Sarka, SQL Server MVP
Associate Mentor
www.SolidQualityLearning.com
"maryam rezvani" <rezvani@.parskhazar.net> wrote in message
news:uWJq1njwEHA.3824@.TK2MSFTNGP15.phx.gbl...
> Hi
> What's the benefit usage to select Full recovery model for a database?
> I know it's better to select simple mode for developement and test
> enviroment.
> But I don't know excatly how can the full recovery model be usefull for
> critical enviroment?
> Can any body give me an example?
> Thanks alot
>|||maryam rezvani wrote:
> Hi
> What's the benefit usage to select Full recovery model for a database?
> I know it's better to select simple mode for developement and test
> enviroment.
> But I don't know excatly how can the full recovery model be usefull
> for critical enviroment?
> Can any body give me an example?
> Thanks alot
short:
if your DB is in full recovery model, you will have to backup the log, if
you can several times/day. In case of a restore, you probably will not lose
any data, and you can recovery to the point in time (useful if someone
deletes something or some other human error)
long:
see BooksOnLine (mssql help)|||Hi
By using 'FULL recovery' mode you will be able to restore your database at
point time
For example , you do a full backup on sunday night and every hour a log file
backup during the work day ,so on tuesday at 11 AM the database is crashed
.If you have the database in 'SIMPLE recovery' you will be able to get the
database back only from last backup (sunday night) ,that means you lost the
data of monday,tuesday . However , if you have 'FULL recovery' you have to
restore the last database backup and the apply all LOG backups till 11AM
(see more details in the BOL)
Another important point is
Let say you do a FULL backup database every sunday night and every hour a
LOG file backup. Now, you lost the FULL database backup of the second week
and the database is get corrupted now. So what would you do, you are about
to lost the data of two weeks ( if you do only FULL backup database (SIMPLE
recovery) ) ,but in that case you restore the last full backup (two weeks
ago) and the apply all LOG files you perfom till the corruption. You will
lost nothing because LOG file backup contains all info since last LOG file
backup.
"maryam rezvani" <rezvani@.parskhazar.net> wrote in message
news:uWJq1njwEHA.3824@.TK2MSFTNGP15.phx.gbl...
> Hi
> What's the benefit usage to select Full recovery model for a database?
> I know it's better to select simple mode for developement and test
> enviroment.
> But I don't know excatly how can the full recovery model be usefull for
> critical enviroment?
> Can any body give me an example?
> Thanks alot
>|||Thanks
Do you mean that if I found that some false insertion happenning to a
special table
in 9:00 am and my db is in full recovery model so I can restore my db to the
point
exaclty before the false insertion through the log file?
but if I set my db to simple mode have to restore the previous backup
related to the day before(cause I back up my db every night)?
"Zarko Jovanovic" <mind_less_NOSPAM_@.bigfoot.com> wrote in message
news:1099553502.722414@.internet.fina.hr...
> maryam rezvani wrote:
> > Hi
> >
> > What's the benefit usage to select Full recovery model for a database?
> > I know it's better to select simple mode for developement and test
> > enviroment.
> > But I don't know excatly how can the full recovery model be usefull
> > for critical enviroment?
> >
> > Can any body give me an example?
> > Thanks alot
> short:
> if your DB is in full recovery model, you will have to backup the log, if
> you can several times/day. In case of a restore, you probably will not
lose
> any data, and you can recovery to the point in time (useful if someone
> deletes something or some other human error)
> long:
> see BooksOnLine (mssql help)
>|||Correct. But for the first scenario, you also need to perform regular transaction log backups. When
you restore a transaction log backup, you can stop at a certain point in time.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"maryam rezvani" <rezvani@.parskhazar.net> wrote in message
news:egP72OkwEHA.4004@.tk2msftngp13.phx.gbl...
> Thanks
> Do you mean that if I found that some false insertion happenning to a
> special table
> in 9:00 am and my db is in full recovery model so I can restore my db to the
> point
> exaclty before the false insertion through the log file?
> but if I set my db to simple mode have to restore the previous backup
> related to the day before(cause I back up my db every night)?
> "Zarko Jovanovic" <mind_less_NOSPAM_@.bigfoot.com> wrote in message
> news:1099553502.722414@.internet.fina.hr...
> > maryam rezvani wrote:
> > > Hi
> > >
> > > What's the benefit usage to select Full recovery model for a database?
> > > I know it's better to select simple mode for developement and test
> > > enviroment.
> > > But I don't know excatly how can the full recovery model be usefull
> > > for critical enviroment?
> > >
> > > Can any body give me an example?
> > > Thanks alot
> >
> > short:
> >
> > if your DB is in full recovery model, you will have to backup the log, if
> > you can several times/day. In case of a restore, you probably will not
> lose
> > any data, and you can recovery to the point in time (useful if someone
> > deletes something or some other human error)
> >
> > long:
> >
> > see BooksOnLine (mssql help)
> >
> >
>

Benefits of 64bit SQL?

Hi,
I'm trying to decide whether our next database server should be 32 or 64
bit. Could someone please explain the benefits of 64bit computing and the
factors I should be looking at in order to determine whether it would be of
value to me?
The only benefit I'm aware of is the fact that memory beyond 4gigs can
be accessed directly -- but surely there must be other benefits as well. I
imagine that the speed at which data is transferred across the bus must be
doubled due to the fatter data path... but given that I'd still be limited
by the I/O speed of the drives, is the performance improvement even
relevant?
Sorry for the newbie questions. I just want to avoid having some slick
talking salesman sell us a 64bit machine if we don't really need it. I want
to know what questions to ask.
Thanks..."The One We Call 'Dave'" <ghetto@.englewood.com> wrote in message
news:yLudnZXu2Ii_AE7eRVn-gQ@.giganews.com...
> Hi,
> I'm trying to decide whether our next database server should be 32 or
> 64 bit. Could someone please explain the benefits of 64bit computing and
> the factors I should be looking at in order to determine whether it would
> be of value to me?
> The only benefit I'm aware of is the fact that memory beyond 4gigs can
> be accessed directly -- but surely there must be other benefits as well.
That's pretty much it. But x64 64 bit does not add any cost to servers.
Intel and AMD's server chips are (basically) all 64 bit chips.
>I imagine that the speed at which data is transferred across the bus must
>be doubled due to the fatter data path... but given that I'd still be
>limited by the I/O speed of the drives, is the performance improvement even
>relevant?
Memory bus speed is a very important performance factor for databse servers.
With several gigabytes of data cached, moving that data in and out of the
CPU is one of the major system bottlenecks. Large on-chip L2 cache helps
here too. However 64 bit systems are not automatically better here. X64
servers use basically the same system boards as 32-bit systems.
> Sorry for the newbie questions. I just want to avoid having some slick
> talking salesman sell us a 64bit machine if we don't really need it. I
> want to know what questions to ask.
You definitely want 64bit, since it doesn't really cost you anyting. You
still have to choose between x64 and IA64-based systems. Currently dollar
for dollar x64 is the performance king, but for certian very large workloads
you might need a big IA64 box.
David|||from a performance point of view, for the same hardware and less then 4Gb
there is no difference.
above 4Gb there are small improvements at the DB level. but managing the
memory is more easier.
the performance improvement is at the SSIS & AS levels. with more then 4Gb
these 2 tools takes a big advantage of this memory.
the other advantage is at the OS level.
Standard x64 edition of windows support 32Gb while the 32bits version is
limited to 4Gb.
"The One We Call 'Dave'" <ghetto@.englewood.com> wrote in message
news:yLudnZXu2Ii_AE7eRVn-gQ@.giganews.com...
> Hi,
> I'm trying to decide whether our next database server should be 32 or
> 64 bit. Could someone please explain the benefits of 64bit computing and
> the factors I should be looking at in order to determine whether it would
> be of value to me?
> The only benefit I'm aware of is the fact that memory beyond 4gigs can
> be accessed directly -- but surely there must be other benefits as well. I
> imagine that the speed at which data is transferred across the bus must be
> doubled due to the fatter data path... but given that I'd still be limited
> by the I/O speed of the drives, is the performance improvement even
> relevant?
> Sorry for the newbie questions. I just want to avoid having some slick
> talking salesman sell us a 64bit machine if we don't really need it. I
> want to know what questions to ask.
> Thanks...
>|||http://www.microsoft.com/sql/techinfo/whitepapers/advantages-64bit-environment.mspx
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
--
"The One We Call 'Dave'" <ghetto@.englewood.com> wrote in message
news:yLudnZXu2Ii_AE7eRVn-gQ@.giganews.com...
> Hi,
> I'm trying to decide whether our next database server should be 32 or
> 64 bit. Could someone please explain the benefits of 64bit computing and
> the factors I should be looking at in order to determine whether it would
> be of value to me?
> The only benefit I'm aware of is the fact that memory beyond 4gigs can
> be accessed directly -- but surely there must be other benefits as well. I
> imagine that the speed at which data is transferred across the bus must be
> doubled due to the fatter data path... but given that I'd still be limited
> by the I/O speed of the drives, is the performance improvement even
> relevant?
> Sorry for the newbie questions. I just want to avoid having some slick
> talking salesman sell us a 64bit machine if we don't really need it. I
> want to know what questions to ask.
> Thanks...
>|||> However 64 bit systems are not automatically better here. X64 servers use
> basically the same system boards as 32-bit systems.
Hi David,
Could you expand on this a bit? Excuse my ignorance here, but what do
you mean when you say that X64 servers use basically the same system boards
as 32 bit systems? How is that possible? Also, is "X64" just a generic term
that's used to refer to 64 bit computing in general or does it represent a
particular *brand* of 64 bit processors designed by Intel (ala "Pentium" or
"386")?
Thanks,
Dave|||http://en.wikipedia.org/wiki/X64
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
--
"The One We Call 'Dave'" <ghetto@.englewood.com> wrote in message
news:x_SdnandWO39lEjenZ2dnUVZ_tidnZ2d@.giganews.com...
>> However 64 bit systems are not automatically better here. X64 servers
>> use basically the same system boards as 32-bit systems.
> Hi David,
> Could you expand on this a bit? Excuse my ignorance here, but what do
> you mean when you say that X64 servers use basically the same system
> boards as 32 bit systems? How is that possible? Also, is "X64" just a
> generic term that's used to refer to 64 bit computing in general or does
> it represent a particular *brand* of 64 bit processors designed by Intel
> (ala "Pentium" or "386")?
> Thanks,
> Dave
>

Benefits of 64bit SQL?

Hi,
I'm trying to decide whether our next database server should be 32 or 64
bit. Could someone please explain the benefits of 64bit computing and the
factors I should be looking at in order to determine whether it would be of
value to me?
The only benefit I'm aware of is the fact that memory beyond 4gigs can
be accessed directly -- but surely there must be other benefits as well. I
imagine that the speed at which data is transferred across the bus must be
doubled due to the fatter data path... but given that I'd still be limited
by the I/O speed of the drives, is the performance improvement even
relevant?
Sorry for the newbie questions. I just want to avoid having some slick
talking salesman sell us a 64bit machine if we don't really need it. I want
to know what questions to ask.
Thanks...
"The One We Call 'Dave'" <ghetto@.englewood.com> wrote in message
news:yLudnZXu2Ii_AE7eRVn-gQ@.giganews.com...
> Hi,
> I'm trying to decide whether our next database server should be 32 or
> 64 bit. Could someone please explain the benefits of 64bit computing and
> the factors I should be looking at in order to determine whether it would
> be of value to me?
> The only benefit I'm aware of is the fact that memory beyond 4gigs can
> be accessed directly -- but surely there must be other benefits as well.
That's pretty much it. But x64 64 bit does not add any cost to servers.
Intel and AMD's server chips are (basically) all 64 bit chips.

>I imagine that the speed at which data is transferred across the bus must
>be doubled due to the fatter data path... but given that I'd still be
>limited by the I/O speed of the drives, is the performance improvement even
>relevant?
Memory bus speed is a very important performance factor for databse servers.
With several gigabytes of data cached, moving that data in and out of the
CPU is one of the major system bottlenecks. Large on-chip L2 cache helps
here too. However 64 bit systems are not automatically better here. X64
servers use basically the same system boards as 32-bit systems.

> Sorry for the newbie questions. I just want to avoid having some slick
> talking salesman sell us a 64bit machine if we don't really need it. I
> want to know what questions to ask.
You definitely want 64bit, since it doesn't really cost you anyting. You
still have to choose between x64 and IA64-based systems. Currently dollar
for dollar x64 is the performance king, but for certian very large workloads
you might need a big IA64 box.
David
|||from a performance point of view, for the same hardware and less then 4Gb
there is no difference.
above 4Gb there are small improvements at the DB level. but managing the
memory is more easier.
the performance improvement is at the SSIS & AS levels. with more then 4Gb
these 2 tools takes a big advantage of this memory.
the other advantage is at the OS level.
Standard x64 edition of windows support 32Gb while the 32bits version is
limited to 4Gb.
"The One We Call 'Dave'" <ghetto@.englewood.com> wrote in message
news:yLudnZXu2Ii_AE7eRVn-gQ@.giganews.com...
> Hi,
> I'm trying to decide whether our next database server should be 32 or
> 64 bit. Could someone please explain the benefits of 64bit computing and
> the factors I should be looking at in order to determine whether it would
> be of value to me?
> The only benefit I'm aware of is the fact that memory beyond 4gigs can
> be accessed directly -- but surely there must be other benefits as well. I
> imagine that the speed at which data is transferred across the bus must be
> doubled due to the fatter data path... but given that I'd still be limited
> by the I/O speed of the drives, is the performance improvement even
> relevant?
> Sorry for the newbie questions. I just want to avoid having some slick
> talking salesman sell us a 64bit machine if we don't really need it. I
> want to know what questions to ask.
> Thanks...
>
|||http://www.microsoft.com/sql/techinf...vironment.mspx
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
"The One We Call 'Dave'" <ghetto@.englewood.com> wrote in message
news:yLudnZXu2Ii_AE7eRVn-gQ@.giganews.com...
> Hi,
> I'm trying to decide whether our next database server should be 32 or
> 64 bit. Could someone please explain the benefits of 64bit computing and
> the factors I should be looking at in order to determine whether it would
> be of value to me?
> The only benefit I'm aware of is the fact that memory beyond 4gigs can
> be accessed directly -- but surely there must be other benefits as well. I
> imagine that the speed at which data is transferred across the bus must be
> doubled due to the fatter data path... but given that I'd still be limited
> by the I/O speed of the drives, is the performance improvement even
> relevant?
> Sorry for the newbie questions. I just want to avoid having some slick
> talking salesman sell us a 64bit machine if we don't really need it. I
> want to know what questions to ask.
> Thanks...
>
|||> However 64 bit systems are not automatically better here. X64 servers use
> basically the same system boards as 32-bit systems.
Hi David,
Could you expand on this a bit? Excuse my ignorance here, but what do
you mean when you say that X64 servers use basically the same system boards
as 32 bit systems? How is that possible? Also, is "X64" just a generic term
that's used to refer to 64 bit computing in general or does it represent a
particular *brand* of 64 bit processors designed by Intel (ala "Pentium" or
"386")?
Thanks,
Dave
|||http://en.wikipedia.org/wiki/X64
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
"The One We Call 'Dave'" <ghetto@.englewood.com> wrote in message
news:x_SdnandWO39lEjenZ2dnUVZ_tidnZ2d@.giganews.com ...
> Hi David,
> Could you expand on this a bit? Excuse my ignorance here, but what do
> you mean when you say that X64 servers use basically the same system
> boards as 32 bit systems? How is that possible? Also, is "X64" just a
> generic term that's used to refer to 64 bit computing in general or does
> it represent a particular *brand* of 64 bit processors designed by Intel
> (ala "Pentium" or "386")?
> Thanks,
> Dave
>

Benefits of 64bit SQL?

Hi,
I'm trying to decide whether our next database server should be 32 or 64
bit. Could someone please explain the benefits of 64bit computing and the
factors I should be looking at in order to determine whether it would be of
value to me?
The only benefit I'm aware of is the fact that memory beyond 4gigs can
be accessed directly -- but surely there must be other benefits as well. I
imagine that the speed at which data is transferred across the bus must be
doubled due to the fatter data path... but given that I'd still be limited
by the I/O speed of the drives, is the performance improvement even
relevant?
Sorry for the newbie questions. I just want to avoid having some slick
talking salesman sell us a 64bit machine if we don't really need it. I want
to know what questions to ask.
Thanks..."The One We Call 'Dave'" <ghetto@.englewood.com> wrote in message
news:yLudnZXu2Ii_AE7eRVn-gQ@.giganews.com...
> Hi,
> I'm trying to decide whether our next database server should be 32 or
> 64 bit. Could someone please explain the benefits of 64bit computing and
> the factors I should be looking at in order to determine whether it would
> be of value to me?
> The only benefit I'm aware of is the fact that memory beyond 4gigs can
> be accessed directly -- but surely there must be other benefits as well.
That's pretty much it. But x64 64 bit does not add any cost to servers.
Intel and AMD's server chips are (basically) all 64 bit chips.

>I imagine that the speed at which data is transferred across the bus must
>be doubled due to the fatter data path... but given that I'd still be
>limited by the I/O speed of the drives, is the performance improvement even
>relevant?
Memory bus speed is a very important performance factor for databse servers.
With several gigabytes of data cached, moving that data in and out of the
CPU is one of the major system bottlenecks. Large on-chip L2 cache helps
here too. However 64 bit systems are not automatically better here. X64
servers use basically the same system boards as 32-bit systems.

> Sorry for the newbie questions. I just want to avoid having some slick
> talking salesman sell us a 64bit machine if we don't really need it. I
> want to know what questions to ask.
You definitely want 64bit, since it doesn't really cost you anyting. You
still have to choose between x64 and IA64-based systems. Currently dollar
for dollar x64 is the performance king, but for certian very large workloads
you might need a big IA64 box.
David|||from a performance point of view, for the same hardware and less then 4Gb
there is no difference.
above 4Gb there are small improvements at the DB level. but managing the
memory is more easier.
the performance improvement is at the SSIS & AS levels. with more then 4Gb
these 2 tools takes a big advantage of this memory.
the other advantage is at the OS level.
Standard x64 edition of windows support 32Gb while the 32bits version is
limited to 4Gb.
"The One We Call 'Dave'" <ghetto@.englewood.com> wrote in message
news:yLudnZXu2Ii_AE7eRVn-gQ@.giganews.com...
> Hi,
> I'm trying to decide whether our next database server should be 32 or
> 64 bit. Could someone please explain the benefits of 64bit computing and
> the factors I should be looking at in order to determine whether it would
> be of value to me?
> The only benefit I'm aware of is the fact that memory beyond 4gigs can
> be accessed directly -- but surely there must be other benefits as well. I
> imagine that the speed at which data is transferred across the bus must be
> doubled due to the fatter data path... but given that I'd still be limited
> by the I/O speed of the drives, is the performance improvement even
> relevant?
> Sorry for the newbie questions. I just want to avoid having some slick
> talking salesman sell us a 64bit machine if we don't really need it. I
> want to know what questions to ask.
> Thanks...
>|||x" target="_blank">http://www.microsoft.com/sql/techin...nt.msp
x
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
--
"The One We Call 'Dave'" <ghetto@.englewood.com> wrote in message
news:yLudnZXu2Ii_AE7eRVn-gQ@.giganews.com...
> Hi,
> I'm trying to decide whether our next database server should be 32 or
> 64 bit. Could someone please explain the benefits of 64bit computing and
> the factors I should be looking at in order to determine whether it would
> be of value to me?
> The only benefit I'm aware of is the fact that memory beyond 4gigs can
> be accessed directly -- but surely there must be other benefits as well. I
> imagine that the speed at which data is transferred across the bus must be
> doubled due to the fatter data path... but given that I'd still be limited
> by the I/O speed of the drives, is the performance improvement even
> relevant?
> Sorry for the newbie questions. I just want to avoid having some slick
> talking salesman sell us a 64bit machine if we don't really need it. I
> want to know what questions to ask.
> Thanks...
>|||> However 64 bit systems are not automatically better here. X64 servers use
> basically the same system boards as 32-bit systems.
Hi David,
Could you expand on this a bit? Excuse my ignorance here, but what do
you mean when you say that X64 servers use basically the same system boards
as 32 bit systems? How is that possible? Also, is "X64" just a generic term
that's used to refer to 64 bit computing in general or does it represent a
particular *brand* of 64 bit processors designed by Intel (ala "Pentium" or
"386")?
Thanks,
Dave|||http://en.wikipedia.org/wiki/X64
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
--
"The One We Call 'Dave'" <ghetto@.englewood.com> wrote in message
news:x_SdnandWO39lEjenZ2dnUVZ_tidnZ2d@.gi
ganews.com...
> Hi David,
> Could you expand on this a bit? Excuse my ignorance here, but what do
> you mean when you say that X64 servers use basically the same system
> boards as 32 bit systems? How is that possible? Also, is "X64" just a
> generic term that's used to refer to 64 bit computing in general or does
> it represent a particular *brand* of 64 bit processors designed by Intel
> (ala "Pentium" or "386")?
> Thanks,
> Dave
>

Benefits of 64 bit

I understand that the 64 environment allows more addressable memory.
Are there any additional performance benefits other than possibly those
gained by increased memory addressability?
Assuming the same database running on a 32 bit environment and a 64 bit
environment and applications hitting both environments with the same
work load. Can the 64 bit environment have a higher throughput. For
this hypothetical case let us assume that advantages of having a bigger
proc cache does not help.
cheers
KenHere is an MS enumeration of the advantages:
http://www.microsoft.com/sql/techinfo/whitepapers/advantages-64bit-environment.mspx
> Are there any additional performance benefits other than possibly those
> gained by increased memory addressability?
We've seen a roughly 40% reduction in query times on a 64bit server vs.
its 32bit equivalent (sql2k5 on both). We're using Intel with 64bit
extensions rather than Itanium.
> Assuming the same database running on a 32 bit environment and a 64 bit
> environment and applications hitting both environments with the same
> work load. Can the 64 bit environment have a higher throughput.
This does seem to be the case, though you still have to consider disk
IO limitations (assuming you're not storing your entire database in the
increased RAM on your 64bit server).
Although the performance increases are notable, and MS claims the 64bit
version is fully functional and supported, we have had a few trouble
areas with the 64bit version. SSIS seems quirky, along with
OPENDATASOURCE between 64bit and 32bit servers (not that you'd
necessarily want to use that a lot :))
All-in-all, we're not disappointed.
Have fun!
KenJ|||Proc Cache isn't the main consumer of memory which benefits being on 64 bit.
The main beneficiary is the increased data caching capability & this is by
far the most significant single reason for upgrading to 64 bit, at least
from a performance perspective.
Regards,
Greg Linwood
SQL Server MVP
<raidken@.yahoo.com> wrote in message
news:1156990437.923057.219500@.i42g2000cwa.googlegroups.com...
>I understand that the 64 environment allows more addressable memory.
> Are there any additional performance benefits other than possibly those
> gained by increased memory addressability?
> Assuming the same database running on a 32 bit environment and a 64 bit
> environment and applications hitting both environments with the same
> work load. Can the 64 bit environment have a higher throughput. For
> this hypothetical case let us assume that advantages of having a bigger
> proc cache does not help.
> cheers
> Ken
>|||I agree that the main beneficiary of increased memory is the buffer
cache. Even with 32 bit a large amounts of memory could be addresses
through AWE. Which brings up another question, does 64 bit give a
substantial performance boost by eliminating the need for AWE?
KenJ, you mentioned that query performance increased by 40%, was your
32 bit database memory bound? Do u attribute the improvement to higher
buffer hit rate, reduced IO queue length? I would be very interested in
discussing this further if you are willing.
cheers,
ken|||It appears that you are expecting to gain performance going to 64 bit. That
may very well be the case, but it may just turn out not to be case. The
outcome really depends on your workloads. I have seen the same app coming out
with lower throughput on 64 bit than on 32 bit with the same hardware. You
need to test your app to be sure.
Linchi
"raidken@.yahoo.com" wrote:
> I understand that the 64 environment allows more addressable memory.
> Are there any additional performance benefits other than possibly those
> gained by increased memory addressability?
> Assuming the same database running on a 32 bit environment and a 64 bit
> environment and applications hitting both environments with the same
> work load. Can the 64 bit environment have a higher throughput. For
> this hypothetical case let us assume that advantages of having a bigger
> proc cache does not help.
> cheers
> Ken
>|||using 64b instead of AWE provide a small boost.
if you take a look at the TPC.org web site, you'll see some benchmarks.
a 4CPU server provides 206000tpmC using SQL2005 x64 (128Gb of RAM) and
188000 tpmc with SQL 2000 (64Gb of RAM)
so with having 2times the memory on the server provides only a few advantage
and the x64 version is not so helpfull in this case.
in fact, the difference is also at the disk level, to compensate the lack of
memory the SQL 2000 benchmark use 2 time more disks (total of 30TB versus
15TB)
The advantage for small and mid sizebusiness is the ability to share the
server with multiple applications and let SQL Server to manage more memory
without locking this memory.
the AWE option lock the memory and this memory is not available for other
applications, its good for high performance and dedicated servers. But in a
real world 1 server support more then 1 application (the company install RS,
SQL and AS on the same server to reduce the license cost) locking the memory
is not good. In these conditions the x64bits version is really good, all the
server memory is used but not locked and regarding which application is more
on demand then the server balance the memory usage between them.
But for dedicated servers like intensive transactionnal systems the
advantage is small.
but the big changes are in AS2005 and SSIS where the x64bit platform provide
a huge advantage.
and to finish, because there is no difference in the price and for future
compatibility, use x64 version. There is no disadvantage of the x64 platform
versus the x32, so if you have the choice, use it!!!
also 32bits CPUs will quickly disappeared from the market with the price war
between Intel and AMD.
<raidken@.yahoo.com> wrote in message
news:1156995016.052764.299640@.i42g2000cwa.googlegroups.com...
>I agree that the main beneficiary of increased memory is the buffer
> cache. Even with 32 bit a large amounts of memory could be addresses
> through AWE. Which brings up another question, does 64 bit give a
> substantial performance boost by eliminating the need for AWE?
> KenJ, you mentioned that query performance increased by 40%, was your
> 32 bit database memory bound? Do u attribute the improvement to higher
> buffer hit rate, reduced IO queue length? I would be very interested in
> discussing this further if you are willing.
> cheers,
> ken
>|||There is some degree of overhead associated with AWE infrastructure, but
it's a relatively small part of the picture.
There's also more to compare than simply whether you can address 32Gb via 32
bit AWE or via 64 bit without AWE. For example, the 64 bit version of SQL
Server 2005 Standard Edition 2005 is limited to 32Gb RAM (on Win 2003 EE 64
bit), whilst the 32 bit version of SQL Server 2005 Standard Edition can't
get anywhere near that amount (I'm not sure what the actual amount is, but I
think it might be 4Gb)
Regards,
Greg Linwood
SQL Server MVP
<raidken@.yahoo.com> wrote in message
news:1156995016.052764.299640@.i42g2000cwa.googlegroups.com...
>I agree that the main beneficiary of increased memory is the buffer
> cache. Even with 32 bit a large amounts of memory could be addresses
> through AWE. Which brings up another question, does 64 bit give a
> substantial performance boost by eliminating the need for AWE?
> KenJ, you mentioned that query performance increased by 40%, was your
> 32 bit database memory bound? Do u attribute the improvement to higher
> buffer hit rate, reduced IO queue length? I would be very interested in
> discussing this further if you are willing.
> cheers,
> ken
>|||Hi Linchi
Any chance you can share what type of workload you've identified that
exhibits these characteristics & how this has been measured?
Regards,
Greg Linwood
SQL Server MVP
"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:173E5682-2471-4A6F-9DD7-33125DCEB413@.microsoft.com...
> It appears that you are expecting to gain performance going to 64 bit.
> That
> may very well be the case, but it may just turn out not to be case. The
> outcome really depends on your workloads. I have seen the same app coming
> out
> with lower throughput on 64 bit than on 32 bit with the same hardware. You
> need to test your app to be sure.
> Linchi
> "raidken@.yahoo.com" wrote:
>> I understand that the 64 environment allows more addressable memory.
>> Are there any additional performance benefits other than possibly those
>> gained by increased memory addressability?
>> Assuming the same database running on a 32 bit environment and a 64 bit
>> environment and applications hitting both environments with the same
>> work load. Can the 64 bit environment have a higher throughput. For
>> this hypothetical case let us assume that advantages of having a bigger
>> proc cache does not help.
>> cheers
>> Ken
>>|||raidken@.yahoo.com wrote:
> I understand that the 64 environment allows more addressable memory.
> Are there any additional performance benefits other than possibly those
> gained by increased memory addressability?
Putting aside the benefits for a moment, I'd strongly advise checking
for 64-bit availability of components where necessary. I recently got
dragged in to the later stages of a project where this hadn't been done
and had real trouble getting a 64-bit SQL 2005 installation to link
through to an old Informix box. In the end they had to roll it back to
32-bit.|||Greg;
I can't share it publicly. But if you drop me an email.
Linchi
"Greg Linwood" wrote:
> Hi Linchi
> Any chance you can share what type of workload you've identified that
> exhibits these characteristics & how this has been measured?
> Regards,
> Greg Linwood
> SQL Server MVP
> "Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
> news:173E5682-2471-4A6F-9DD7-33125DCEB413@.microsoft.com...
> > It appears that you are expecting to gain performance going to 64 bit.
> > That
> > may very well be the case, but it may just turn out not to be case. The
> > outcome really depends on your workloads. I have seen the same app coming
> > out
> > with lower throughput on 64 bit than on 32 bit with the same hardware. You
> > need to test your app to be sure.
> >
> > Linchi
> >
> > "raidken@.yahoo.com" wrote:
> >
> >> I understand that the 64 environment allows more addressable memory.
> >> Are there any additional performance benefits other than possibly those
> >> gained by increased memory addressability?
> >>
> >> Assuming the same database running on a 32 bit environment and a 64 bit
> >> environment and applications hitting both environments with the same
> >> work load. Can the 64 bit environment have a higher throughput. For
> >> this hypothetical case let us assume that advantages of having a bigger
> >> proc cache does not help.
> >>
> >> cheers
> >>
> >> Ken
> >>
> >>
>
>

Benefits of 64 bit

I understand that the 64 environment allows more addressable memory.
Are there any additional performance benefits other than possibly those
gained by increased memory addressability?
Assuming the same database running on a 32 bit environment and a 64 bit
environment and applications hitting both environments with the same
work load. Can the 64 bit environment have a higher throughput. For
this hypothetical case let us assume that advantages of having a bigger
proc cache does not help.
cheers
KenHere is an MS enumeration of the advantages:
http://www.microsoft.com/sql/techin...nt.msp
x

> Are there any additional performance benefits other than possibly those
> gained by increased memory addressability?
We've seen a roughly 40% reduction in query times on a 64bit server vs.
its 32bit equivalent (sql2k5 on both). We're using Intel with 64bit
extensions rather than Itanium.

> Assuming the same database running on a 32 bit environment and a 64 bit
> environment and applications hitting both environments with the same
> work load. Can the 64 bit environment have a higher throughput.
This does seem to be the case, though you still have to consider disk
IO limitations (assuming you're not storing your entire database in the
increased RAM on your 64bit server).
Although the performance increases are notable, and MS claims the 64bit
version is fully functional and supported, we have had a few trouble
areas with the 64bit version. SSIS seems quirky, along with
OPENDATASOURCE between 64bit and 32bit servers (not that you'd
necessarily want to use that a lot )
All-in-all, we're not disappointed.
Have fun!
KenJ|||Proc Cache isn't the main consumer of memory which benefits being on 64 bit.
The main beneficiary is the increased data caching capability & this is by
far the most significant single reason for upgrading to 64 bit, at least
from a performance perspective.
Regards,
Greg Linwood
SQL Server MVP
<raidken@.yahoo.com> wrote in message
news:1156990437.923057.219500@.i42g2000cwa.googlegroups.com...
>I understand that the 64 environment allows more addressable memory.
> Are there any additional performance benefits other than possibly those
> gained by increased memory addressability?
> Assuming the same database running on a 32 bit environment and a 64 bit
> environment and applications hitting both environments with the same
> work load. Can the 64 bit environment have a higher throughput. For
> this hypothetical case let us assume that advantages of having a bigger
> proc cache does not help.
> cheers
> Ken
>|||I agree that the main beneficiary of increased memory is the buffer
cache. Even with 32 bit a large amounts of memory could be addresses
through AWE. Which brings up another question, does 64 bit give a
substantial performance boost by eliminating the need for AWE?
KenJ, you mentioned that query performance increased by 40%, was your
32 bit database memory bound? Do u attribute the improvement to higher
buffer hit rate, reduced IO queue length? I would be very interested in
discussing this further if you are willing.
cheers,
ken|||It appears that you are expecting to gain performance going to 64 bit. That
may very well be the case, but it may just turn out not to be case. The
outcome really depends on your workloads. I have seen the same app coming ou
t
with lower throughput on 64 bit than on 32 bit with the same hardware. You
need to test your app to be sure.
Linchi
"raidken@.yahoo.com" wrote:

> I understand that the 64 environment allows more addressable memory.
> Are there any additional performance benefits other than possibly those
> gained by increased memory addressability?
> Assuming the same database running on a 32 bit environment and a 64 bit
> environment and applications hitting both environments with the same
> work load. Can the 64 bit environment have a higher throughput. For
> this hypothetical case let us assume that advantages of having a bigger
> proc cache does not help.
> cheers
> Ken
>|||using 64b instead of AWE provide a small boost.
if you take a look at the TPC.org web site, you'll see some benchmarks.
a 4CPU server provides 206000tpmC using SQL2005 x64 (128Gb of RAM) and
188000 tpmc with SQL 2000 (64Gb of RAM)
so with having 2times the memory on the server provides only a few advantage
and the x64 version is not so helpfull in this case.
in fact, the difference is also at the disk level, to compensate the lack of
memory the SQL 2000 benchmark use 2 time more disks (total of 30TB versus
15TB)
The advantage for small and mid sizebusiness is the ability to share the
server with multiple applications and let SQL Server to manage more memory
without locking this memory.
the AWE option lock the memory and this memory is not available for other
applications, its good for high performance and dedicated servers. But in a
real world 1 server support more then 1 application (the company install RS,
SQL and AS on the same server to reduce the license cost) locking the memory
is not good. In these conditions the x64bits version is really good, all the
server memory is used but not locked and regarding which application is more
on demand then the server balance the memory usage between them.
But for dedicated servers like intensive transactionnal systems the
advantage is small.
but the big changes are in AS2005 and SSIS where the x64bit platform provide
a huge advantage.
and to finish, because there is no difference in the price and for future
compatibility, use x64 version. There is no disadvantage of the x64 platform
versus the x32, so if you have the choice, use it!!!
also 32bits CPUs will quickly disappeared from the market with the price war
between Intel and AMD.
<raidken@.yahoo.com> wrote in message
news:1156995016.052764.299640@.i42g2000cwa.googlegroups.com...
>I agree that the main beneficiary of increased memory is the buffer
> cache. Even with 32 bit a large amounts of memory could be addresses
> through AWE. Which brings up another question, does 64 bit give a
> substantial performance boost by eliminating the need for AWE?
> KenJ, you mentioned that query performance increased by 40%, was your
> 32 bit database memory bound? Do u attribute the improvement to higher
> buffer hit rate, reduced IO queue length? I would be very interested in
> discussing this further if you are willing.
> cheers,
> ken
>|||There is some degree of overhead associated with AWE infrastructure, but
it's a relatively small part of the picture.
There's also more to compare than simply whether you can address 32Gb via 32
bit AWE or via 64 bit without AWE. For example, the 64 bit version of SQL
Server 2005 Standard Edition 2005 is limited to 32Gb RAM (on Win 2003 EE 64
bit), whilst the 32 bit version of SQL Server 2005 Standard Edition can't
get anywhere near that amount (I'm not sure what the actual amount is, but I
think it might be 4Gb)
Regards,
Greg Linwood
SQL Server MVP
<raidken@.yahoo.com> wrote in message
news:1156995016.052764.299640@.i42g2000cwa.googlegroups.com...
>I agree that the main beneficiary of increased memory is the buffer
> cache. Even with 32 bit a large amounts of memory could be addresses
> through AWE. Which brings up another question, does 64 bit give a
> substantial performance boost by eliminating the need for AWE?
> KenJ, you mentioned that query performance increased by 40%, was your
> 32 bit database memory bound? Do u attribute the improvement to higher
> buffer hit rate, reduced IO queue length? I would be very interested in
> discussing this further if you are willing.
> cheers,
> ken
>|||Hi Linchi
Any chance you can share what type of workload you've identified that
exhibits these characteristics & how this has been measured?
Regards,
Greg Linwood
SQL Server MVP
"Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
news:173E5682-2471-4A6F-9DD7-33125DCEB413@.microsoft.com...[vbcol=seagreen]
> It appears that you are expecting to gain performance going to 64 bit.
> That
> may very well be the case, but it may just turn out not to be case. The
> outcome really depends on your workloads. I have seen the same app coming
> out
> with lower throughput on 64 bit than on 32 bit with the same hardware. You
> need to test your app to be sure.
> Linchi
> "raidken@.yahoo.com" wrote:
>|||raidken@.yahoo.com wrote:

> I understand that the 64 environment allows more addressable memory.
> Are there any additional performance benefits other than possibly those
> gained by increased memory addressability?
Putting aside the benefits for a moment, I'd strongly advise checking
for 64-bit availability of components where necessary. I recently got
dragged in to the later stages of a project where this hadn't been done
and had real trouble getting a 64-bit SQL 2005 installation to link
through to an old Informix box. In the end they had to roll it back to
32-bit.|||Greg;
I can't share it publicly. But if you drop me an email.
Linchi
"Greg Linwood" wrote:

> Hi Linchi
> Any chance you can share what type of workload you've identified that
> exhibits these characteristics & how this has been measured?
> Regards,
> Greg Linwood
> SQL Server MVP
> "Linchi Shea" <LinchiShea@.discussions.microsoft.com> wrote in message
> news:173E5682-2471-4A6F-9DD7-33125DCEB413@.microsoft.com...
>
>