Back or restore operation terminating abnormally

Hi all,
Microsoft SQL Server 7.00 - 7.00.1094 (Intel X86) May 29 2003 15:21:25
Copyright (c) 1988-2002 Microsoft Corporation Enterprise Edition on
Windows NT 5.0 (Build 2195: Service Pack 4)
using windows system login, Loged in as Administrator, have full rights.
Getting the following Error message when trying to restore a database?
Back or restore operation terminating abnormally. SQLDumpExceptionhandler:
process 9 generated Fatal excetion c0000005 Exception_Access_Violation.
SQL Server is terminating this process.
No luck searching on this error. what I did find didn't help.
thanks
gvgv
I see that you do that from .NET application.
When you run the same statement from QA do you get the same error?
Can you show us you RESTORE command?
"gv" <viatorg@.musc.edu> wrote in message
news:uXJNhiWOFHA.2680@.TK2MSFTNGP09.phx.gbl...
> Hi all,
> Microsoft SQL Server 7.00 - 7.00.1094 (Intel X86) May 29 2003 15:21:25
> Copyright (c) 1988-2002 Microsoft Corporation Enterprise Edition on
> Windows NT 5.0 (Build 2195: Service Pack 4)
> using windows system login, Loged in as Administrator, have full rights.
> Getting the following Error message when trying to restore a database?
> Back or restore operation terminating abnormally. SQLDumpExceptionhandler:
> process 9 generated Fatal excetion c0000005 Exception_Access_Violation.
> SQL Server is terminating this process.
> No luck searching on this error. what I did find didn't help.
> thanks
> gv
>

AWE? / Windows 2003 R2 x64 / SQL Server 2000 x86 / 8GB RAM

We had to install SQL 2000 on a 64-bit Intel x64 server. We quickly
learned that SQL 2000 x64 can only be installed on 64-bit Intel
Itanium (IA64) servers, so were forced to install the 32bit x86
version.
When running a 64-bit version of Windows 2003 with 8gb of RAM, we no
longer need to set the /3GB and /PAE switches because all of the
memory is addressable on the 64-bit platform.
Now that we are running 32-bit SQL Server 2000 Enterprise x86 on 64bit
Windows 2003 R2 Enterprise x64, do we need to enable AWE in SQL Server
like we had to on 32-bit Windows?
Here's how we did it on 32bit SQL:
http://www.sql-server-performance.com/awe_memory.asp
It appears that AWE is only required/supported on 32-bit OS:
http://www.microsoft.com/sql/editions/64bit/sql64bitadvantages.mspx
AWE is a set of memory management extensions to the Microsoft Win32?
API that allows applications to address memory beyond the 4GB
limitation. Using AWE, applications can acquire physical memory as
nonpaged memory, and then dynamically map views of the nonpaged memory
to the 32-bit address space.
32 it SQL Server is 32 bit. In order of a 32 bit app to see more than 2 or 3 GB memory, it need to
use the AWE extensions. So, yes, you need to sp_configure your 32 bit SQL Server to use AWE.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
<mikemiller.innova@.gmail.com> wrote in message
news:1176395603.695552.226090@.b75g2000hsg.googlegr oups.com...
We had to install SQL 2000 on a 64-bit Intel x64 server. We quickly
learned that SQL 2000 x64 can only be installed on 64-bit Intel
Itanium (IA64) servers, so were forced to install the 32bit x86
version.
When running a 64-bit version of Windows 2003 with 8gb of RAM, we no
longer need to set the /3GB and /PAE switches because all of the
memory is addressable on the 64-bit platform.
Now that we are running 32-bit SQL Server 2000 Enterprise x86 on 64bit
Windows 2003 R2 Enterprise x64, do we need to enable AWE in SQL Server
like we had to on 32-bit Windows?
Here's how we did it on 32bit SQL:
http://www.sql-server-performance.com/awe_memory.asp
It appears that AWE is only required/supported on 32-bit OS:
http://www.microsoft.com/sql/editions/64bit/sql64bitadvantages.mspx
AWE is a set of memory management extensions to the Microsoft Win32?
API that allows applications to address memory beyond the 4GB
limitation. Using AWE, applications can acquire physical memory as
nonpaged memory, and then dynamically map views of the nonpaged memory
to the 32-bit address space.

AWE? / Windows 2003 R2 x64 / SQL Server 2000 x86 / 8GB RAM

