You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have excellent possibility to backup database from client machine with the help of Services API. But there are problems, when we try to restore database in the same way.
First: we can't close all the connections to the database from client machine if other client machines have active transactions. Of course we can shutdown database and other client machines can't open new transactions, but: a) if some clients opened long read transaction and do nothing, the transaction may be endless and b) we can't see from our client machine if all the connections closed anyway but receiving exception on trying moving or renaming original database file.
Second: We can't rename or move current database file (because we haven't access to the server file system from the client machine by the security reasons). We only can restore database from one of the backup files over current database. It's not safety.
Third: We can't see list of previous backup files to select one of them. Yes, we can make log on the client machine or shared folder and append one name per backup.
So:
- It will be usable to add to the Services API function to close all connection because of SYSDBA request with sending notifying message to clients. It may be usable to add the same functionality to the GFIX utility (and corresponding command line parameter).
- if will be usable to add to the Services API something to make it possible to rename or move original database file. I see it may decrease privacy of the server file system.
The text was updated successfully, but these errors were encountered:
I do not believe that extending the Services API to support *overwriting* an active database is appropriate. This is EXTREMELY DANGEROUS. The current functionality to restore to a new database, remotely, and then to shutdown the current database and replace it, via the server/console operations, is the only appropriate operation which should be supported.
Nor, do I believe that the Services API should provide functionality to change the database name. Again, this operation should be performed via server/console operations.
Quotation:I do not believe that extending the Services API to support *overwriting* an active database is appropriate.
No, I don't want this. And Yes, I can do all I needed from server console.
The issue was to let somebody do all needed operations WITHOUT ACCESS TO SERVER FILE SYSTEM.
I needed in:
Backup database - it's possible and I can ceate new file name for backup. Excellent
Restore database - it's possible ONLY if all connection closed and ONLY over existing file. I can restore database to another file name but I haven't access to server file system, so I can't rename restored file to the original name, so I can't use restored database.
So, what I want:
Yesterday, I backup my database
Today I want to restore my yesterday copy. What must I do and what can I do ? First, I must be sure that all connections are closed (how?). Second I want to rename my original database (how?). Third I want to restore database from backup to the original file name.
Submitted by: Vinokurov Alexander (vino)
Votes: 2
We have excellent possibility to backup database from client machine with the help of Services API. But there are problems, when we try to restore database in the same way.
First: we can't close all the connections to the database from client machine if other client machines have active transactions. Of course we can shutdown database and other client machines can't open new transactions, but: a) if some clients opened long read transaction and do nothing, the transaction may be endless and b) we can't see from our client machine if all the connections closed anyway but receiving exception on trying moving or renaming original database file.
Second: We can't rename or move current database file (because we haven't access to the server file system from the client machine by the security reasons). We only can restore database from one of the backup files over current database. It's not safety.
Third: We can't see list of previous backup files to select one of them. Yes, we can make log on the client machine or shared folder and append one name per backup.
So:
- It will be usable to add to the Services API function to close all connection because of SYSDBA request with sending notifying message to clients. It may be usable to add the same functionality to the GFIX utility (and corresponding command line parameter).
- if will be usable to add to the Services API something to make it possible to rename or move original database file. I see it may decrease privacy of the server file system.
The text was updated successfully, but these errors were encountered: