Showing posts with label installing. Show all posts
Showing posts with label installing. Show all posts

Thursday, March 22, 2012

: Preferred disk raid config when using SQL Server 2005

Hello all,
If you are planning on installing SQL Server 2005 on a WIndows 2003 SP1
server, is there a "preferred" disk configuration that gives redundancy
and fast performance? I was going to go hardware raid 5, but I fear
slow performance under heavy load. Any suggestions or ideas? Is there
a SQL Server best practice for this?
Thank you in advance for your help, ideas, and/or suggestions!
- Mike
Listoff wrote:
> Hello all,
> If you are planning on installing SQL Server 2005 on a WIndows 2003 SP1
> server, is there a "preferred" disk configuration that gives redundancy
> and fast performance? I was going to go hardware raid 5, but I fear
> slow performance under heavy load. Any suggestions or ideas? Is there
> a SQL Server best practice for this?
> Thank you in advance for your help, ideas, and/or suggestions!
> - Mike
>
Mike,
There are a lot of different opinions on this subject, but generally
it's best practice to seperate database files, logfiles and OS
files/tempdb on different disk arrays.
Depending on your load and application, it can be worth putting tempdb
on it's own array as well, but I'd say that in many cases it will be ok
to have tempdb together with the OS. Furthermore you could also consider
putting your swap file somewhere different from the OS drive, but in
most cases I don't think it will be worth the effort.
When it comes to RAID, there're also many different opinions, but again
I think that most people will agree that an ok setup will be to put you
OS on RAID 1, Databasefiles on RAID 5 and logfiles on RAID 1 (or 1+0).
This will be a decent setup in most cases. If you have enough
disks/money, you could put you databasefiles on a RAID 10 which in some
situations will perform better than RAID 5.
Bottomline is that you gain the most by ensuring that you split OS,
database file and logfile on physical different units (disks) and then
avoiding RAID 5 for your logfiles. What ever you do after that in terms
of RAID configuration, arrays on different controllers etc. will give
you "slightly" better performance, but might be to little to be noticed
by your users.
Last, but not least, you should also consider where you put you backup
files. Best of all you put them on their own array - both from a
performance and safety point of view. IF you only plan to do backup once
a day or so, it might not matter much in terms of performance, but if
you do logfile backup every 15 minutes on a heavy loaded server, it
might make a difference.
HTH
Regards
Steen
|||Wow! That makes a lot of sense and helps out a lot! Thank you guys
for your help! -Mike

: Preferred disk raid config when using SQL Server 2005

Hello all,
If you are planning on installing SQL Server 2005 on a WIndows 2003 SP1
server, is there a "preferred" disk configuration that gives redundancy
and fast performance? I was going to go hardware raid 5, but I fear
slow performance under heavy load. Any suggestions or ideas? Is there
a SQL Server best practice for this?
Thank you in advance for your help, ideas, and/or suggestions!
- MikeListoff wrote:
> Hello all,
> If you are planning on installing SQL Server 2005 on a WIndows 2003 SP1
> server, is there a "preferred" disk configuration that gives redundancy
> and fast performance? I was going to go hardware raid 5, but I fear
> slow performance under heavy load. Any suggestions or ideas? Is there
> a SQL Server best practice for this?
> Thank you in advance for your help, ideas, and/or suggestions!
> - Mike
>
Mike,
There are a lot of different opinions on this subject, but generally
it's best practice to seperate database files, logfiles and OS
files/tempdb on different disk arrays.
Depending on your load and application, it can be worth putting tempdb
on it's own array as well, but I'd say that in many cases it will be ok
to have tempdb together with the OS. Furthermore you could also consider
putting your swap file somewhere different from the OS drive, but in
most cases I don't think it will be worth the effort.
When it comes to RAID, there're also many different opinions, but again
I think that most people will agree that an ok setup will be to put you
OS on RAID 1, Databasefiles on RAID 5 and logfiles on RAID 1 (or 1+0).
This will be a decent setup in most cases. If you have enough
disks/money, you could put you databasefiles on a RAID 10 which in some
situations will perform better than RAID 5.
Bottomline is that you gain the most by ensuring that you split OS,
database file and logfile on physical different units (disks) and then
avoiding RAID 5 for your logfiles. What ever you do after that in terms
of RAID configuration, arrays on different controllers etc. will give
you "slightly" better performance, but might be to little to be noticed
by your users.
Last, but not least, you should also consider where you put you backup
files. Best of all you put them on their own array - both from a
performance and safety point of view. IF you only plan to do backup once
a day or so, it might not matter much in terms of performance, but if
you do logfile backup every 15 minutes on a heavy loaded server, it
might make a difference.
HTH
Regards
Steen|||Wow! That makes a lot of sense and helps out a lot! Thank you guys
for your help! -Mike

