Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

Remote Backup

4 posts in Windows NT Last posting was on 1997-10-31 10:04:34.0Z
David Levine Posted on 1997-10-14 02:19:15.0Z
From: "David Levine" <david_levine@opcenter.net>
Subject: Remote Backup
Date: Mon, 13 Oct 1997 22:19:15 -0400
Lines: 21
Organization: Sony
X-Newsreader: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Message-ID: <BQqyV7D28GA.175@forums.powersoft.com>
Newsgroups: sybase.public.sqlserver.nt
Path: forums-1-dub!forums-master.sybase.com!forums.powersoft.com
Xref: forums-1-dub sybase.public.sqlserver.nt:5479
Article PK: 1081556

I now have a requirement to dump my backup to a remote SQL Server.
Everything is setup correctly, or so it appears. There is no problem
running the remote backup for the transaction logs, the master database or
sybsystemprocs. The backup "freezes" whenever we try to dump the user
database. By "freeze", I mean remains a process on the machine, but it is
in sleep status. The file that is created on the remote machine is tine (2
MB) in comparison to the 1.9GB database. No messages on either server.
Once that process "freezes" we need to down the box in order to make it go
away. If we don't the subsequent tran log dumps are locked on that sleeping
process.

The network both machines are located on is an underutilized 100MB switched
fast ethernet segment.

Any ideas?

Thanks,
David Levine
david_levine@opcenter.net


Reinoud van Leeuwen Posted on 1997-10-31 10:04:34.0Z
Message-ID: <3459AD32.14B5@sybase.com>
Date: Fri, 31 Oct 1997 11:04:34 +0100
From: Reinoud van Leeuwen <reinoud@sybase.com>
Organization: Sybase Inc.
X-Mailer: Mozilla 3.0 (Win95; I)
MIME-Version: 1.0
To: David Levine <david_levine@opcenter.net>
Subject: Re: Remote Backup
References: <BQqyV7D28GA.175@forums.powersoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Newsgroups: sybase.public.sqlserver.nt
Lines: 20
Path: forums-1-dub!forums-master.sybase.com!forums.powersoft.com
Xref: forums-1-dub sybase.public.sqlserver.nt:5442
Article PK: 1081520


David Levine wrote:
>
> I now have a requirement to dump my backup to a remote SQL Server.
> Everything is setup correctly, or so it appears. There is no problem
> running the remote backup for the transaction logs, the master database or
> sybsystemprocs. The backup "freezes" whenever we try to dump the user
> database. By "freeze", I mean remains a process on the machine, but it is

One thing that sometimes seems to help:
- if you backup to something called
"c:\dir_on_remote_server\dumpname.dump" it sometimes helps to create a
LOCAL c:\dir_on_remote_server. I dont know if that solves your problem ,
because when this is the problem, the remote backup usually fails
compltely.
I don't know wheter this is fixed and exactely in which versions it was
(or is) needed.


Mark A. Parsons Posted on 1997-10-23 22:51:12.0Z
Message-ID: <344FD4E0.DF4@compuserve.com>
Date: Thu, 23 Oct 1997 18:51:12 -0400
From: "Mark A. Parsons" <Iron_Horse@compuserve.com>
Reply-To: Iron_Horse@compuserve.com
Organization: Iron Horse, Inc.
X-Mailer: Mozilla 3.01 (Win95; I)
MIME-Version: 1.0
Subject: Re: Remote Backup
References: <BQqyV7D28GA.175@forums.powersoft.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Newsgroups: sybase.public.sqlserver.nt
Lines: 52
Path: forums-1-dub!forums-master.sybase.com!forums.powersoft.com
Xref: forums-1-dub sybase.public.sqlserver.nt:5462
Article PK: 1081540

You didn't give any details on what kind of problem resolution you've
gone through so some of this may sound elementary ....

How soon after you run the 'dump' command does the process hang? Do you
get back the normal messages showing a running count of how much has
been dumped so far? (Anything in the backupserver errorlog to show that
the dump is running? Any errors showing why it might be hung?)

Do you have enough dump space on the target directory(s) to house your
database dump?

You mention that the database is 1.9GB in size ... is that the amount of
space actually in use or the total defined size of the database?

How many stripes are you dumping to? If 1, have you tried 2 or 3?

Have you tried dumping to another remote dataserver and/or file system?

Do you have any other user databases you could test dumping? What about
a development or test dataserver (I'm assuming you're "freezing" dump is
in production??) ?

Has your user database been setup with separate data and log segments?
(master and sybsystemprocs mix their data and log segments ... I'm
wondering in there might be a problem dumping a database that has
separate data and log segments??)

Have you called any of this into Sybase TS?

Sorry ... no solutions ... yet ... need some more info ...

