Sunday, March 11, 2012
Database and log backups not deleting
maintenance plan set to backup databases and log files
and to delete the old ones after 2 days. The backups run
fine and restores have been tested. We have never been
able to get the maintenance plan to automatically delete
the backups after the 2 days as it is supposed to do. We
are running Windows 2000 Advanced Server SP3 with SQL
2000 SP3. It continues to be a problem as we
consistently run out of disk space due to too many
backups stored on our local disk.We had the same problems.
Make sure you do not have RETAINDAYS or EXPIRES in the backup.
One thing I found was that a backup does not run for the same duration each
time,
so a backup that needs to delete older than 2 days sees the "2 day old
backup"
scenario as EXACTLY 24 hours or greater. The 2 days is based on the end
time.
So, if the 2 day old backup ran 15 minutes - 2:00am to 2:15am and
the new backup runs less time 2:00am to 2:13am then it is not 24 hours.
it is 47 hours 58 minutes. Voila NO DELETE. I worked around this by
DELETING Backups more than 36 HOURS old.
Hope this helps.
--
FrankM
You know you are in trouble when
the learning curve turns into a death spiral
"chuck" <ccrofford@.adelphia.net> wrote in message
news:082901c35dad$1a92a790$a501280a@.phx.gbl...
> We have had an issue for a long time. We have the
> maintenance plan set to backup databases and log files
> and to delete the old ones after 2 days. The backups run
> fine and restores have been tested. We have never been
> able to get the maintenance plan to automatically delete
> the backups after the 2 days as it is supposed to do. We
> are running Windows 2000 Advanced Server SP3 with SQL
> 2000 SP3. It continues to be a problem as we
> consistently run out of disk space due to too many
> backups stored on our local disk.|||In addition to Franks wonderful suggestions you may want to read this:
-- Log files don't delete --
http://support.microsoft.com/default.aspx?scid=kb;en-us;Q303292
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
Andrew J. Kelly
SQL Server MVP
"chuck" <ccrofford@.adelphia.net> wrote in message
news:082901c35dad$1a92a790$a501280a@.phx.gbl...
> We have had an issue for a long time. We have the
> maintenance plan set to backup databases and log files
> and to delete the old ones after 2 days. The backups run
> fine and restores have been tested. We have never been
> able to get the maintenance plan to automatically delete
> the backups after the 2 days as it is supposed to do. We
> are running Windows 2000 Advanced Server SP3 with SQL
> 2000 SP3. It continues to be a problem as we
> consistently run out of disk space due to too many
> backups stored on our local disk.
Thursday, March 8, 2012
database access & asp.net
and removing items from an order what is to stop a malicious user changing
the product code in the form and then adding to or removing items to/from
another user's order ?
How do we ensure that the rows the user is editing are rows the user has
permission to edit ?
ThanksTwo words Application Architecture. Seriously you need to implement your
own security model if you want to provide for row level and field level
security.
Secondly if you are developing a web app the user should not have rights to
your database. The connection should be handled by an "Application User"
that in turn is managed by a Connection Pool.
Dan
"Murphy" <murphy@.murphy.com> wrote in message
news:%23wb%23$V%23oDHA.684@.TK2MSFTNGP09.phx.gbl...
> If a user has permissions to add and delete rows from a table i.e. adding
> and removing items from an order what is to stop a malicious user changing
> the product code in the form and then adding to or removing items to/from
> another user's order ?
> How do we ensure that the rows the user is editing are rows the user has
> permission to edit ?
> Thanks
>|||Are there any security models that have been tried and proven, don't want to
reinvent the wheel ?
Thanks
"solex" <solex@.nowhere.com> wrote in message
news:%23oTqDa%23oDHA.708@.TK2MSFTNGP10.phx.gbl...
> Two words Application Architecture. Seriously you need to implement your
> own security model if you want to provide for row level and field level
> security.
> Secondly if you are developing a web app the user should not have rights
to
> your database. The connection should be handled by an "Application User"
> that in turn is managed by a Connection Pool.
> Dan
> "Murphy" <murphy@.murphy.com> wrote in message
> news:%23wb%23$V%23oDHA.684@.TK2MSFTNGP09.phx.gbl...
> > If a user has permissions to add and delete rows from a table i.e.
adding
> > and removing items from an order what is to stop a malicious user
changing
> > the product code in the form and then adding to or removing items
to/from
> > another user's order ?
> >
> > How do we ensure that the rows the user is editing are rows the user has
> > permission to edit ?
> >
> > Thanks
> >
> >
>|||There are many security models but none that I have seen that will implement
row level security in your database. It has been my experience that if you
want granular security you will need to implement it on your own.
Dan
"Murphy" <murphy@.murphy.com> wrote in message
news:eosI6c%23oDHA.2652@.TK2MSFTNGP09.phx.gbl...
> Are there any security models that have been tried and proven, don't want
to
> reinvent the wheel ?
> Thanks
> "solex" <solex@.nowhere.com> wrote in message
> news:%23oTqDa%23oDHA.708@.TK2MSFTNGP10.phx.gbl...
> > Two words Application Architecture. Seriously you need to implement
your
> > own security model if you want to provide for row level and field level
> > security.
> >
> > Secondly if you are developing a web app the user should not have rights
> to
> > your database. The connection should be handled by an "Application
User"
> > that in turn is managed by a Connection Pool.
> >
> > Dan
> >
> > "Murphy" <murphy@.murphy.com> wrote in message
> > news:%23wb%23$V%23oDHA.684@.TK2MSFTNGP09.phx.gbl...
> > > If a user has permissions to add and delete rows from a table i.e.
> adding
> > > and removing items from an order what is to stop a malicious user
> changing
> > > the product code in the form and then adding to or removing items
> to/from
> > > another user's order ?
> > >
> > > How do we ensure that the rows the user is editing are rows the user
has
> > > permission to edit ?
> > >
> > > Thanks
> > >
> > >
> >
> >
>
Wednesday, March 7, 2012
dataadapter.Update() OR ExecuteNonQuery()
Hi
If you are only intending on working with one row at a time (presumably using the primary key for the data you are working with) then it would be more efficient to use the ExecuteNonQuery method of the command object. The Update method of the DataAdapter object will attempt to update all changes to rows within a DataSet/DataTable.
HTH
|||You said: "Update method of the DataAdapter object will attempt to update ALL changes to rows within a DataSet/DataTable", even if I write: dataadapter.UpdateCommand="update TableName set field1 with ? for .... "?|||Hi
If you specify the DataAdapter's UpdateCommand to update only one row then that will be similar to the ExecuteNonQuery method. I assumed by DataAdapter.Update that you were going to pass it a DataSet/DataTable so that all changed rows would be persisted to the Database.
To be honest though, the DataAdapter's UpdateCommand is a command object so therefore, to update a row you would have configured a DataAdapter and then configured a Command object when you could simply have configured a Command object only. However, if you already had the DataAdapter available to you then this wouldn't be so much of an issue. It really depends on the type of aproach you are taking, especially when considering a Data Access Layer.
HTH
|||Yes, you are right. With dataadapter the work is double. Thank you.Sunday, February 19, 2012
Data type in audit record
I want my application to audit any data changes (update, insert,
delete) made by the users. Rather than have an audit table mirroring
each user table, I'd prefer to have a generic structure which can log
anything. This is what I've come up with:
TABLE: audit_record
*audit_record_id (uniqueidentifier, auto-assign, PK) - unique
idenfiier of the audit record
table_name (varchar) - name of the table where the action (insert/
update/delete) was made
pk_value (varchar) - primary key of the changed record. If the PK
itself has changed, this will store the old value.
user_id (varchar) - user who changed the record
date (datetime) - date/time at which the change was made
action (int) - 0, 1 or 2 (insert, update, delete)
TABLE: audit_column
*audit_record_id (uniqueidentifier, composite PK) - FK to
cdb_audit_record table
*column_name (varchar, composite PK) - name of the column with changed
data
new_value (text?) - value after the change
So every column which changes has its new value logged individually in
the audit_column table. However, I'm not sure what data type the
new_value column should have. The obvious answer (to me) is text, as
that can handle any necessary data type with the appropriate
conversion (we don't store any binary data). However, this table is
going to grow to millions of records and I'm not sure what the
performance implications of a text column will be, particularly given
that the actual data stored in it will almost always be tiny.
Any thoughts/recommendations/criticism would be greatly appreciated.
Thanks
AlexSorry for replying to myself - I forgot to state that I'm using SQL
Server 2000 standard edition.|||WombatDeath@.gmail.com wrote:
Quote:
Originally Posted by
I want my application to audit any data changes (update, insert,
delete) made by the users. Rather than have an audit table mirroring
each user table, I'd prefer to have a generic structure which can log
anything. This is what I've come up with:
>
TABLE: audit_record
*audit_record_id (uniqueidentifier, auto-assign, PK) - unique
idenfiier of the audit record
table_name (varchar) - name of the table where the action (insert/
update/delete) was made
pk_value (varchar) - primary key of the changed record. If the PK
itself has changed, this will store the old value.
user_id (varchar) - user who changed the record
date (datetime) - date/time at which the change was made
action (int) - 0, 1 or 2 (insert, update, delete)
>
TABLE: audit_column
*audit_record_id (uniqueidentifier, composite PK) - FK to
cdb_audit_record table
*column_name (varchar, composite PK) - name of the column with changed
data
new_value (text?) - value after the change
>
So every column which changes has its new value logged individually in
the audit_column table. However, I'm not sure what data type the
new_value column should have. The obvious answer (to me) is text, as
that can handle any necessary data type with the appropriate
conversion (we don't store any binary data). However, this table is
going to grow to millions of records and I'm not sure what the
performance implications of a text column will be, particularly given
that the actual data stored in it will almost always be tiny.
>
Any thoughts/recommendations/criticism would be greatly appreciated.
Do you actually have anything (or any reasonable prospect of having
anything in future) for which NVARCHAR(4000) wouldn't be good enough?
Whatever you do, I strongly recommend keeping tabs on how quickly it
grows, showing that trend information to the client, and (1) narrow it
down to the tables that really need an audit trail and/or (2) come up
with a sane archive-and-purge schedule.|||On Mar 30, 3:42 pm, Ed Murphy <emurph...@.socal.rr.comwrote:
Quote:
Originally Posted by
WombatDe...@.gmail.com wrote:
Quote:
Originally Posted by
I want my application to audit any data changes (update, insert,
delete) made by the users. Rather than have an audit table mirroring
each user table, I'd prefer to have a generic structure which can log
anything. This is what I've come up with:
>
Quote:
Originally Posted by
TABLE: audit_record
*audit_record_id (uniqueidentifier, auto-assign, PK) - unique
idenfiier of the audit record
table_name (varchar) - name of the table where the action (insert/
update/delete) was made
pk_value (varchar) - primary key of the changed record. If the PK
itself has changed, this will store the old value.
user_id (varchar) - user who changed the record
date (datetime) - date/time at which the change was made
action (int) - 0, 1 or 2 (insert, update, delete)
>
Quote:
Originally Posted by
TABLE: audit_column
*audit_record_id (uniqueidentifier, composite PK) - FK to
cdb_audit_record table
*column_name (varchar, composite PK) - name of the column with changed
data
new_value (text?) - value after the change
>
Quote:
Originally Posted by
So every column which changes has its new value logged individually in
the audit_column table. However, I'm not sure what data type the
new_value column should have. The obvious answer (to me) is text, as
that can handle any necessary data type with the appropriate
conversion (we don't store any binary data). However, this table is
going to grow to millions of records and I'm not sure what the
performance implications of a text column will be, particularly given
that the actual data stored in it will almost always be tiny.
>
Quote:
Originally Posted by
Any thoughts/recommendations/criticism would be greatly appreciated.
>
Do you actually have anything (or any reasonable prospect of having
anything in future) for which NVARCHAR(4000) wouldn't be good enough?
>
Whatever you do, I strongly recommend keeping tabs on how quickly it
grows, showing that trend information to the client, and (1) narrow it
down to the tables that really need an audit trail and/or (2) come up
with a sane archive-and-purge schedule.
Yeah, unfortunately we do have several tables with a column of type
text. These generally don't hold anything close to 4000 chars but
there's nothing actually preventing them from doing so. But...if
there's no tidier option I think I may just truncate to 4000 and be
done with it. We're not auditing to fulfil legal obligations or
anything nasty like that so I don't think it will be a problem.
Your point about maintenance is well taken. I've specified that the
application's auditing must be configurable on an entity-by-entity
basis, and every so often we'll archive away any old data for fast-
changing entities.
Thanks very much for your input!|||(WombatDeath@.gmail.com) writes:
Quote:
Originally Posted by
I want my application to audit any data changes (update, insert,
delete) made by the users. Rather than have an audit table mirroring
each user table, I'd prefer to have a generic structure which can log
anything. This is what I've come up with:
>
TABLE: audit_record
*audit_record_id (uniqueidentifier, auto-assign, PK) - unique
idenfiier of the audit record
table_name (varchar) - name of the table where the action (insert/
update/delete) was made
pk_value (varchar) - primary key of the changed record. If the PK
itself has changed, this will store the old value.
user_id (varchar) - user who changed the record
date (datetime) - date/time at which the change was made
action (int) - 0, 1 or 2 (insert, update, delete)
>
TABLE: audit_column
*audit_record_id (uniqueidentifier, composite PK) - FK to
cdb_audit_record table
*column_name (varchar, composite PK) - name of the column with changed
data
new_value (text?) - value after the change
>
So every column which changes has its new value logged individually in
the audit_column table. However, I'm not sure what data type the
new_value column should have. The obvious answer (to me) is text, as
that can handle any necessary data type with the appropriate
conversion (we don't store any binary data). However, this table is
going to grow to millions of records and I'm not sure what the
performance implications of a text column will be, particularly given
that the actual data stored in it will almost always be tiny.
That is not going to be fun in SQL 2000. In SQL 2005 you could build a
generic audit solution on the xml data type.
I would recommend that you research the market for audit products. I
know for instance that ApexSQL has a something they call SQLAudit
if memory serves.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||>I want my application to audit any data changes (update, insert, delete) made by the users. Rather than have an audit table mirroring each user table, I'd prefer to have a generic structure which can log anything. <<
Any chance you might post DDL instead of your personal pseudo-code?
And I hope you know that auto-numbering is not a relational key.
Finally, Google "EAV design flaw" for tens of thousands of words on
why this approach stinks. There is no such magical shape shifting
table in RDBMS. Data Versus metadata, etc.? Freshman database
course, 3rd week of the quarter?
While you might like this kludge your accountants and auditors will
not. NEVER keep audit trails on the same database or even the same
hardware as the database.
Quote:
Originally Posted by
Quote:
Originally Posted by
>Any thoughts/recommendations/criticism would be greatly appreciated. <<
Look at third party tools that follow the law and get a basic dat
modeling book.