Showing posts with label trn. Show all posts
Showing posts with label trn. Show all posts

Thursday, March 22, 2012

DB updates when limited to bak/trn files only

Hi,
I couldn't make a clear title without writing 2 lines.

My problem (I tried to find out through the archives):
this scenario will be used for several DBs on severals servers.

The remotes servers are not mine, I have only access to the backups files, I have no rights to setup a replication relationship.

I'm using a repository server with SQL 2005, and daily, I need to get the latest Full backup from an SQL2000 server, copy it to the repository server, restore it then delete the .bak file.
This is possible by using many different scripts (like .vbs to copy and rename the latest Full backups) then I use SQL job for daily restore.
Process is too long and the time estimated to start next task (and the backup keep growing).

Is there a way to do everything via SQL2005 script (job)?

Initially, the problem is that I have to do this with the Full backups every days (around 5 Dbs 8 Go in average). So if I can use the latest transaction log files (that would eliminate my first question).
The best way is to use log shipping as well but sql2005 is needed on both sides.

Hope I'm clear.

Thanks for any help!Do you need the databases in read only mode, or fully recovered?

It would be difficult to use the tran log backups, because you could never recover the database.

However, saying that, I wonder if you could keep the receiving database in an unrecovered Read-Only mode, and transactionally publish that database to a third database that would be recovered?


Source Receiving Recovered
Server Full Backup Server DB Server
[----] ------> [----] [----]
[----] Tran Log backups [----] Transactional [----]
[----] ------> [----] Replication [----]
[----] [----] ------> [----]
[----] [----] [----]|||Database in read only mode should be enough as they are used for extraction.
The best and simpler solution again is having the rights on the remotes server but I need to do with it.

So as I won't be able to restore the DB with Trn log only, I still need to copy the Full Bak. I'm fine with that as having the full from 12 h ago is fine.
I guess the intermediary server solution in not needed for that. I know this is a widely used solution but maybe not for what I need (until SQL 2005 migration on remotes servers).

So now, saying I'll only use the .bak, is here a way I can automate from my local server the copy and restore?

Backups are done on same Remote servers, then picked up from there.

Thanks|||So now, saying I'll only use the .bak, is here a way I can automate from my local server the copy and restore?


Since I don't know all the info regarding your provider as regards backup retention period, etc ... here is an overview:

1. Download robocopy - it's free and very good - will auto-restart a file copy if interrupted