Mark Parsons
Iron Horse, Inc.

David Levine wrote:
>
> I now have a requirement to dump my backup to a remote SQL Server.
> Everything is setup correctly, or so it appears. There is no problem
> running the remote backup for the transaction logs, the master database or
> sybsystemprocs. The backup "freezes" whenever we try to dump the user
> database. By "freeze", I mean remains a process on the machine, but it is
> in sleep status. The file that is created on the remote machine is tine (2
> MB) in comparison to the 1.9GB database. No messages on either server.
> Once that process "freezes" we need to down the box in order to make it go
> away. If we don't the subsequent tran log dumps are locked on that sleeping
> process.


David Levine Posted on 1997-10-24 00:53:30.0Z
From: "David Levine" <david_levine@opcenter.net>
References: <BQqyV7D28GA.175@forums.powersoft.com> <344FD4E0.DF4@compuserve.com>
Subject: Re: Remote Backup
Date: Thu, 23 Oct 1997 20:53:30 -0400
Lines: 113
Organization: Sony
X-Newsreader: Microsoft Outlook Express 4.71.1712.3
X-MimeOLE: Produced By Microsoft MimeOLE V4.71.1712.3
Message-ID: <VEkQn5A48GA.175@forums.powersoft.com>
Newsgroups: sybase.public.sqlserver.nt
Path: forums-1-dub!forums-master.sybase.com!forums.powersoft.com
Xref: forums-1-dub sybase.public.sqlserver.nt:5459
Article PK: 1081538

Thanks for responding. I inserted reponses to your questions.

Mark A. Parsons wrote in message <344FD4E0.DF4@compuserve.com>...
>You didn't give any details on what kind of problem resolution you've
>gone through so some of this may sound elementary ....
>

>How soon after you run the 'dump' command does the process hang? Do you
>get back the normal messages showing a running count of how much has
>been dumped so far? (Anything in the backupserver errorlog to show that
>the dump is running? Any errors showing why it might be hung?)

Hangs within a couple minutes. With just under a 2GB database, the dumped
file size never exceeded 7MB. I didn't get any error messages, but I was
running it as a detached process. After we called Sybase, they asked the
same thing and requested we run it via isql in an interactive session to
capture any messages.


>Do you have enough dump space on the target directory(s) to house your
>database dump?

Yes, there is about 4GB of space on the target drive


>You mention that the database is 1.9GB in size ... is that the amount of
>space actually in use or the total defined size of the database?

The database devices allocated are over 2GB and the dump file, though
growing, was around 1.7GB at the time.


>How many stripes are you dumping to? If 1, have you tried 2 or 3?

I was dumping the database to a file on an NT Server. The drive, via
hardware, is Raid 5.


>Have you tried dumping to another remote dataserver and/or file system?

No, since I don't have the space available on another machine with SQL
Server installed.



>Do you have any other user databases you could test dumping? What about
>a development or test dataserver (I'm assuming you're "freezing" dump is
>in production??) ?

Yes. I didn't think it was a configuration issue since both the master &
sybsystemprocs database (about 40MB in total) dump fine to the remote backup
server. I could try that though.



>Has your user database been setup with separate data and log segments?
>(master and sybsystemprocs mix their data and log segments ... I'm
>wondering in there might be a problem dumping a database that has
>separate data and log segments??)

The database have both data & log on the same segments.


>Have you called any of this into Sybase TS?


Yes. They, of course, requested I upgrade to the latest EBF or release.
When I asked if it would fix the problem, they said they didn't know. I
told them I'm not upgrading. They asked if I would run it via an
interactive isql session, but we temporarily added another drive to the
machine to give us space and I'm in the middle of a national rollout of a
system.

I have another solution which I will try first though. I didn't think you
could dump to a "mapped" drive. I had always received an error message when
I tried. It seems that its a permissions thing since someone from my office
has done it. If it works, this is a good solution for me since I end up
with the same end result.

I'll let you know how it turns out.

Thanks for responding.

David
david_levine@opcenter.net

>
>Sorry ... no solutions ... yet ... need some more info ...
>
>Mark Parsons
>Iron Horse, Inc.
>
>
>David Levine wrote:
>>
>> I now have a requirement to dump my backup to a remote SQL Server.
>> Everything is setup correctly, or so it appears. There is no problem
>> running the remote backup for the transaction logs, the master database
or
>> sybsystemprocs. The backup "freezes" whenever we try to dump the user
>> database. By "freeze", I mean remains a process on the machine, but it
is
>> in sleep status. The file that is created on the remote machine is tine
(2
>> MB) in comparison to the 1.9GB database. No messages on either server.
>> Once that process "freezes" we need to down the box in order to make it
go
>> away. If we don't the subsequent tran log dumps are locked on that
sleeping
>> process.