We had to install SQL 2000 on a 64-bit Intel x64 server. We quickly learned that SQL 2000 x64 can only be installed on 64-bit Intel Itanium (IA64) servers, so were forced to install the 32bit x86 version.
When running a 64-bit version of Windows 2003 with 8gb of RAM, we no longer need to set the /3GB and /PAE switches because all of the memory is addressable on the 64-bit platform.
Now that we are running 32-bit SQL Server 2000 Enterprise x86 on 64bit Windows 2003 R2 Enterprise x64, do we need to enable AWE in SQL Server like we had to on 32-bit Windows?
Here's how we did it on 32bit SQL:
http://www.sql-server-performance.com/awe_memory.asp
It appears that AWE is only required/supported on 32-bit OS:
http://www.microsoft.com/sql/editio...advantages.mspx AWE is a set of memory management extensions to the Microsoft Win32 API that allows applications to address memory beyond the 4GB limitation. Using AWE, applications can acquire physical memory as nonpaged memory, and then dynamically map views of the nonpaged memory to the 32-bit address space.32 it SQL Server is 32 bit. In order of a 32 bit app to see more than 2 or 3
GB memory, it need to
use the AWE extensions. So, yes, you need to sp_configure your 32 bit SQL Se
rver to use AWE.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
<mikemiller.innova@.gmail.com> wrote in message
news:1176395603.695552.226090@.b75g2000hsg.googlegroups.com...
We had to install SQL 2000 on a 64-bit Intel x64 server. We quickly
learned that SQL 2000 x64 can only be installed on 64-bit Intel
Itanium (IA64) servers, so were forced to install the 32bit x86
version.
When running a 64-bit version of Windows 2003 with 8gb of RAM, we no
longer need to set the /3GB and /PAE switches because all of the
memory is addressable on the 64-bit platform.
Now that we are running 32-bit SQL Server 2000 Enterprise x86 on 64bit
Windows 2003 R2 Enterprise x64, do we need to enable AWE in SQL Server
like we had to on 32-bit Windows?
Here's how we did it on 32bit SQL:
http://www.sql-server-performance.com/awe_memory.asp
It appears that AWE is only required/supported on 32-bit OS:
http://www.microsoft.com/sql/editio...advantages.mspx
AWE is a set of memory management extensions to the Microsoft Win32?
API that allows applications to address memory beyond the 4GB
limitation. Using AWE, applications can acquire physical memory as
nonpaged memory, and then dynamically map views of the nonpaged memory
to the 32-bit address space.

AWE Question

