dumping backups to share in different domain

Hi,
I have a sql server running in domain abc.com. de sqlserver and the sqlagent
services are running on their own useraccounts SqlServerServ@.abc.com and
SqlAgentServ@.abc.com. This server is in our own server room which we use to
host servers on our own domain 123.com.
the following task needs to be done:
make backups of the databases in sqlserver.abc.com to the file share on
fileserver.123.com by creating jobs in sqlagent.
What can not be done:
Make a trust between abc.com and 123.com since both companies don't trust
each other.
extra info.
sqlserver.abc.com
sql server 2000 standard SP3 running on
windows 2000 Standard edition (patches unknown)
this box happens to be the DC for abc.com as well (it's a test enviorment)
fileserver.123.com
windows 2000 standard edition (patches unknown)
this box is not the DC for 123.com
a share is create \\fileserver\DBbackups
and a user called SQLbackup@.123.com which has full rights to this share
What is the best way to go arround:
1) try and make the backups work using SQLbackup@.123.com
2) or try and give SQLAgentServ@.abc.com access to the fileshare on
fileserver.123.com
Is any of these two option possible at all?
are there better solutions with this setup?(we cannot change the domain
setup and memberships, and we cannot at extra boxes)
Kind regards
Edward Dortland
please reply to newsgroup ONLYSuggestions:
Install FTP server on fileserver.123.com, then
1. Do local backup on abc.com
2. Transfer these backups to fileserver.123.com using -s:filename option.
OR try this one (not sure if it will work).
1. Create LOCAL account SQLAgentServ on both computers with same password.
From Log shipping:
"Local Network Account
You can use SQL Server to start under a locally-created network account. In
the situation where there is network access required by a SQL Server
process, which is the case if you have configured SQL Server to use log
shipping, you can use network pass-through security. With pass-through
security, all machines that will be accessed by SQL Server must have the
same network account with the same password and appropriate permissions,
configured locally. Additionally, when the SQL Server process requests
resources from the second computer, traditional network security is bypassed
if the same account (under which the requesting SQL Server service is
started) exists with the same password. As long the account on the second
computer is configured with enough permission to carry out the task that is
requested by calling SQL Server, the task will be successful. "
2. Try to do backup.
HTH
Igor Raytsin
"Edward Dortland" <edwardNOSPAMMMM@.solsol.nl> wrote in message
news:104jovuket4qk0f@.corp.supernews.com...
> Hi,
> I have a sql server running in domain abc.com. de sqlserver and the
sqlagent
> services are running on their own useraccounts SqlServerServ@.abc.com and
> SqlAgentServ@.abc.com. This server is in our own server room which we use
to
> host servers on our own domain 123.com.
> the following task needs to be done:
> make backups of the databases in sqlserver.abc.com to the file share on
> fileserver.123.com by creating jobs in sqlagent.
> What can not be done:
> Make a trust between abc.com and 123.com since both companies don't trust
> each other.
> extra info.
> sqlserver.abc.com
> sql server 2000 standard SP3 running on
> Windows 2000 Standard edition (patches unknown)
> this box happens to be the DC for abc.com as well (it's a test enviorment)
> fileserver.123.com
> Windows 2000 standard edition (patches unknown)
> this box is not the DC for 123.com
> a share is create \\fileserver\DBbackups
> and a user called SQLbackup@.123.com which has full rights to this share
> What is the best way to go arround:
> 1) try and make the backups work using SQLbackup@.123.com
> 2) or try and give SQLAgentServ@.abc.com access to the fileshare on
> fileserver.123.com
> Is any of these two option possible at all?
> are there better solutions with this setup?(we cannot change the domain
> setup and memberships, and we cannot at extra boxes)
> Kind regards
>
> Edward Dortland
> please reply to newsgroup ONLY
>
>

dumping backups to share in different domain