: Preferred disk raid config when using SQL Server 2005

Hello all,
If you are planning on installing SQL Server 2005 on a WIndows 2003 SP1
server, is there a "preferred" disk configuration that gives redundancy
and fast performance? I was going to go hardware raid 5, but I fear
slow performance under heavy load. Any suggestions or ideas? Is there
a SQL Server best practice for this?
Thank you in advance for your help, ideas, and/or suggestions!
- MikeRAID 0+1
"Listoff" <fastxlr8r@.hotmail.com> wrote in message
news:1131642400.414148.236860@.g14g2000cwa.googlegroups.com...
> Hello all,
> If you are planning on installing SQL Server 2005 on a WIndows 2003 SP1
> server, is there a "preferred" disk configuration that gives redundancy
> and fast performance? I was going to go hardware raid 5, but I fear
> slow performance under heavy load. Any suggestions or ideas? Is there
> a SQL Server best practice for this?|||Listoff wrote:
> Hello all,
> If you are planning on installing SQL Server 2005 on a WIndows 2003 SP1
> server, is there a "preferred" disk configuration that gives redundancy
> and fast performance? I was going to go hardware raid 5, but I fear
> slow performance under heavy load. Any suggestions or ideas? Is there
> a SQL Server best practice for this?
> Thank you in advance for your help, ideas, and/or suggestions!
> - Mike
>
Mike,
There are a lot of different opinions on this subject, but generally
it's best practice to seperate database files, logfiles and OS
files/tempdb on different disk arrays.
Depending on your load and application, it can be worth putting tempdb
on it's own array as well, but I'd say that in many cases it will be ok
to have tempdb together with the OS. Furthermore you could also consider
putting your swap file somewhere different from the OS drive, but in
most cases I don't think it will be worth the effort.
When it comes to RAID, there're also many different opinions, but again
I think that most people will agree that an ok setup will be to put you
OS on RAID 1, Databasefiles on RAID 5 and logfiles on RAID 1 (or 1+0).
This will be a decent setup in most cases. If you have enough
disks/money, you could put you databasefiles on a RAID 10 which in some
situations will perform better than RAID 5.
Bottomline is that you gain the most by ensuring that you split OS,
database file and logfile on physical different units (disks) and then
avoiding RAID 5 for your logfiles. What ever you do after that in terms
of RAID configuration, arrays on different controllers etc. will give
you "slightly" better performance, but might be to little to be noticed
by your users.
Last, but not least, you should also consider where you put you backup
files. Best of all you put them on their own array - both from a
performance and safety point of view. IF you only plan to do backup once
a day or so, it might not matter much in terms of performance, but if
you do logfile backup every 15 minutes on a heavy loaded server, it
might make a difference.
HTH
Regards
Steen|||Wow! That makes a lot of sense and helps out a lot! Thank you guys
for your help! -Mike

Thursday, February 16, 2012

**URGENT** Please Help ! Installation Issue

