I have created a maintenance plan and specified a detailed job log. The log
only contains the entries down to the "Details" line and noting after.
This is on a SQL Server 2005 SP1 server.
Any ideas?This is happening to me too. This is all I get in the report text file and
yet the job has run for 4hrs and ends in a failed status.
Microsoft(R) Server Maintenance Utility (Unicode) Version 9.0.2047
Report was generated on "DBSERVER".
Maintenance Plan: Weekly All DB Maintenance Plan
Duration: 00:00:00
Status: Succeeded.
Details:
Showing posts with label contains. Show all posts
Showing posts with label contains. Show all posts
Friday, March 23, 2012
Maintenance Job log incomplete
I have created a maintenance plan and specified a detailed job log. The log
only contains the entries down to the "Details" line and noting after.
This is on a SQL Server 2005 SP1 server.
Any ideas?
This is happening to me too. This is all I get in the report text file and
yet the job has run for 4hrs and ends in a failed status.
Microsoft(R) Server Maintenance Utility (Unicode) Version 9.0.2047
Report was generated on "DBSERVER".
Maintenance Plan: Weekly All DB Maintenance Plan
Duration: 00:00:00
Status: Succeeded.
Details:
only contains the entries down to the "Details" line and noting after.
This is on a SQL Server 2005 SP1 server.
Any ideas?
This is happening to me too. This is all I get in the report text file and
yet the job has run for 4hrs and ends in a failed status.
Microsoft(R) Server Maintenance Utility (Unicode) Version 9.0.2047
Report was generated on "DBSERVER".
Maintenance Plan: Weekly All DB Maintenance Plan
Duration: 00:00:00
Status: Succeeded.
Details:
Monday, March 19, 2012
Maintain History
Hi All
I have a table that contains details regarding branch offices and as these
offices regularly change details such as the branch name and address I need
to always have the current details and also maintain a history of historical
details for each branch office. Initially I was think of having a duplicate
table with a datetime column to store when the last change was made and also
a column that contained the details of who changed the branch office details.
I was going to control this through the application but have identified that
there is any additional vendor application that also change details in this
table and the application can not be modified.
Is the best way to maintain a history of branch office details in this
scenario to create a trigger on the table and populate a duplicate table with
the details of the branch office as they where before being modified or is
there a better way to do this?
Thanks
- DavidHi David
There is a simple auditing example (E) in the Create Trigger topic in books
online. There may be an impact on the system if you implement these on all
your tables, in both the amount of storage used and time taken to make
changes. To reduce the performance degredation it is best to keep the trigger
as simple as you can , if any reconciliation is necessary then you can do
that during a quiet period of possibly offline.
Alternatively you can purchase a log reading program, you may want to log at
LogExplorer from Lumigent www.lumigent.com or LogPI which has been aquired
by Goldengate see www.logpi.com
John
"David" wrote:
> Hi All
> I have a table that contains details regarding branch offices and as these
> offices regularly change details such as the branch name and address I need
> to always have the current details and also maintain a history of historical
> details for each branch office. Initially I was think of having a duplicate
> table with a datetime column to store when the last change was made and also
> a column that contained the details of who changed the branch office details.
> I was going to control this through the application but have identified that
> there is any additional vendor application that also change details in this
> table and the application can not be modified.
> Is the best way to maintain a history of branch office details in this
> scenario to create a trigger on the table and populate a duplicate table with
> the details of the branch office as they where before being modified or is
> there a better way to do this?
> Thanks
> - David
I have a table that contains details regarding branch offices and as these
offices regularly change details such as the branch name and address I need
to always have the current details and also maintain a history of historical
details for each branch office. Initially I was think of having a duplicate
table with a datetime column to store when the last change was made and also
a column that contained the details of who changed the branch office details.
I was going to control this through the application but have identified that
there is any additional vendor application that also change details in this
table and the application can not be modified.
Is the best way to maintain a history of branch office details in this
scenario to create a trigger on the table and populate a duplicate table with
the details of the branch office as they where before being modified or is
there a better way to do this?
Thanks
- DavidHi David
There is a simple auditing example (E) in the Create Trigger topic in books
online. There may be an impact on the system if you implement these on all
your tables, in both the amount of storage used and time taken to make
changes. To reduce the performance degredation it is best to keep the trigger
as simple as you can , if any reconciliation is necessary then you can do
that during a quiet period of possibly offline.
Alternatively you can purchase a log reading program, you may want to log at
LogExplorer from Lumigent www.lumigent.com or LogPI which has been aquired
by Goldengate see www.logpi.com
John
"David" wrote:
> Hi All
> I have a table that contains details regarding branch offices and as these
> offices regularly change details such as the branch name and address I need
> to always have the current details and also maintain a history of historical
> details for each branch office. Initially I was think of having a duplicate
> table with a datetime column to store when the last change was made and also
> a column that contained the details of who changed the branch office details.
> I was going to control this through the application but have identified that
> there is any additional vendor application that also change details in this
> table and the application can not be modified.
> Is the best way to maintain a history of branch office details in this
> scenario to create a trigger on the table and populate a duplicate table with
> the details of the branch office as they where before being modified or is
> there a better way to do this?
> Thanks
> - David
Maintain History
Hi All
I have a table that contains details regarding branch offices and as these
offices regularly change details such as the branch name and address I need
to always have the current details and also maintain a history of historical
details for each branch office. Initially I was think of having a duplicate
table with a datetime column to store when the last change was made and also
a column that contained the details of who changed the branch office details
.
I was going to control this through the application but have identified that
there is any additional vendor application that also change details in this
table and the application can not be modified.
Is the best way to maintain a history of branch office details in this
scenario to create a trigger on the table and populate a duplicate table wit
h
the details of the branch office as they where before being modified or is
there a better way to do this?
Thanks
- DavidHi David
There is a simple auditing example (E) in the Create Trigger topic in books
online. There may be an impact on the system if you implement these on all
your tables, in both the amount of storage used and time taken to make
changes. To reduce the performance degredation it is best to keep the trigge
r
as simple as you can , if any reconciliation is necessary then you can do
that during a quiet period of possibly offline.
Alternatively you can purchase a log reading program, you may want to log at
LogExplorer from Lumigent www.lumigent.com or LogPI which has been aquired
by Goldengate see www.logpi.com
John
"David" wrote:
> Hi All
> I have a table that contains details regarding branch offices and as these
> offices regularly change details such as the branch name and address I nee
d
> to always have the current details and also maintain a history of historic
al
> details for each branch office. Initially I was think of having a duplica
te
> table with a datetime column to store when the last change was made and al
so
> a column that contained the details of who changed the branch office detai
ls.
> I was going to control this through the application but have identified t
hat
> there is any additional vendor application that also change details in thi
s
> table and the application can not be modified.
> Is the best way to maintain a history of branch office details in this
> scenario to create a trigger on the table and populate a duplicate table w
ith
> the details of the branch office as they where before being modified or is
> there a better way to do this?
> Thanks
> - David
I have a table that contains details regarding branch offices and as these
offices regularly change details such as the branch name and address I need
to always have the current details and also maintain a history of historical
details for each branch office. Initially I was think of having a duplicate
table with a datetime column to store when the last change was made and also
a column that contained the details of who changed the branch office details
.
I was going to control this through the application but have identified that
there is any additional vendor application that also change details in this
table and the application can not be modified.
Is the best way to maintain a history of branch office details in this
scenario to create a trigger on the table and populate a duplicate table wit
h
the details of the branch office as they where before being modified or is
there a better way to do this?
Thanks
- DavidHi David
There is a simple auditing example (E) in the Create Trigger topic in books
online. There may be an impact on the system if you implement these on all
your tables, in both the amount of storage used and time taken to make
changes. To reduce the performance degredation it is best to keep the trigge
r
as simple as you can , if any reconciliation is necessary then you can do
that during a quiet period of possibly offline.
Alternatively you can purchase a log reading program, you may want to log at
LogExplorer from Lumigent www.lumigent.com or LogPI which has been aquired
by Goldengate see www.logpi.com
John
"David" wrote:
> Hi All
> I have a table that contains details regarding branch offices and as these
> offices regularly change details such as the branch name and address I nee
d
> to always have the current details and also maintain a history of historic
al
> details for each branch office. Initially I was think of having a duplica
te
> table with a datetime column to store when the last change was made and al
so
> a column that contained the details of who changed the branch office detai
ls.
> I was going to control this through the application but have identified t
hat
> there is any additional vendor application that also change details in thi
s
> table and the application can not be modified.
> Is the best way to maintain a history of branch office details in this
> scenario to create a trigger on the table and populate a duplicate table w
ith
> the details of the branch office as they where before being modified or is
> there a better way to do this?
> Thanks
> - David
Maintain Blank DB Copy
Hi
I have a development database that gets filled with test
data. I would like to maintain a 'blank' copy i.e one
that only contains the data the application needs to run,
that is automatically updated with structural changes,
new SP's etc without any new 'user' data being added to
it.
Can anyone give me any pointers as to the most painless
way of doing this?
Thanks in advance
GrahamI prefer to have the DDL scripts to create the database and then INSERT statements to create the
base stuff, this way you don't have to mess with restore or attach.
Here are some options to generate DDL script, some including data:
You can use SCPTXFER to generate DDL from code as described in:
DTS Does Not Copy Identity, Indexes, Primary Key or Other Constraints (Q220163)
http://www.support.microsoft.com/?id=220163
Generate TSQL scrip with DDL and data:
http://www.rac4sql.net/objectscriptr_main.asp
Generate TSQL script with data:
http://www.sqlscripter.com
Generate TSQL script with data:
http://www.lockwoodtech.com/index.asp?PageId=auto_inserts&TitleID=products
Generate TSQL script with data:
http://www.largosqltools.com/DataInsertScripts.asp
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Graham" <graham@.DONT_SPAM_MEremarkabledesignPLEASE.com> wrote in message
news:0c0f01c3a9e4$680c2590$a401280a@.phx.gbl...
> Hi
> I have a development database that gets filled with test
> data. I would like to maintain a 'blank' copy i.e one
> that only contains the data the application needs to run,
> that is automatically updated with structural changes,
> new SP's etc without any new 'user' data being added to
> it.
> Can anyone give me any pointers as to the most painless
> way of doing this?
> Thanks in advance
> Graham|||Graham wrote:
> Hi
> I have a development database that gets filled with test
> data. I would like to maintain a 'blank' copy i.e one
> that only contains the data the application needs to run,
> that is automatically updated with structural changes,
> new SP's etc without any new 'user' data being added to
> it.
> Can anyone give me any pointers as to the most painless
> way of doing this?
> Thanks in advance
> Graham
Million ways to do this but...
My personal preference would be to create the blank database, dettach
it and make a copy of the dbs data and log files (set them to
readonly). You can then reattach and continue. When you want to go back
to blank you would just detach current db, delete files and copy the
blankcopyones and rename back to origonal names (remove read
attributes) and reattach.
Tibors way is also a very good option.
--
Br,
Mark Broadbent
mcdba , mcse+i
=============
I have a development database that gets filled with test
data. I would like to maintain a 'blank' copy i.e one
that only contains the data the application needs to run,
that is automatically updated with structural changes,
new SP's etc without any new 'user' data being added to
it.
Can anyone give me any pointers as to the most painless
way of doing this?
Thanks in advance
GrahamI prefer to have the DDL scripts to create the database and then INSERT statements to create the
base stuff, this way you don't have to mess with restore or attach.
Here are some options to generate DDL script, some including data:
You can use SCPTXFER to generate DDL from code as described in:
DTS Does Not Copy Identity, Indexes, Primary Key or Other Constraints (Q220163)
http://www.support.microsoft.com/?id=220163
Generate TSQL scrip with DDL and data:
http://www.rac4sql.net/objectscriptr_main.asp
Generate TSQL script with data:
http://www.sqlscripter.com
Generate TSQL script with data:
http://www.lockwoodtech.com/index.asp?PageId=auto_inserts&TitleID=products
Generate TSQL script with data:
http://www.largosqltools.com/DataInsertScripts.asp
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as_ugroup=microsoft.public.sqlserver
"Graham" <graham@.DONT_SPAM_MEremarkabledesignPLEASE.com> wrote in message
news:0c0f01c3a9e4$680c2590$a401280a@.phx.gbl...
> Hi
> I have a development database that gets filled with test
> data. I would like to maintain a 'blank' copy i.e one
> that only contains the data the application needs to run,
> that is automatically updated with structural changes,
> new SP's etc without any new 'user' data being added to
> it.
> Can anyone give me any pointers as to the most painless
> way of doing this?
> Thanks in advance
> Graham|||Graham wrote:
> Hi
> I have a development database that gets filled with test
> data. I would like to maintain a 'blank' copy i.e one
> that only contains the data the application needs to run,
> that is automatically updated with structural changes,
> new SP's etc without any new 'user' data being added to
> it.
> Can anyone give me any pointers as to the most painless
> way of doing this?
> Thanks in advance
> Graham
Million ways to do this but...
My personal preference would be to create the blank database, dettach
it and make a copy of the dbs data and log files (set them to
readonly). You can then reattach and continue. When you want to go back
to blank you would just detach current db, delete files and copy the
blankcopyones and rename back to origonal names (remove read
attributes) and reattach.
Tibors way is also a very good option.
--
Br,
Mark Broadbent
mcdba , mcse+i
=============
Subscribe to:
Posts (Atom)