Backing up and restoring SQL Server

I want to reformat my servers harddrive and install a newer operating
system (Win 2003). I am running SQL Server 2000 with about 10
databases. What is the best way to backup and restore SQL Server for
this so I don't lose anything.
Thanks,
RickRick (rick@.abasoftware.com) writes:
> I want to reformat my servers harddrive and install a newer operating
> system (Win 2003). I am running SQL Server 2000 with about 10
> databases. What is the best way to backup and restore SQL Server for
> this so I don't lose anything.

Look at http://support.microsoft.com/defaul...kb;EN-US;224071.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp

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 Memory

Hello
We have 2 servers in a cluster environment with 12 GB each. We install
SQL server 2000 in them and use the switches /3GB /PAE and use AWE enable
option. We allocated 7GB for SQL along with enough room for the OS and other
apps currently running on that box. My question is, when I check the Task
manager, it only shows that SQL uses 150Kb for memory although you can see
under memory counters that 7.5 is been used. Why can we not see SQL using
more that 150KB? is there anything wrong in our setting? Below are the Store
procedures used to enable AWE and allocate 7GB.
SP_CONFIGURE 'show advanced options', 1
RECONFIGURE
GO
SP_CONFIGURE 'awe enabled', 1
RECONFIGURE
GO
SP_CONFIGURE 'max server memory', 7168
RECONFIGURE
GO
ThanksFirstly... if you have AWE, you dont need /3GB switch
Now coming to your question: SQL Server when its started it starts
taking memory from 1KB and grows as the resources need more memory...
and once it reaches min server memory, it will never go back to less
than Min Server memory..until you restart the SQL again.
And by configuring 7GB as Max Server memory, you are limiting the SQL
to not consume more than that...
And incase in some scenerio where SQL has any amount of memory and if
OS need some of that.. it will release that memory only if SQL doesnt
need that at that point of time.
So if you see that SQL is using only 150KB, then dont be alarmed.. its
expected behaviour|||Task manager isn't AWE/PAE aware. Use performance monitor.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Dario" <Dario@.discussions.microsoft.com> wrote in message
news:CF884EB2-F09C-4412-8FC9-547CFC6844CC@.microsoft.com...
> Hello
> We have 2 servers in a cluster environment with 12 GB each. We install
> SQL server 2000 in them and use the switches /3GB /PAE and use AWE enable
> option. We allocated 7GB for SQL along with enough room for the OS and other
> apps currently running on that box. My question is, when I check the Task
> manager, it only shows that SQL uses 150Kb for memory although you can see
> under memory counters that 7.5 is been used. Why can we not see SQL using
> more that 150KB? is there anything wrong in our setting? Below are the Store
> procedures used to enable AWE and allocate 7GB.
> SP_CONFIGURE 'show advanced options', 1
> RECONFIGURE
> GO
> SP_CONFIGURE 'awe enabled', 1
> RECONFIGURE
> GO
> SP_CONFIGURE 'max server memory', 7168
> RECONFIGURE
> GO
> Thanks
>
>

AWE

Hi,
I have a new server that hild hosl 4GB RAM on a Windows
Server. I will install on this server SQL 2000 Enterprise
Edition. Shoul i enable AWE to use for instance 3.5 of
RAM ?
Thanks
Mike
HI
Use the /PAE swith in boot.ini, but I recommend use the /3GB switch and use only 3 GB for SQL Sever.
Read:
Large Memory Support Is Available in Windows 2000 and Windows Server 2003
<http://support.microsoft.com/default...1&PA=1&SD=HSCH>
JBandi

AWE

Hi,
I have a new server that hild hosl 4GB RAM on a Windows
Server. I will install on this server SQL 2000 Enterprise
Edition. Shoul i enable AWE to use for instance 3.5 of
RAM ?
Thanks
MikeH
Use the /PAE swith in boot.ini, but I recommend use the /3GB switch and use only 3 GB for SQL Sever
Read
Large Memory Support Is Available in Windows 2000 and Windows Server 200
<http://support.microsoft.com/default.aspx?scid=kb;en-us;838150&FR=1&PA=1&SD=HSCH
JBandi

AWE