What would be the optimal max server memory setting for the following
machine?
Dedicated SQL Server:
Intel Xeon MP 3.3 GHz (4 physical Processors)
136 GB (C Drive)
8.0 GB RAM
Microsoft Windows 2003 Enterprise Edition Service Pack 1 Build 3790
SQL Server Enterprise 2000, with SP3
The machine has following database sizes. All databases are being accessed
all the time by around 300+ concurrent users.
DB#1 - 536.44 MB
DB#2 - 1.09 GB
DB#3 - 3.27 GB
DB#4 - 4.92 GB
DB#5 - 5.29 GB
DB#6 - 15.09 GB
DB#7 - 50.13 GB
I am still learning the ins and outs of configuring higher end db servers.
Are there any other non-default server settings that I should change?"Isaac Alexander" <isaacNOSPAM@.goNOSPAMprocura.com> wrote in message
news:uqJkBN9uGHA.4756@.TK2MSFTNGP04.phx.gbl...
> What would be the optimal max server memory setting for the following
> machine?
> Dedicated SQL Server:
> Intel Xeon MP 3.3 GHz (4 physical Processors)
> 136 GB (C Drive)
> 8.0 GB RAM
> Microsoft Windows 2003 Enterprise Edition Service Pack 1 Build 3790
> SQL Server Enterprise 2000, with SP3
> The machine has following database sizes. All databases are being accessed
> all the time by around 300+ concurrent users.
> DB#1 - 536.44 MB
> DB#2 - 1.09 GB
> DB#3 - 3.27 GB
> DB#4 - 4.92 GB
> DB#5 - 5.29 GB
> DB#6 - 15.09 GB
> DB#7 - 50.13 GB
> I am still learning the ins and outs of configuring higher end db servers.
>
Does each user access all databases or does each database have its own set
of users?
If the different databsaes represent seperate applications, you should
consider dividing the server into multiple SQL instances to divide up the
memory on the box and optionally the CPU's into 2 or 3 different resource
pools. 32bit SQL Server works more efficiently when it doesn't have to use
AWE to access memory, and multiple instances allow you to easilly partition
memory and CPU resources between the workloads.
David|||>
> Does each user access all databases or does each database have its own set
> of users?
All databases are the same application (different clients on each db similar
to an ASP service).
Each user usually accesses only a single database. Admin users would need
access to all.
> If the different databsaes represent seperate applications, you should
> consider dividing the server into multiple SQL instances to divide up the
> memory on the box and optionally the CPU's into 2 or 3 different resource
> pools. 32bit SQL Server works more efficiently when it doesn't have to
> use AWE to access memory, and multiple instances allow you to easilly
> partition memory and CPU resources between the workloads.
>
Interesting option. Your making me think about that.
You mention that 32bit SQL Server works more efficiently when it doesn't use
AWE. Does it affect performance that much?
My concern is the 50 GB database itself would benefit from more then 2 GB of
RAM.
You also mention that you can configure CPUs into different resource pools.
How does this work? Do you have a knowledge base link?|||"Isaac Alexander" <isaacNOSPAM@.goNOSPAMprocura.com> wrote in message
news:%23MUPzp9uGHA.4160@.TK2MSFTNGP06.phx.gbl...
> >
>> Does each user access all databases or does each database have its own
>> set of users?
> All databases are the same application (different clients on each db
> similar to an ASP service).
> Each user usually accesses only a single database. Admin users would need
> access to all.
>> If the different databsaes represent seperate applications, you should
>> consider dividing the server into multiple SQL instances to divide up the
>> memory on the box and optionally the CPU's into 2 or 3 different resource
>> pools. 32bit SQL Server works more efficiently when it doesn't have to
>> use AWE to access memory, and multiple instances allow you to easilly
>> partition memory and CPU resources between the workloads.
> Interesting option. Your making me think about that.
> You mention that 32bit SQL Server works more efficiently when it doesn't
> use AWE. Does it affect performance that much?
> My concern is the 50 GB database itself would benefit from more then 2 GB
> of RAM.
Yes it would, but you have 7 databses and only 8G of ram. How much ram can
you afford to allocate for that one workload. And using the /3GB switch you
can give a SQL instance access to 3GB of memory without using AWE.
Also you will have one procedure cache per instance, and on 32bit SQL is
strictly limited in size. Multiple instances would have multiple procedure
caches.
"On 32-bit platforms configured with 4 GB or more of physical memory, you
can either use Address Windowing Extensions (AWE) or use multiple instances
of SQL Server as a way to fully utilize the large amount of physical memory.
AWE may work well for some scenarios; however, you should be aware that AWE
memory can only be used for data cache. The memory for procedure cache,
connections, locks, and other internal resources of SQL Server must come
from the 2 GB (or 3GB, depending on the settings used) portion of the
virtual memory. On systems needing to support a large number of databases
and user connections, multiple instances of SQL Server may be a better
approach to fully alleviate the 2 GB or 3GB memory constraint imposed by the
32-bit platform for these data structures."
http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/32bitconsolidation.mspx
> You also mention that you can configure CPUs into different resource
> pools. How does this work? Do you have a knowledge base link?
>
Simple partition of CPU's to SQL Instances should be done with the "affinity
mask" server option.
SQL Server 2005 Books Online
affinity mask Option
http://msdn2.microsoft.com/en-us/library/ms187104.aspx
Dynamic CPU allocation policies can be implemented with WSRM:
Windows System Resource Manager
http://www.microsoft.com/technet/downloads/winsrvr/wsrm.mspx
David|||"David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
message news:O$v%232B%23uGHA.3428@.TK2MSFTNGP02.phx.gbl...
> "Isaac Alexander" <isaacNOSPAM@.goNOSPAMprocura.com> wrote in message
> news:%23MUPzp9uGHA.4160@.TK2MSFTNGP06.phx.gbl...
>> >
>> Does each user access all databases or does each database have its own
>> set of users?
>> All databases are the same application (different clients on each db
>> similar to an ASP service).
>> Each user usually accesses only a single database. Admin users would need
>> access to all.
>>
>> If the different databsaes represent seperate applications, you should
>> consider dividing the server into multiple SQL instances to divide up
>> the memory on the box and optionally the CPU's into 2 or 3 different
>> resource pools. 32bit SQL Server works more efficiently when it doesn't
>> have to use AWE to access memory, and multiple instances allow you to
>> easilly partition memory and CPU resources between the workloads.
>>
>> Interesting option. Your making me think about that.
>> You mention that 32bit SQL Server works more efficiently when it doesn't
>> use AWE. Does it affect performance that much?
>> My concern is the 50 GB database itself would benefit from more then 2 GB
>> of RAM.
> Yes it would, but you have 7 databses and only 8G of ram. How much ram
> can you afford to allocate for that one workload. And using the /3GB
> switch you can give a SQL instance access to 3GB of memory without using
> AWE.
> Also you will have one procedure cache per instance, and on 32bit SQL is
> strictly limited in size. Multiple instances would have multiple
> procedure caches.
> "On 32-bit platforms configured with 4 GB or more of physical memory, you
> can either use Address Windowing Extensions (AWE) or use multiple
> instances of SQL Server as a way to fully utilize the large amount of
> physical memory. AWE may work well for some scenarios; however, you should
> be aware that AWE memory can only be used for data cache. The memory for
> procedure cache, connections, locks, and other internal resources of SQL
> Server must come from the 2 GB (or 3GB, depending on the settings used)
> portion of the virtual memory. On systems needing to support a large
> number of databases and user connections, multiple instances of SQL Server
> may be a better approach to fully alleviate the 2 GB or 3GB memory
> constraint imposed by the 32-bit platform for these data structures."
> http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/32bitconsolidation.mspx
>> You also mention that you can configure CPUs into different resource
>> pools. How does this work? Do you have a knowledge base link?
> Simple partition of CPU's to SQL Instances should be done with the
> "affinity mask" server option.
> SQL Server 2005 Books Online
> affinity mask Option
> http://msdn2.microsoft.com/en-us/library/ms187104.aspx
>
> Dynamic CPU allocation policies can be implemented with WSRM:
> Windows System Resource Manager
> http://www.microsoft.com/technet/downloads/winsrvr/wsrm.mspx
> David
>
Thanks David. This info is very helpful.|||Isaac
> Dedicated SQL Server:
> Intel Xeon MP 3.3 GHz (4 physical Processors)
> 136 GB (C Drive)
> 8.0 GB RAM
I'd consider (based on your description) MAX Memory 7GB
"Isaac Alexander" <isaacNOSPAM@.goNOSPAMprocura.com> wrote in message
news:%23$AxxK%23uGHA.4752@.TK2MSFTNGP02.phx.gbl...
> "David Browne" <davidbaxterbrowne no potted meat@.hotmail.com> wrote in
> message news:O$v%232B%23uGHA.3428@.TK2MSFTNGP02.phx.gbl...
>> "Isaac Alexander" <isaacNOSPAM@.goNOSPAMprocura.com> wrote in message
>> news:%23MUPzp9uGHA.4160@.TK2MSFTNGP06.phx.gbl...
>> >
>> Does each user access all databases or does each database have its own
>> set of users?
>> All databases are the same application (different clients on each db
>> similar to an ASP service).
>> Each user usually accesses only a single database. Admin users would
>> need access to all.
>>
>> If the different databsaes represent seperate applications, you should
>> consider dividing the server into multiple SQL instances to divide up
>> the memory on the box and optionally the CPU's into 2 or 3 different
>> resource pools. 32bit SQL Server works more efficiently when it
>> doesn't have to use AWE to access memory, and multiple instances allow
>> you to easilly partition memory and CPU resources between the
>> workloads.
>>
>> Interesting option. Your making me think about that.
>> You mention that 32bit SQL Server works more efficiently when it doesn't
>> use AWE. Does it affect performance that much?
>> My concern is the 50 GB database itself would benefit from more then 2
>> GB of RAM.
>> Yes it would, but you have 7 databses and only 8G of ram. How much ram
>> can you afford to allocate for that one workload. And using the /3GB
>> switch you can give a SQL instance access to 3GB of memory without using
>> AWE.
>> Also you will have one procedure cache per instance, and on 32bit SQL is
>> strictly limited in size. Multiple instances would have multiple
>> procedure caches.
>> "On 32-bit platforms configured with 4 GB or more of physical memory, you
>> can either use Address Windowing Extensions (AWE) or use multiple
>> instances of SQL Server as a way to fully utilize the large amount of
>> physical memory. AWE may work well for some scenarios; however, you
>> should be aware that AWE memory can only be used for data cache. The
>> memory for procedure cache, connections, locks, and other internal
>> resources of SQL Server must come from the 2 GB (or 3GB, depending on the
>> settings used) portion of the virtual memory. On systems needing to
>> support a large number of databases and user connections, multiple
>> instances of SQL Server may be a better approach to fully alleviate the 2
>> GB or 3GB memory constraint imposed by the 32-bit platform for these data
>> structures."
>> http://www.microsoft.com/technet/prodtechnol/sql/2000/deploy/32bitconsolidation.mspx
>> You also mention that you can configure CPUs into different resource
>> pools. How does this work? Do you have a knowledge base link?
>>
>> Simple partition of CPU's to SQL Instances should be done with the
>> "affinity mask" server option.
>> SQL Server 2005 Books Online
>> affinity mask Option
>> http://msdn2.microsoft.com/en-us/library/ms187104.aspx
>>
>> Dynamic CPU allocation policies can be implemented with WSRM:
>> Windows System Resource Manager
>> http://www.microsoft.com/technet/downloads/winsrvr/wsrm.mspx
>> David
> Thanks David. This info is very helpful.
>|||"Uri Dimant" <urid@.iscar.co.il> wrote in message
news:uYF1sPEvGHA.724@.TK2MSFTNGP05.phx.gbl...
> Isaac
>> Dedicated SQL Server:
>> Intel Xeon MP 3.3 GHz (4 physical Processors)
>> 136 GB (C Drive)
>> 8.0 GB RAM
>
> I'd consider (based on your description) MAX Memory 7GB
>
Thanks Uri.