Hi,
I have a sql server running in domain abc.com. de sqlserver and the sqlagent
services are running on their own useraccounts SqlServerServ@.abc.com and
SqlAgentServ@.abc.com. This server is in our own server room which we use to
host servers on our own domain 123.com.
the following task needs to be done:
make backups of the databases in sqlserver.abc.com to the file share on
fileserver.123.com by creating jobs in sqlagent.
What can not be done:
Make a trust between abc.com and 123.com since both companies don't trust
each other.
extra info.
sqlserver.abc.com
sql server 2000 standard SP3 running on
windows 2000 Standard edition (patches unknown)
this box happens to be the DC for abc.com as well (it's a test enviorment)
fileserver.123.com
windows 2000 standard edition (patches unknown)
this box is not the DC for 123.com
a share is create \\fileserver\DBbackups
and a user called SQLbackup@.123.com which has full rights to this share
What is the best way to go arround:
1) try and make the backups work using SQLbackup@.123.com
2) or try and give SQLAgentServ@.abc.com access to the fileshare on
fileserver.123.com
Is any of these two option possible at all?
are there better solutions with this setup?(we cannot change the domain
setup and memberships, and we cannot at extra boxes)
Kind regards
Edward Dortland
please reply to newsgroup ONLYSuggestions:
Install FTP server on fileserver.123.com, then
1. Do local backup on abc.com
2. Transfer these backups to fileserver.123.com using -s:filename option.
OR try this one (not sure if it will work).
1. Create LOCAL account SQLAgentServ on both computers with same password.
From Log shipping:
"Local Network Account
You can use SQL Server to start under a locally-created network account. In
the situation where there is network access required by a SQL Server
process, which is the case if you have configured SQL Server to use log
shipping, you can use network pass-through security. With pass-through
security, all machines that will be accessed by SQL Server must have the
same network account with the same password and appropriate permissions,
configured locally. Additionally, when the SQL Server process requests
resources from the second computer, traditional network security is bypassed
if the same account (under which the requesting SQL Server service is
started) exists with the same password. As long the account on the second
computer is configured with enough permission to carry out the task that is
requested by calling SQL Server, the task will be successful. "
2. Try to do backup.
HTH
Igor Raytsin
"Edward Dortland" <edwardNOSPAMMMM@.solsol.nl> wrote in message
news:104jovuket4qk0f@.corp.supernews.com...
> Hi,
> I have a sql server running in domain abc.com. de sqlserver and the
sqlagent
> services are running on their own useraccounts SqlServerServ@.abc.com and
> SqlAgentServ@.abc.com. This server is in our own server room which we use
to
> host servers on our own domain 123.com.
> the following task needs to be done:
> make backups of the databases in sqlserver.abc.com to the file share on
> fileserver.123.com by creating jobs in sqlagent.
> What can not be done:
> Make a trust between abc.com and 123.com since both companies don't trust
> each other.
> extra info.
> sqlserver.abc.com
> sql server 2000 standard SP3 running on
> windows 2000 Standard edition (patches unknown)
> this box happens to be the DC for abc.com as well (it's a test enviorment)
> fileserver.123.com
> windows 2000 standard edition (patches unknown)
> this box is not the DC for 123.com
> a share is create \\fileserver\DBbackups
> and a user called SQLbackup@.123.com which has full rights to this share
> What is the best way to go arround:
> 1) try and make the backups work using SQLbackup@.123.com
> 2) or try and give SQLAgentServ@.abc.com access to the fileshare on
> fileserver.123.com
> Is any of these two option possible at all?
> are there better solutions with this setup?(we cannot change the domain
> setup and memberships, and we cannot at extra boxes)
> Kind regards
>
> Edward Dortland
> please reply to newsgroup ONLY
>
>sql

DUMP TRANSACTION database WITH NO_LOG

Hello there,
I am trying to learn about MS-SQL Server on my own and am faced with a
problem that requires action quickly, even though I would prefer to take my
time and dig out the answer from all the documentation available.
On the web site that I manage, some log files grow to be as large or larger
than the MDF files themselves, and I am concernced with preserving hard disk
space for obvious reasons. I asked the web hosting company's tech support
department for a way to reduce the size of these log files, and they pointed
me to this suggestion:
DUMP TRANSACTION database WITH NO_LOG
While I have used this command to reduce the log file size successfully, I
am concerned that I am actually truncating data that has not been committed
to the database yet. Am I worrying needlessly? Or am I actually losing dat
a
when I run this command?
I have observed that when I run this query from the SQL Query Analyzer that
the log file does not instantly get smaller in size. Rather it gets
substantially smaller a few hours later. The MDF file is about 5.3 GB and
the LDF file is about 9 GB.
Thank you for whatever help you can offer.
Sincerely,
Mr. MixterMick,
Don't worry. This command will truncate committed transactions from the
transaction log. If you don't have much control over your database in terms
of backups, etc, consider changing the recovery model to simple, this means
that committed transactions are removed from the transaction log, which will
stop it growing.
Once you have changed the recovery model and truncated the log, you will
need to shrink the log file using DBCC SHRINKFILE. Look that up in BOL.
Sounds like your hosting company admins need to go on a SQL Server course.
Regards,
Mark.
"Mick Keily" wrote:

> Hello there,
> I am trying to learn about MS-SQL Server on my own and am faced with a
> problem that requires action quickly, even though I would prefer to take m
y
> time and dig out the answer from all the documentation available.
> On the web site that I manage, some log files grow to be as large or large
r
> than the MDF files themselves, and I am concernced with preserving hard di
sk
> space for obvious reasons. I asked the web hosting company's tech support
> department for a way to reduce the size of these log files, and they point
ed
> me to this suggestion:
> DUMP TRANSACTION database WITH NO_LOG
> While I have used this command to reduce the log file size successfully, I
> am concerned that I am actually truncating data that has not been committe
d
> to the database yet. Am I worrying needlessly? Or am I actually losing d
ata
> when I run this command?
> I have observed that when I run this query from the SQL Query Analyzer tha
t
> the log file does not instantly get smaller in size. Rather it gets
> substantially smaller a few hours later. The MDF file is about 5.3 GB and
> the LDF file is about 9 GB.
> Thank you for whatever help you can offer.
> Sincerely,
> Mr. Mixter