2. create a sql script that will be executed by sqlcmd (command line interface) - script builds the filename to download (assumes provider is building filenames including date of backup in filename) and uses robocopy to perform the copy to your local storage. Also have that script create a small file called "CopyComplete.txt" after robocopy successfully finishes (you could copy it from another locatiopn"

3. Create a scheduled job that checks periodically for the "CopyComplete.txt" file. When it finds it, it deletes it and then does the database restore using the replace option.

This is one method ... there are many variations of this ... you chose one and debug it until it works, then use that as a template for all your databases.|||Bkp retention is 2 days (2 full and 6 trn) (so need to grag the last ones, always same time)

I'll try Robocopy with your steps then and will let u know how i is.

thanks again

Saturday, February 25, 2012

DB Maintenance Plan not working properly

In my maintenance plan, i have specified that it should delete bak files
older than 3 days and trn files also older than 3 days. It is surprising
doing that for trn files but the bak are not being deleted. I have 10 small
databases and one large database. It is accumulating the bak files longer
than 3 days while its doing the trn properly. What could cause this to happen
as it is filling up my hardisk. Due to this my large database cannot get
backed up as its saying no hard disk space. Please let me know where the
problem is. thanks in advance.
Below KB might help:
http://support.microsoft.com/default...&Product=sql2k
Also, check out below great troubleshooting suggestions from Bill H at MS:
-- Log files don't delete --
This is likely to be either a permissions problem or a sharing violation
problem. The maintenance plan is run as a job, and jobs are run by the
SQLServerAgent service.
Permissions:
1. Determine the startup account for the SQLServerAgent service
(Start|Programs|Administrative tools|Services|SQLServerAgent|Startup). This
account is the security context for jobs, and thus the maintenance plan.
2. If SQLServerAgent is started using LocalSystem (as opposed to a domain
account) then skip step 3.
3. On that box, log onto NT as that account. Using Explorer, attempt to
delete an expired backup. If that succeeds then go to Sharing Violation
section.
4. Log onto NT with an account that is an administrator and use Explorer to
look at the Properties|Security of the folder (where the backups reside)
and ensure the SQLServerAgent startup account has Full Control. If the
SQLServerAgent startup account is LocalSystem, then the account to consider
is SYSTEM.
5. In NT, if an account is a member of an NT group, and if that group has
Access is Denied, then that account will have Access is Denied, even if
that account is also a member of the Administrators group. Thus you may
need to check group permissions (if the Startup Account is a member of a
group).
6. Keep in mind that permissions (by default) are inherited from a parent
folder. Thus, if the backups are stored in C:\bak, and if someone had
denied permission to the SQLServerAgent startup account for C:\, then
C:\bak will inherit access is denied.
Sharing violation:
This is likely to be rooted in a timing issue, with the most likely cause
being another scheduled process (such as NT Backup or Anti-Virus software)
having the backup file open at the time when the SQLServerAgent (i.e., the
maintenance plan job) tried to delete it.
1. Download filemon and handle from www.sysinternals.com.
2. I am not sure whether filemon can be scheduled, or you might be able to
use NT scheduling services to start filemon just before the maintenance
plan job is started, but the filemon log can become very large, so it would
be best to start it some short time before the maintenance plan starts.
3. Inspect the filemon log for another process that has that backup file
open (if your lucky enough to have started filemon before this other
process grabs the backup folder), and inspect the log for the results when
the SQLServerAgent agent attempts to open that same file.
4. Schedule the job or that other process to do their work at different
times.
5. You can use the handle utility if you are around at the time when the
job is scheduled to run.
If the backup files are going to a \\share or a mapped drive (as opposed to
local drive), then you will need to modify the above (with respect to where
the tests and utilities are run).
Finally, inspection of the maintenance plan's history report might be
useful.
Thanks,
Bill Hollinshead
Microsoft, SQL Server
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"zj" <zj@.discussions.microsoft.com> wrote in message
news:BF147E4E-EEA3-49CD-83BB-B533FC772F49@.microsoft.com...
> In my maintenance plan, i have specified that it should delete bak files
> older than 3 days and trn files also older than 3 days. It is surprising
> doing that for trn files but the bak are not being deleted. I have 10 small
> databases and one large database. It is accumulating the bak files longer
> than 3 days while its doing the trn properly. What could cause this to happen
> as it is filling up my hardisk. Due to this my large database cannot get
> backed up as its saying no hard disk space. Please let me know where the
> problem is. thanks in advance.

DB Maintenance Plan not working properly

In my maintenance plan, i have specified that it should delete bak files
older than 3 days and trn files also older than 3 days. It is surprising
doing that for trn files but the bak are not being deleted. I have 10 small
databases and one large database. It is accumulating the bak files longer
than 3 days while its doing the trn properly. What could cause this to happen
as it is filling up my hardisk. Due to this my large database cannot get
backed up as its saying no hard disk space. Please let me know where the
problem is. thanks in advance.Below KB might help:
http://support.microsoft.com/default.aspx?scid=kb;en-us;303292&Product=sql2k
Also, check out below great troubleshooting suggestions from Bill H at MS:
-- Log files don't delete --
This is likely to be either a permissions problem or a sharing violation
problem. The maintenance plan is run as a job, and jobs are run by the
SQLServerAgent service.
Permissions:
1. Determine the startup account for the SQLServerAgent service
(Start|Programs|Administrative tools|Services|SQLServerAgent|Startup). This
account is the security context for jobs, and thus the maintenance plan.
2. If SQLServerAgent is started using LocalSystem (as opposed to a domain
account) then skip step 3.
3. On that box, log onto NT as that account. Using Explorer, attempt to
delete an expired backup. If that succeeds then go to Sharing Violation
section.
4. Log onto NT with an account that is an administrator and use Explorer to
look at the Properties|Security of the folder (where the backups reside)
and ensure the SQLServerAgent startup account has Full Control. If the
SQLServerAgent startup account is LocalSystem, then the account to consider
is SYSTEM.
5. In NT, if an account is a member of an NT group, and if that group has
Access is Denied, then that account will have Access is Denied, even if
that account is also a member of the Administrators group. Thus you may
need to check group permissions (if the Startup Account is a member of a
group).
6. Keep in mind that permissions (by default) are inherited from a parent
folder. Thus, if the backups are stored in C:\bak, and if someone had
denied permission to the SQLServerAgent startup account for C:\, then
C:\bak will inherit access is denied.
Sharing violation:
This is likely to be rooted in a timing issue, with the most likely cause
being another scheduled process (such as NT Backup or Anti-Virus software)
having the backup file open at the time when the SQLServerAgent (i.e., the
maintenance plan job) tried to delete it.
1. Download filemon and handle from www.sysinternals.com.
2. I am not sure whether filemon can be scheduled, or you might be able to
use NT scheduling services to start filemon just before the maintenance
plan job is started, but the filemon log can become very large, so it would
be best to start it some short time before the maintenance plan starts.
3. Inspect the filemon log for another process that has that backup file
open (if your lucky enough to have started filemon before this other
process grabs the backup folder), and inspect the log for the results when
the SQLServerAgent agent attempts to open that same file.
4. Schedule the job or that other process to do their work at different
times.
5. You can use the handle utility if you are around at the time when the
job is scheduled to run.
If the backup files are going to a \\share or a mapped drive (as opposed to
local drive), then you will need to modify the above (with respect to where
the tests and utilities are run).
Finally, inspection of the maintenance plan's history report might be
useful.
Thanks,
Bill Hollinshead
Microsoft, SQL Server
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"zj" <zj@.discussions.microsoft.com> wrote in message
news:BF147E4E-EEA3-49CD-83BB-B533FC772F49@.microsoft.com...
> In my maintenance plan, i have specified that it should delete bak files
> older than 3 days and trn files also older than 3 days. It is surprising
> doing that for trn files but the bak are not being deleted. I have 10 small
> databases and one large database. It is accumulating the bak files longer
> than 3 days while its doing the trn properly. What could cause this to happen
> as it is filling up my hardisk. Due to this my large database cannot get
> backed up as its saying no hard disk space. Please let me know where the
> problem is. thanks in advance.

DB Maintenance Plan not working properly

In my maintenance plan, i have specified that it should delete bak files
older than 3 days and trn files also older than 3 days. It is surprising
doing that for trn files but the bak are not being deleted. I have 10 small
databases and one large database. It is accumulating the bak files longer
than 3 days while its doing the trn properly. What could cause this to happe
n
as it is filling up my hardisk. Due to this my large database cannot get
backed up as its saying no hard disk space. Please let me know where the
problem is. thanks in advance.Below KB might help:
http://support.microsoft.com/defaul...2&Product=sql2k
Also, check out below great troubleshooting suggestions from Bill H at MS:
-- Log files don't delete --
This is likely to be either a permissions problem or a sharing violation
problem. The maintenance plan is run as a job, and jobs are run by the
SQLServerAgent service.
Permissions:
1. Determine the startup account for the SQLServerAgent service
(Start|Programs|Administrative tools|Services|SQLServerAgent|Startup). This
account is the security context for jobs, and thus the maintenance plan.
2. If SQLServerAgent is started using LocalSystem (as opposed to a domain
account) then skip step 3.
3. On that box, log onto NT as that account. Using Explorer, attempt to
delete an expired backup. If that succeeds then go to Sharing Violation
section.
4. Log onto NT with an account that is an administrator and use Explorer to
look at the Properties|Security of the folder (where the backups reside)
and ensure the SQLServerAgent startup account has Full Control. If the
SQLServerAgent startup account is LocalSystem, then the account to consider
is SYSTEM.
5. In NT, if an account is a member of an NT group, and if that group has
Access is Denied, then that account will have Access is Denied, even if
that account is also a member of the Administrators group. Thus you may
need to check group permissions (if the Startup Account is a member of a
group).
6. Keep in mind that permissions (by default) are inherited from a parent
folder. Thus, if the backups are stored in C:\bak, and if someone had
denied permission to the SQLServerAgent startup account for C:\, then
C:\bak will inherit access is denied.
Sharing violation:
This is likely to be rooted in a timing issue, with the most likely cause
being another scheduled process (such as NT Backup or Anti-Virus software)
having the backup file open at the time when the SQLServerAgent (i.e., the
maintenance plan job) tried to delete it.
1. Download filemon and handle from www.sysinternals.com.
2. I am not sure whether filemon can be scheduled, or you might be able to
use NT scheduling services to start filemon just before the maintenance
plan job is started, but the filemon log can become very large, so it would
be best to start it some short time before the maintenance plan starts.
3. Inspect the filemon log for another process that has that backup file
open (if your lucky enough to have started filemon before this other
process grabs the backup folder), and inspect the log for the results when
the SQLServerAgent agent attempts to open that same file.
4. Schedule the job or that other process to do their work at different
times.
5. You can use the handle utility if you are around at the time when the
job is scheduled to run.
If the backup files are going to a \\share or a mapped drive (as opposed to
local drive), then you will need to modify the above (with respect to where
the tests and utilities are run).
Finally, inspection of the maintenance plan's history report might be
useful.
Thanks,
Bill Hollinshead
Microsoft, SQL Server
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"zj" <zj@.discussions.microsoft.com> wrote in message
news:BF147E4E-EEA3-49CD-83BB-B533FC772F49@.microsoft.com...
> In my maintenance plan, i have specified that it should delete bak files
> older than 3 days and trn files also older than 3 days. It is surprising
> doing that for trn files but the bak are not being deleted. I have 10 smal
l
> databases and one large database. It is accumulating the bak files longer
> than 3 days while its doing the trn properly. What could cause this to hap
pen
> as it is filling up my hardisk. Due to this my large database cannot get
> backed up as its saying no hard disk space. Please let me know where the
> problem is. thanks in advance.