Showing posts with label building. Show all posts
Showing posts with label building. Show all posts

Thursday, March 8, 2012

64-bit Windows/64-bit SQL - External Drives

Hi,
I read in the SQL 2005 Exam guides for clustering that (p.283 - 70-443),
that if building a cluster on 64-bit Windows then must use Fibre drives?
I'm trying to verying this with help of Google/MSDN, and not found
confirmation anywhere.
Is this the case that running a cluster on 64-bit editions places these
restrictions on hardware?
If we want use 64-bit clustered system, are we basically forced to accept a
fibre-based SAN as I/O system?
Thank you.
CraigYour hardware for Cluster must be in the Hardware Compatibility List. Check
out the following site:
http://support.microsoft.com/kb/309395
--
Ekrem Ã?nsoy
"craig_amtdatatechnologies@.discussions.mi"
<craigamtdatatechnologiesdiscussionsmi@.discussions.microsoft.com> wrote in
message news:25BEEEE9-2C79-4377-83D5-CAA0574273B2@.microsoft.com...
> Hi,
> I read in the SQL 2005 Exam guides for clustering that (p.283 - 70-443),
> that if building a cluster on 64-bit Windows then must use Fibre drives?
> I'm trying to verying this with help of Google/MSDN, and not found
> confirmation anywhere.
> Is this the case that running a cluster on 64-bit editions places these
> restrictions on hardware?
> If we want use 64-bit clustered system, are we basically forced to accept
> a
> fibre-based SAN as I/O system?
>
> Thank you.
> Craig
>

64-bit Windows / 64-bit SQL - External Disk Array (cluster)

oops, post should have gone to this forum ....
Hi,
I read in the SQL 2005 Exam guides for clustering that (p.283 - 70-443),
that if building a cluster on 64-bit Windows then must use Fibre drives?
I'm trying to verying this with help of Google/MSDN, and not found
confirmation anywhere.
Is this the case that running a cluster on 64-bit editions places these
restrictions on hardware?
If we want to go 64-bit, are we basically forced to accept a fibre-based SAN
as I/O system?
Thank you.
Craig
Windows 2003 64-bit does not require fibre drives. You can use anything
internal for the nodes. The shared disk can be Parallel Attached SCSI
(though I would not), iSCSI or SAN based.
Now Windows 2008 will not support PAS, but it will support SAS, SAN, or
iSCSI.
Cheers,
Rodney R. Fournier
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering Website
http://msmvps.com/clustering - Blog
http://www.clusterhelp.com - Cluster Training
ClusterHelp.com is a Microsoft Certified Gold Partner
"craig_amtdatatechnologies@.discussions.mi"
<craigamtdatatechnologiesdiscussionsmi@.discussions .microsoft.com> wrote in
message news:B1B0C4B4-B45D-4217-AC25-3A2D7A4B362B@.microsoft.com...
> oops, post should have gone to this forum ....
> Hi,
> I read in the SQL 2005 Exam guides for clustering that (p.283 - 70-443),
> that if building a cluster on 64-bit Windows then must use Fibre drives?
> I'm trying to verying this with help of Google/MSDN, and not found
> confirmation anywhere.
> Is this the case that running a cluster on 64-bit editions places these
> restrictions on hardware?
> If we want to go 64-bit, are we basically forced to accept a fibre-based
> SAN
> as I/O system?
>
> Thank you.
> Craig
|||Thanks for reply re: this
"Rodney R. Fournier [MVP]" wrote:

> Windows 2003 64-bit does not require fibre drives. You can use anything
> internal for the nodes. The shared disk can be Parallel Attached SCSI
> (though I would not), iSCSI or SAN based.
>
> Now Windows 2008 will not support PAS, but it will support SAS, SAN, or
> iSCSI.
> Cheers,
> Rodney R. Fournier
> MVP - Windows Server - Clustering
> http://www.nw-america.com - Clustering Website
> http://msmvps.com/clustering - Blog
> http://www.clusterhelp.com - Cluster Training
> ClusterHelp.com is a Microsoft Certified Gold Partner
>
> "craig_amtdatatechnologies@.discussions.mi"
> <craigamtdatatechnologiesdiscussionsmi@.discussions .microsoft.com> wrote in
> message news:B1B0C4B4-B45D-4217-AC25-3A2D7A4B362B@.microsoft.com...
>
>

Saturday, February 25, 2012

64 bit SQL

Why bother? Planning on building new servers in the next 6 months. Any point
in dumping 32 bit?
Bob Castleman
DBA PoseurBob,
A little more background would help; What is your memory utilization like
in 32-bit? Are in in an Active/Active cluster and unable to take advantage
of AWE? What are some characteristics of your workload? With the
information I have right now I couldn't even help you choose your next car,
let-alone where your I.T. budget dollars need to go. =)
"Bob Castleman" wrote:

> Why bother? Planning on building new servers in the next 6 months. Any poi
nt
> in dumping 32 bit?
> Bob Castleman
> DBA Poseur
>
>|||Not enough info. Guilty as charged.
Current environment is a two node active-passive cluster. Currently 4
processors, 16 gig RAM. going to add 4 procs and 16 Gigs Ram this wend.
Fiber chanel to an array.
We are looking into a building a cluster with more nodes
(Active-Active-Passive, maybe).
Biggest problems are that the application is a port from an Access database
and we serve the appliction to about 200 customers, growing fast (20% per
quarter). It has not, and very likely will never be, optimized in any
meanigful way for SQL Server. Another fun thing is that each instance of
the application creates multiple database connections and leaves them open
until the user exits. This amounts to thousands of open connections at peak
times.
Bob
"Cris_Benge" <CrisBenge@.discussions.microsoft.com> wrote in message
news:DCDD3C51-759C-4BAD-BD5B-A0B64E874B7D@.microsoft.com...
> Bob,
> A little more background would help; What is your memory utilization like
> in 32-bit? Are in in an Active/Active cluster and unable to take
> advantage
> of AWE? What are some characteristics of your workload? With the
> information I have right now I couldn't even help you choose your next
> car,
> let-alone where your I.T. budget dollars need to go. =)
>
> "Bob Castleman" wrote:
>|||"Bob Castleman" <nomail@.here> wrote in message
news:Op22C6GbFHA.2124@.TK2MSFTNGP14.phx.gbl...
> Why bother? Planning on building new servers in the next 6 months. Any
point
> in dumping 32 bit?
> Bob Castleman
> DBA Poseur
>
Any point in staying 32-bit?
Buy dual-core capable Opteron machines. The licensing fee structure makes it
irresponsible to buy anything else.|||I'd get a 2005 Ford Mustang 4.6L, Dark Platinum with Charcoal leather...
"Cris_Benge" <CrisBenge@.discussions.microsoft.com> wrote in message
news:DCDD3C51-759C-4BAD-BD5B-A0B64E874B7D@.microsoft.com...
> Bob,
> A little more background would help; What is your memory utilization like
> in 32-bit? Are in in an Active/Active cluster and unable to take
advantage
> of AWE? What are some characteristics of your workload? With the
> information I have right now I couldn't even help you choose your next
car,
> let-alone where your I.T. budget dollars need to go. =)
>
> "Bob Castleman" wrote:
>
point|||I had an '02 GT Couple with a Vortech SQ trim blower and 4.10 rear gears...
and then Indiana winter taught me a lesson about traction and physics. =/
"Ty Salistean" wrote:

> I'd get a 2005 Ford Mustang 4.6L, Dark Platinum with Charcoal leather...
> "Cris_Benge" <CrisBenge@.discussions.microsoft.com> wrote in message
> news:DCDD3C51-759C-4BAD-BD5B-A0B64E874B7D@.microsoft.com...
> advantage
> car,
> point
>
>|||Superficially (based on what you've provided), I wouldn't bother going to 64
bit until the situation is more under control. All real-world reports I've
heard of are having various issues with 64-bit handling some of the basic
functionality 32-bit delivers without issue (memory leak in the dynamic proc
cache, issues with linked servers, replication, etc). If your app isn't
tuned yet, you're going to get more bang for your buck throwing intelligent
design at it instead of 64-bit / hardware.
"Bob Castleman" wrote:

> Not enough info. Guilty as charged.
> Current environment is a two node active-passive cluster. Currently 4
> processors, 16 gig RAM. going to add 4 procs and 16 Gigs Ram this wend.
> Fiber chanel to an array.
> We are looking into a building a cluster with more nodes
> (Active-Active-Passive, maybe).
> Biggest problems are that the application is a port from an Access databas
e
> and we serve the appliction to about 200 customers, growing fast (20% per
> quarter). It has not, and very likely will never be, optimized in any
> meanigful way for SQL Server. Another fun thing is that each instance of
> the application creates multiple database connections and leaves them open
> until the user exits. This amounts to thousands of open connections at pea
k
> times.
> Bob
>
> "Cris_Benge" <CrisBenge@.discussions.microsoft.com> wrote in message
> news:DCDD3C51-759C-4BAD-BD5B-A0B64E874B7D@.microsoft.com...
>
>|||Hi
I agree with Cris.
Whilst you are at it, why not buy a Unisys ES 7000?
If it is easier to throw pots of money at a bad application to buy hardware,
you might as well buy the top of the range as you will probably still need
it soon.
Get the application fixed, and save yourself a lot of trouble. Eventually
you will not be able to scale up any more and your business grinds to a
halt.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"Cris_Benge" <CrisBenge@.discussions.microsoft.com> wrote in message
news:90A70D9A-95AA-4CA8-96D2-678DD574F3C2@.microsoft.com...
> Superficially (based on what you've provided), I wouldn't bother going to
> 64
> bit until the situation is more under control. All real-world reports
> I've
> heard of are having various issues with 64-bit handling some of the basic
> functionality 32-bit delivers without issue (memory leak in the dynamic
> proc
> cache, issues with linked servers, replication, etc). If your app isn't
> tuned yet, you're going to get more bang for your buck throwing
> intelligent
> design at it instead of 64-bit / hardware.
> "Bob Castleman" wrote:
>

Monday, February 13, 2012

404 error when using Web Service

I'm building a client application that uses the SSRS Web Service. My problem
is that when I use the servername the web service works just fine. ie
http://RServer/ReportServer/reportservice.asmx
If I try to use the full DNS name of the server any call I make to the web
service returns a 404 error.
ie if I use http://RServer.sdm.dm.com/ReportServer/reportservice.asmx which
points to the same server gives me a 404 error..I've looked at the config
files for ReportServer and can't figure out what's going wrong...
Any help would be greatly appreciated..
Thanks
JasonHello Jason,
To use the FQDN name of the report server, please check the ReportServerUrl
element in the RSWebApplication.config file.
You need to specify the FQDN name for this element. Please refer this
article:
RSWebApplication Configuration File
http://msdn2.microsoft.com/en-us/library/ms155878.aspx
Hope this helps.
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================This posting is provided "AS IS" with no warranties, and confers no rights.|||Hi ,
How is everything going? Please feel free to let me know if you need any
assistance.
Sincerely,
Wei Lu
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================This posting is provided "AS IS" with no warranties, and confers no rights.