While installing MSRS i have taken care of all pre-requisites. I am
installing it on Windows 2003 server machine. I want to have the remote
sql-server instance for my reporting services. For Sql-server, i have taken
'Mixed mode installation' and given the username & password as 'sa'. As
specified if sql-server is a remote instance, then we should use sql server
Authentication as the 'Credential Type'.
I have selected the service account as 'Domain account'. And for Report
server database i have selected Sql login option & provided the username &
password as 'sa'. But its giving error as 'Login failed for user
domainname\machinename$'.
The exact error message is given below
"Sql setup failed to connect to the database service for server
configuration. The error was: Login failed for user
'Americas\HTNESX605VM09$'. Refer to the server error logs and setup logs for
more infirmation."
Did anyone encountered this problem before. This is very urgent if anyone
can give there suggestions for this problem.
Note: I am carrying out a remote installation connecting to my VMware server
using Terminal Services.
Thanks in advance.
Rajendra VaishnavSounds to me like the TS machine is not authenticated to do installations on
the SQL Server machine.
-prophead
"Rajendra" wrote:
> While installing MSRS i have taken care of all pre-requisites. I am
> installing it on Windows 2003 server machine. I want to have the remote
> sql-server instance for my reporting services. For Sql-server, i have taken
> 'Mixed mode installation' and given the username & password as 'sa'. As
> specified if sql-server is a remote instance, then we should use sql server
> Authentication as the 'Credential Type'.
> I have selected the service account as 'Domain account'. And for Report
> server database i have selected Sql login option & provided the username &
> password as 'sa'. But its giving error as 'Login failed for user
> domainname\machinename$'.
> The exact error message is given below
> "Sql setup failed to connect to the database service for server
> configuration. The error was: Login failed for user
> 'Americas\HTNESX605VM09$'. Refer to the server error logs and setup logs for
> more infirmation."
> Did anyone encountered this problem before. This is very urgent if anyone
> can give there suggestions for this problem.
> Note: I am carrying out a remote installation connecting to my VMware server
> using Terminal Services.
> Thanks in advance.
> Rajendra Vaishnav
>|||Hi Prophead,
The terminal server should have access to Sql server. While installing MSRS,
i had configured to use Sql authentication. So, ideally when try to connect
to the remote sql server to do the installation it should use Sql
authentication instead of windows authentication. Even if it is trying to use
the windows authentication, i am surprised why it should use an account
something like <domain name>\<servername$> instead I would only expect it to
use <domain name>\<user name>. Kindly advice.
Could this be to do something with installing MSMRS from Terminal services.
I am stuck at this point and need some help in proceeding further.
Thanks in advance.
Rajendra Vaishnav
"prophead" wrote:
> Sounds to me like the TS machine is not authenticated to do installations on
> the SQL Server machine.
> -prophead
> "Rajendra" wrote:
> > While installing MSRS i have taken care of all pre-requisites. I am
> > installing it on Windows 2003 server machine. I want to have the remote
> > sql-server instance for my reporting services. For Sql-server, i have taken
> > 'Mixed mode installation' and given the username & password as 'sa'. As
> > specified if sql-server is a remote instance, then we should use sql server
> > Authentication as the 'Credential Type'.
> >
> > I have selected the service account as 'Domain account'. And for Report
> > server database i have selected Sql login option & provided the username &
> > password as 'sa'. But its giving error as 'Login failed for user
> > domainname\machinename$'.
> >
> > The exact error message is given below
> > "Sql setup failed to connect to the database service for server
> > configuration. The error was: Login failed for user
> > 'Americas\HTNESX605VM09$'. Refer to the server error logs and setup logs for
> > more infirmation."
> >
> > Did anyone encountered this problem before. This is very urgent if anyone
> > can give there suggestions for this problem.
> >
> > Note: I am carrying out a remote installation connecting to my VMware server
> > using Terminal Services.
> >
> > Thanks in advance.
> > Rajendra Vaishnav
> >|||I don't have an answer for you, Ragendra, so I posted this thread as a new
question in hopes one of the MS guys will answer. It is posted under the
subject "Installation Security Issue".
-prophead
"prophead" wrote:
> Sounds to me like the TS machine is not authenticated to do installations on
> the SQL Server machine.
> -prophead
> "Rajendra" wrote:
> > While installing MSRS i have taken care of all pre-requisites. I am
> > installing it on Windows 2003 server machine. I want to have the remote
> > sql-server instance for my reporting services. For Sql-server, i have taken
> > 'Mixed mode installation' and given the username & password as 'sa'. As
> > specified if sql-server is a remote instance, then we should use sql server
> > Authentication as the 'Credential Type'.
> >
> > I have selected the service account as 'Domain account'. And for Report
> > server database i have selected Sql login option & provided the username &
> > password as 'sa'. But its giving error as 'Login failed for user
> > domainname\machinename$'.
> >
> > The exact error message is given below
> > "Sql setup failed to connect to the database service for server
> > configuration. The error was: Login failed for user
> > 'Americas\HTNESX605VM09$'. Refer to the server error logs and setup logs for
> > more infirmation."
> >
> > Did anyone encountered this problem before. This is very urgent if anyone
> > can give there suggestions for this problem.
> >
> > Note: I am carrying out a remote installation connecting to my VMware server
> > using Terminal Services.
> >
> > Thanks in advance.
> > Rajendra Vaishnav
> >

Thursday, February 9, 2012

(Repost) Problems installing SQL 2005 Express after trying VS.NET 2005 Beta 2

