|
Home > Archive > SQL Anywhere database > June 2005 > Killing Users to gain exclusive locks
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Killing Users to gain exclusive locks
|
|
|
| We want to upgrade our clients' databases. We have a series
of .sql scripts that do the job. What we are running into
are users that have jumped into the database via our
front-end apps and locked down the schema targeted for
upgrade during the upgrade process. I know the best answer
is to bring down the database and do this offline, but we
run many databases off of one database server, each database
belonging to different groups of clients. Not all of the
databases running on a server need to be upgraded. If we
bring down the database server, all groups of clients
experience down time...I know this is not the best setup,
but one that we are stuck with now. Is there anyway to run
a kill command just prior to running a schema update script
that would guarentee an exclusive lock for our processes to
do their job? And, we are running SqlAnywhere version 5.5.
Appreciate any help that can be provided.
Thanks,
Randy Kight
Richmond, VA.
| |
| Paul Horan[TeamSybase] 2005-06-21, 1:23 pm |
| <JRK> wrote in message news:42b8440d.7796.1681692777@sybase.com...
> We want to upgrade our clients' databases. We have a series
> of .sql scripts that do the job. What we are running into
> are users that have jumped into the database via our
> front-end apps and locked down the schema targeted for
> upgrade during the upgrade process. I know the best answer
> is to bring down the database and do this offline, but we
> run many databases off of one database server, each database
> belonging to different groups of clients. Not all of the
> databases running on a server need to be upgraded. If we
> bring down the database server, all groups of clients
> experience down time...I know this is not the best setup,
> but one that we are stuck with now. Is there anyway to run
> a kill command just prior to running a schema update script
> that would guarentee an exclusive lock for our processes to
> do their job? And, we are running SqlAnywhere version 5.5.
> Appreciate any help that can be provided.
>
> Thanks,
> Randy Kight
> Richmond, VA.
You can stop (and restart) individual databases without bringing down the entire server...
--
Paul Horan[TeamSybase]
| |
| Jeff Albion \(iAnywhere Solutions\) 2005-06-21, 8:23 pm |
| To be more explicit, check out dbstop -d:
dbstop -d -c " uid=dba;pwd=sql;eng=
myengine;dbn=mydatab
ase;"
--
Jeff Albion
Product Support Analyst
iAnywhere Solutions
"Paul Horan[TeamSybase]" < paulhATvcisolutionsD
OTcom> wrote in message
news:42b846ae@forums
-2-dub...
> <JRK> wrote in message news:42b8440d.7796.1681692777@sybase.com...
>
> You can stop (and restart) individual databases without bringing down the
entire server...
>
> --
> Paul Horan[TeamSybase]
>
>
| |
|
| Thanks for the information. I managed to kill my database
server, but cannot seem to kill a database running on my
database server. I tried -d but got invalid param, and I
don't see this listed as possible parameters. Is this only
useful for stopping a database server and or database
engine, but not useful in stopping an individual database
running on a database server?
> To be more explicit, check out dbstop -d:
>
> dbstop -d -c " uid=dba;pwd=sql;eng=
myengine;dbn=mydatab
ase
> ;"
>
> --
> Jeff Albion
> Product Support Analyst
> iAnywhere Solutions
>
> "Paul Horan[TeamSybase]" < paulhATvcisolutionsD
OTcom> wrote
> in message news:42b846ae@forums
-2-dub...
> for upgrade during the upgrade process. I know the best
> do their job? And, we are running SqlAnywhere version
> bringing down the entire server...
>
>
| |
| Mark Culp 2005-06-21, 8:23 pm |
| Hmmm, did you mention which version of ASA you were using?
My (latest & greatest debug build of) 9.0.2 "dbstop -h" reports:
Adaptive Server Anywhere Stop Engine Utility Version 9.0.2.3140 Debug
Usage: dbstop [options] [name]
@<data> expands <data> from environment variable <data> or file <data>
Options (use specified case, as shown):
-c "keyword=value;..."
supply database connection parameters
-d stop only the specified database
-o <file> log output messages to file
-q do not print messages
-x if there are connections, don't stop
-y if there are connections, don't prompt, stop anyway
I checked, and 7.0.4 and 8.0.3 dbstop reports the same thing.
--
Mark Culp
SQLAnywhere Research and Development
-------------------------------------------------------------------------
** Whitepapers, TechDocs, bug fixes are all available through the **
** iAnywhere Developer Community at http://www.ianywhere.com/developer **
-------------------------------------------------------------------------
* <<<<< Please always include the ASA version and build number >>>>> *
* <<<<< _and_ the operating system version that you are using >>>>> *
-------------------------------------------------------------------------
JRK wrote:[color=darkred
]
>
> Thanks for the information. I managed to kill my database
> server, but cannot seem to kill a database running on my
> database server. I tried -d but got invalid param, and I
> don't see this listed as possible parameters. Is this only
> useful for stopping a database server and or database
> engine, but not useful in stopping an individual database
> running on a database server?
>
| |
| Paul Horan[TeamSybase] 2005-06-22, 3:23 am |
| "Mark Culp" < reply_to_newsgroups_
only_please_nospam_m
ark.culp@iAnywhere.com> wrote in message
news:42B8C3CC.16DD542@iAnywhere.com...
> Hmmm, did you mention which version of ASA you were using?
<snip>
>
> I checked, and 7.0.4 and 8.0.3 dbstop reports the same thing.
> --
> Mark Culp
> SQLAnywhere Research and Development
From the original posting:
"And, we are running SqlAnywhere version 5.5. "
--
Paul Horan[TeamSybase]
| |
| Jeff Albion \(iAnywhere Solutions\) 2005-06-22, 11:23 am |
| I, like Mark, missed that highly important detail. Sorry about that. :)
From the ASA 5.5 Docs:
SQL Anywhere User's Guide
- PART 6. SQL Anywhere Reference
- CHAPTER 43. Watcom-SQL Statements
- STOP DATABASE statement
Function
To stop a database on the specified database engine
Syntax
STOP DATABASE database-name
.... [ ON engine-name ]
.... [ UNCONDITIONALLY ]
Usage
ISQL
Permissions
None
Side effects
None
Description
The STOP DATABASE statement stops a specified database on a specified
database engine. If engine-name is not specified, all running engines will
be searched for a database of the specified name.
If the UNCONDITIONALLY keyword is supplied, the database will be stopped
even if there are connections to the database. If UNCONDITIONALLY is not
specified, the database will not be stopped if there are connections to it.
--
Jeff Albion
Product Support Analyst
iAnywhere Solutions
"Paul Horan[TeamSybase]" < paulhATvcisolutionsD
OTcom> wrote in message
news:42b8d1aa$1@foru
ms-1-dub...
> "Mark Culp"
< reply_to_newsgroups_
only_please_nospam_m
ark.culp@iAnywhere.com> wrote in
message
> news:42B8C3CC.16DD542@iAnywhere.com...
> <snip>
>
>
>
> From the original posting:
> "And, we are running SqlAnywhere version 5.5. "
>
> --
> Paul Horan[TeamSybase]
>
>
| |
| Jeff Albion \(iAnywhere Solutions\) 2005-06-22, 11:23 am |
| In SA 5.5, the dbstop command was indeed limited to just stopping the
database engine. See my other post for the SQL command (STOP DATABASE) on
how to do this.
--
Jeff Albion
Product Support Analyst
iAnywhere Solutions
<JRK> wrote in message news:42b87fcd.79b3.1681692777@sybase.com...[color=darkred]
> Thanks for the information. I managed to kill my database
> server, but cannot seem to kill a database running on my
> database server. I tried -d but got invalid param, and I
> don't see this listed as possible parameters. Is this only
> useful for stopping a database server and or database
> engine, but not useful in stopping an individual database
> running on a database server?
>
|
|
|
|
|