Hi,
I have a new server that hild hosl 4GB RAM on a Windows
Server. I will install on this server SQL 2000 Enterprise
Edition. Shoul i enable AWE to use for instance 3.5 of
RAM ?
Thanks
MikeHI
Use the /PAE swith in boot.ini, but I recommend use the /3GB switch and use
only 3 GB for SQL Sever.
Read:
Large Memory Support Is Available in Windows 2000 and Windows Server 2003
<[url]http://support.microsoft.com/default.aspx?scid=kb;en-us;838150&FR=1&PA=1&SD=HSCH[
/url]>
JBandi

Avoiding clear text passwords and editing of packages

Hi!

I have an SQL Server where only a group of sysadmins have access to install DTSX packages. Those DTSX packages are developed by another team that does not have access to the production SQL Server. They use their own SQL Server.

In order to make it as simple as possible to install these packages by the sysadmins, I suggested the use of configuration files. The files are associated with the job that executes the package and all that has to be done to install the package is copy it to the file system or import it into the SQL Server. Developers use their configuration file, sysadmins user theirs. Nothing new here.

The problem is that some of the packages have to access some old systems and we cannot use integrated authentication. We have to use SQL authentication and therefore specify a user account and password in the connection string. If this is stored in the configuration file, it is available in clear text! If I store the configuration in the package itself using ProtectSensitiveWithPassword protection level, the sysadmins will have to edit every DTSX package to reset the connections to the production environment (the developers always send them with their development configurations) and I don't want that. If I store it in a SQL Server database, it seems the sysadmins also have to edit the package to point the package configuration to the correct database and set the configuration filter.

Another solution is to store the credentials in clear text in the configuration file but set the file system permissions on that file so only the account that executes the package can read them (this is what I'm implementing if nothing better comes up...)

Is there any other way to do this? Am I doing something wrong?

Thanks in advance.

Rui Covelo wrote:

Hi!
Another solution is to store the credentials in clear text in the configuration file but set the file system permissions on that file so only the account that executes the package can read them (this is what I'm implementing if nothing better comes up...)

Is there any other way to do this? Am I doing something wrong?

Thanks in advance.

I don't see any other way. Unless that you want to save you the time of oppening each package to change the credentials in every package; I think you are better dealing with the passwords in plain text and securing the place where they live. BTW, you can use Env. variables or a SQL table to place those connection strings if that makes you feel more secure.

This is just my opinion and not an entry for the 'best practice' book

Rafael Salas

|||

I don't see using configuration files is not that big issue that people seem to think of it. So what if they use clear text, all that means is that you need secure them correctly. You probably have a password store already. Does it have password complexity? Does it have group membership? Do passwords expire? Can you manage access centrally? If not it would seem obvious that AD is going to do a better job, so use it :)

The issue I think is more about how people have viewed file permissions in the past, or rather the lack of them. Use them correctly and will be more secure than a single password embedded in a package, and don't forget those jobs that also have the password too. AD is much harder to circumvent any controls around it. People just don't use file permissions, because it is "hard", well get it right and it is more secure, so what sounds better?

|||

I would re-iterate what Darren has said.

At some point someone somewhere needs to know what some password is to open up access to a securable. If that password is the password of a Windows AD account then so much the better. Security is one of the main things that AD is there for.

-Jamie

|||Thanks for your answers!

Available platforms...?

HI,
Can someone please tell me if I can install the SQL Server Client code on and AIX 4.3.3 O/S? When I say client, what I need to do is to install the client code locally on an IBM Infomration Integrator server to enable connectivity to a remote/disparate SQLServer dB.
Your help in this matter will be hugely appreciated.
Regards
Alex.No. You may have to compile your own client with libraries such as freeTDS.
MS was supposedly going to release some SQL client tools for Unix (the rumor
I heard anyway, not meant to create any rumor). But I don't know whether
that is right now.
--
Linchi Shea
linchi_shea@.NOSPAMml.com
"Alex Crockett" <anonymous@.discussions.microsoft.com> wrote in message
news:4521C7EF-9B2E-4CCF-9F6E-D4797C956D15@.microsoft.com...
> HI,
> Can someone please tell me if I can install the SQL Server Client code on
and AIX 4.3.3 O/S? When I say client, what I need to do is to install the
client code locally on an IBM Infomration Integrator server to enable
connectivity to a remote/disparate SQLServer dB.
> Your help in this matter will be hugely appreciated.
> Regards
> Alex.