Should DBA know to check theres no DB connections before performing a data update

[minestrone]

It depends on what is using the DB.

[suityou01]

It depends on what is using the DB.

Why?

[minestrone]

Why?

Cached data in some instances.

[Kanye]

Sorry OP but I'm approaching 10 years as a DBA/developer, mostly direct for Oracle, and have never once had a scenario where people have had to log out for a 'data update'.

Occasionally some DDL or huge table level updates are scheduled for outside of business hours, but even then, leaving the occasional session connected should not be the end of the world.

Sounds like a flaw in the application locking or change processes rather than with the DBA.

[centurian]

Sorry OP but I'm approaching 10 years as a DBA/developer, mostly direct for Oracle, and have never once had a scenario where people have had to log out for a 'data update'.

WHS - same here. Never had to get users to log out for a data update.

Now I have had a few applications where this might have been an issue, so the application / DB schema accomodated this, by being able to pre-load the data gradually, but in an inactive state - and then made active when ready.

Sounds like the application architecture needs a rethink.

[minestrone]

Sounds like the application architecture needs a rethink.

If you are using ORM which mostly everyone does these days in writing java apps ( I would think .NET has eventually got there as well) and using third level caching which you should be then you have to drop the appication or else what you are updating might be written over by the application cache.

It is pretty standard tech and a pretty standard way of using it.

As I said it depends on the use of the DB but it is normal ( necessary )to drop the connections on the architectures I use.

[eek]

If you are using ORM which mostly everyone does these days in writing java apps ( I would think .NET has eventually got there as well) and using third level caching which you should be then you have to drop the appication or else what you are updating might be written over by the application cache.

It is pretty standard tech and a pretty standard way of using it.

As I said it depends on the use of the DB but it is normal ( necessary )to drop the connections on the architectures I use.

Which is why ORM's are more pain then they are worth. The person who retrofitted one at current client co deserves to be shot.

[minestrone]

ORMs are terribly misunderstood by most people that use them, fantastic at delivering clean code quickly written to do page sized data loading but I keep finding people writing batch jobs with it. Battering the shit: out of the DB for minutes on end to do something a stored proc could do in a second.

[aussielong]

If you are using ORM which mostly everyone does these days in writing java apps ( I would think .NET has eventually got there as well) and using third level caching which you should be then you have to drop the appication or else what you are updating might be written over by the application cache.

It is pretty standard tech and a pretty standard way of using it.

As I said it depends on the use of the DB but it is normal ( necessary )to drop the connections on the architectures I use.

Your architectures dont use optimistic locking then? Are you not using versioning on your rows? Which you usually should be in scalable multiuser systems.

The DBA update would incr the version number. The cache would not be able to overwrite that later. You should handle optimistic locking version error in your app-reload the latest version and maybe try again. This is how I've used ORMs such as Hibernate in the past. It's a standard approach.

Bouncing the DB should be an absolute last resort due to needing to refill caches in the middle tier.

[eek]

Your architectures dont use optimistic locking then? Are you not using versioning on your rows? Which you usually should be in scalable multiuser systems.

The DBA update would incr the version number. The cache would not be able to overwrite that later. You should handle optimistic locking version error in your app-reload the latest version and maybe try again. This is how I've used ORMs such as Hibernate in the past. It's a standard approach.

Bouncing the DB should be an absolute last resort due to needing to refill caches in the middle tier.

Blooming heck something from aussielong I can 100% agree with