DUMP TRANSACTION database WITH NO_LOG

Hello there,
I am trying to learn about MS-SQL Server on my own and am faced with a
problem that requires action quickly, even though I would prefer to take my
time and dig out the answer from all the documentation available.
On the web site that I manage, some log files grow to be as large or larger
than the MDF files themselves, and I am concernced with preserving hard disk
space for obvious reasons. I asked the web hosting company's tech support
department for a way to reduce the size of these log files, and they pointed
me to this suggestion:
DUMP TRANSACTION database WITH NO_LOG
While I have used this command to reduce the log file size successfully, I
am concerned that I am actually truncating data that has not been committed
to the database yet. Am I worrying needlessly? Or am I actually losing data
when I run this command?
I have observed that when I run this query from the SQL Query Analyzer that
the log file does not instantly get smaller in size. Rather it gets
substantially smaller a few hours later. The MDF file is about 5.3 GB and
the LDF file is about 9 GB.
Thank you for whatever help you can offer.
Sincerely,
Mr. Mixter
Mick,
Don't worry. This command will truncate committed transactions from the
transaction log. If you don't have much control over your database in terms
of backups, etc, consider changing the recovery model to simple, this means
that committed transactions are removed from the transaction log, which will
stop it growing.
Once you have changed the recovery model and truncated the log, you will
need to shrink the log file using DBCC SHRINKFILE. Look that up in BOL.
Sounds like your hosting company admins need to go on a SQL Server course.
Regards,
Mark.
"Mick Keily" wrote:

> Hello there,
> I am trying to learn about MS-SQL Server on my own and am faced with a
> problem that requires action quickly, even though I would prefer to take my
> time and dig out the answer from all the documentation available.
> On the web site that I manage, some log files grow to be as large or larger
> than the MDF files themselves, and I am concernced with preserving hard disk
> space for obvious reasons. I asked the web hosting company's tech support
> department for a way to reduce the size of these log files, and they pointed
> me to this suggestion:
> DUMP TRANSACTION database WITH NO_LOG
> While I have used this command to reduce the log file size successfully, I
> am concerned that I am actually truncating data that has not been committed
> to the database yet. Am I worrying needlessly? Or am I actually losing data
> when I run this command?
> I have observed that when I run this query from the SQL Query Analyzer that
> the log file does not instantly get smaller in size. Rather it gets
> substantially smaller a few hours later. The MDF file is about 5.3 GB and
> the LDF file is about 9 GB.
> Thank you for whatever help you can offer.
> Sincerely,
> Mr. Mixter

DUMP TRANSACTION database WITH NO_LOG

Hello there,
I am trying to learn about MS-SQL Server on my own and am faced with a
problem that requires action quickly, even though I would prefer to take my
time and dig out the answer from all the documentation available.
On the web site that I manage, some log files grow to be as large or larger
than the MDF files themselves, and I am concernced with preserving hard disk
space for obvious reasons. I asked the web hosting company's tech support
department for a way to reduce the size of these log files, and they pointed
me to this suggestion:
DUMP TRANSACTION database WITH NO_LOG
While I have used this command to reduce the log file size successfully, I
am concerned that I am actually truncating data that has not been committed
to the database yet. Am I worrying needlessly? Or am I actually losing data
when I run this command?
I have observed that when I run this query from the SQL Query Analyzer that
the log file does not instantly get smaller in size. Rather it gets
substantially smaller a few hours later. The MDF file is about 5.3 GB and
the LDF file is about 9 GB.
Thank you for whatever help you can offer.
Sincerely,
Mr. MixterMick,
Don't worry. This command will truncate committed transactions from the
transaction log. If you don't have much control over your database in terms
of backups, etc, consider changing the recovery model to simple, this means
that committed transactions are removed from the transaction log, which will
stop it growing.
Once you have changed the recovery model and truncated the log, you will
need to shrink the log file using DBCC SHRINKFILE. Look that up in BOL.
Sounds like your hosting company admins need to go on a SQL Server course.
Regards,
Mark.
"Mick Keily" wrote:
> Hello there,
> I am trying to learn about MS-SQL Server on my own and am faced with a
> problem that requires action quickly, even though I would prefer to take my
> time and dig out the answer from all the documentation available.
> On the web site that I manage, some log files grow to be as large or larger
> than the MDF files themselves, and I am concernced with preserving hard disk
> space for obvious reasons. I asked the web hosting company's tech support
> department for a way to reduce the size of these log files, and they pointed
> me to this suggestion:
> DUMP TRANSACTION database WITH NO_LOG
> While I have used this command to reduce the log file size successfully, I
> am concerned that I am actually truncating data that has not been committed
> to the database yet. Am I worrying needlessly? Or am I actually losing data
> when I run this command?
> I have observed that when I run this query from the SQL Query Analyzer that
> the log file does not instantly get smaller in size. Rather it gets
> substantially smaller a few hours later. The MDF file is about 5.3 GB and
> the LDF file is about 9 GB.
> Thank you for whatever help you can offer.
> Sincerely,
> Mr. Mixter