Repost: This message had moved into another thread. Not sure why so I thought I'd repost as a new thread just to make sure it gets read ok :)
-
Hi Everyone,
I recently installed Visual Studio .NET 2005 Beta 2 which included SQL 2005 Community Technology Preview. After installing it all, I was no longer able to connect to my SQL 2000 instance in Enterprise Manager. The application opened ok but whenever I tried to browse the server or register it again, it was giving me an error relating to named pipes which really confused me since I was trying to connect to a SQL 2000 database through the SQL 2000 application. I was able to use the 2005 equivalent application (the name eludes me right now) to connect to the \SQLEXPRESS instance. All this time I could still connect to the default instance through Query Analyser and my .NET Web Applications that used SQL databases.
I later had to uninstall the betas because I needed a newer version of the .NET Framework to work with DotNetNuke 4.0. (A whole other story there...)
After uninstalling everything relating to the betas (which I had to do carefully in a prescribed order) I found that I couldn't even open Enterprise Manager properly. It had a big error message in the main display window. I discovered from a forum somewhere that I had to re-register a dll file to fix it. I did this and everything was back to normal.
(pause for breath)
OK, so then I downloaded Visual Web Developer 2005 Express Edition and installed it. Everything was great until the end of the SQL Server 2005 Express Edition setup when I was told it had failed to install. I haven't looked through ALL the log files but in the summary log file, the following message is reported for all three errors:
"[Microsoft][SQL Native Client]Shared Memory Provider: No process is on the other end of the pipe."
I am running Windows XP, SP2 with everything up to date in Windows Update. The Beta 2 of VS.NET was the only beta software I've installed. I'm not trying to connect to a different machine or anything either. VS and SQL are both on the same machine. The only other thing that may be relevant is that the SQL 2000 I have is an evaulation version. I don't think that affects it but you never know. It's often the most overlooked variable that trips you.
Does anyone have any suggestions about how to remedy this?
Thanks for taking the time to read about my problem :)Update:
I solved the problem by backing up my data and re-installing Windows. I now have Visual Web Developer and SQL 2005 Express running alongside Visual Studio 2003 Enterprise Developer, MSDE and SQL 2000.
I don't know if there was a simpler solution but I had spent too much time on it already. Hurrah for my new Maxtor OneTouch II external 300GB beast that carried the burden of my data during these difficult hours!

(Repost) Problems installing SQL 2005 Express after trying VS.NET 2005 Beta 2

Repost: This message had moved into another thread. Not sure why so I thought I'd repost as a new thread just to make sure it gets read ok :)
-
Hi Everyone,
I recently installed Visual Studio .NET 2005 Beta 2 which included SQL 2005 Community Technology Preview. After installing it all, I was no longer able to connect to my SQL 2000 instance in Enterprise Manager. The application opened ok but whenever I tried to browse the server or register it again, it was giving me an error relating to named pipes which really confused me since I was trying to connect to a SQL 2000 database through the SQL 2000 application. I was able to use the 2005 equivalent application (the name eludes me right now) to connect to the \SQLEXPRESS instance. All this time I could still connect to the default instance through Query Analyser and my .NET Web Applications that used SQL databases.
I later had to uninstall the betas because I needed a newer version of the .NET Framework to work with DotNetNuke 4.0. (A whole other story there...)
After uninstalling everything relating to the betas (which I had to do carefully in a prescribed order) I found that I couldn't even open Enterprise Manager properly. It had a big error message in the main display window. I discovered from a forum somewhere that I had to re-register a dll file to fix it. I did this and everything was back to normal.
(pause for breath)
OK, so then I downloaded Visual Web Developer 2005 Express Edition and installed it. Everything was great until the end of the SQL Server 2005 Express Edition setup when I was told it had failed to install. I haven't looked through ALL the log files but in the summary log file, the following message is reported for all three errors:
"[Microsoft][SQL Native Client]Shared Memory Provider: No process is on the other end of the pipe."
I am running Windows XP, SP2 with everything up to date in Windows Update. The Beta 2 of VS.NET was the only beta software I've installed. I'm not trying to connect to a different machine or anything either. VS and SQL are both on the same machine. The only other thing that may be relevant is that the SQL 2000 I have is an evaulation version. I don't think that affects it but you never know. It's often the most overlooked variable that trips you.
Does anyone have any suggestions about how to remedy this?
Thanks for taking the time to read about my problem :)Update:

I solved the problem by backing up my data and re-installing Windows. I

now have Visual Web Developer and SQL 2005 Express running alongside

Visual Studio 2003 Enterprise Developer, MSDE and SQL 2000.

I don't know if there was a simpler solution but I had spent too much

time on it already. Hurrah for my new Maxtor OneTouch II external 300GB

beast that carried the burden of my data during these difficult hours!