Steps to Move SQL Server Agent Jobs Between SQL Server Instances

SQLServerF1

When migrating SQL Server databases or instance from one server to another server or while upgrading from lower version of SQL Server to higher SQL Server version, there are many tasks to move various objects from source SQL Server instance to destination SQL Server instance which include Logins, Server Roles, Linked Servers, Credentials, Jobs, Operators, etc. All these objects can be created before-hand before the go-live so that the amount of work can be reduced during the downtime window. These objects does not change often, so they are better created while preparing the server for testing itself. Below are some of the important steps to move jobs, alerts and operators from one SQL Server instance to another SQL Server instance. Also there are additional steps to take care once these objects are moved to the target server.

Steps to Move SQL Server Jobs, Alerts and Operators
– Open the SQL Server Management Studio, and then expand the Management folder.
– Expand SQL Server Agent, and then either right-click Alerts, Jobs, or Operators.
– Click All Tasks, and then click Generate SQL Script.
– Run the generated file against the destination SQL server instance.

Additional Tasks to Perform before Running the Generated Script
– Jobs created by the generated script may have old login as owner which is not present on the new SQL Server instance or can be left blank is based on logins, so logins must be moved before running the Jobs creation script.
– If any of the jobs names contain old instance name, then they must be replaced by the new instance name.
– If any of the jobs code contains old instance name, then they should be replaced by the new instance name.
– If any of the code inside jobs is dependent on a linked server or backup devices, then Linked servers and backup devices should be moved before creating jobs.
– Maintenance plans jobs must not be scripted because maintenance plans will be recreated from scratch on the new SQL server instance.
– Replication jobs should not be created because it is better to recreate the replication manually which will create the jobs as there could be considerable changes in replication from one SQL server version to another SQL server version.
– Alerts should be verified and any references to old server names or objects not present on new server should be changed accordingly.
– Operators should be verified and made sure all required dependent objects are already present on the new server, if not then they need to be first created. Any references to old server name or objects not present on new server should be removed.

This is applicable on below versions of SQL Server

SQL Server 2005
SQL Server 2008 R2
SQL Server 2012
SQL Server 2014

Hope this was helpful.

Thanks,
SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, SQL Server Frequently asked questions, SQL Server Trainings.

 

Migrating SQL Server Linked Servers from One Server to Another

SQLServerF1

In many environments it is common to notice Linked Servers in various SQL Server instances. These are server level objects comes under security objects. DBAs are responsible for creating linked servers between SQL Server instances or to other 3rd party products such as Oracl, MySQL, DB2, etc. In situations when SQL Server instance is migrated from one server to another server due to hardware upgrade or when upgrading or migrating lower SQL Server version to higher SQL Server versions, all dependent objects also are required to be migrated which include Logins, Jobs, Linked Server as well. If there are one or two linked servers, DBAs can check the configuration of the linked server and create them on the new server, but in cases where the number of linked servers or configuration is different, it is better to find an automated way of moving the linked servers.

Linked server can be used in scheduled jobs, DTS packages, stored procedures or views. If linked servers aren’t created on the destination machine, any component or other user objects depending on them will fail. Below script can be used to script out the linked servers on source or existing of old server and then create them on the destination or target or new server using the generated script. Important thing to keep in mind is that this will not automatically copy over any remote security connections, so you would have to apply the appropriate logins manually. This can be found under the security tab of the linked server properties.

set nocount on
select ‘exec master..sp_addlinkedserver
@server = ”’ + srvname + ”’,
@srvproduct =”’ + srvproduct + ”’,
@provider =”’ + providername + ”’, @datasrc = ”’ +
datasource + ”” from master..sysservers
Where srvname <> @@servername

What are Linked Servers in SQL Server?
Linked servers allows the SQL Server Database Engine to execute commands against OLE DB data sources outside of the instance of SQL Server or remote SQL Server instances. Typically linked servers are configured to enable the Database Engine to execute a Transact-SQL(TSQL) statement that includes tables in another instance of SQL Server, or another database product such as Oracle. Many types of OLE DB data sources can be configured as linked servers such as Microsoft Access, Sybase, MySQL, Excel, etc. Linked servers offer advantages such as provides the ability to access data from outside of SQL Server, provides the ability to issue distributed queries, updates, commands, and transactions on heterogeneous data sources across the enterprise, provides the ability to address diverse data sources similarly.

This is applicable on below versions of SQL Server

SQL Server 2005
SQL Server 2008 R2
SQL Server 2012
SQL Server 2014

Hope this was helpful.

Thanks,
SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, SQL Server Frequently asked questions, SQL Server Trainings.

 

Moving SQL Server Databases from One Server to Another Server

SQLServerF1

One of the very common task for DBAs is to move or migrate databases from one SQL Server instance to another SQL Server Instance. The moving of the databases between SQL Server instances are regularly performed due to various reasons which include databases refresh from production to UAT or Development or Test environments, migration of databases during upgrades, hardware replacements, etc. It is very important to understand the various methods available to move the databases between the SQL instance and steps required to move to safely and successfully move the databases. Also, it is important to have options to quickly and reliable way of rolling back the changes in case of any issues. Below are some of the methods and steps required for moving or migrating SQL Server databases between SQL Server instances.

Backup/Restore: This is very reliable method of moving or migrating SQL Server databases from one instance to another instance safely. This method also leaves the existing databases on old server thus the rollback is easy during the downtime window. In this method Full, DIFF and LOG backups of the databases are performed on the source SQL instance and the backup files are copied over to the destination SQL instance and restore all the backups in order with norecovery option and restore the last log backup using with recovery option which brings the database online.  It is important to plan the type of backups to be performed on which times and prepare the sequence to restore the backup files. The amount of time taken to move the databases can be long if the size of the databases is big for which the backup, copy and restore of Full backup should be performed before the downtime and during the downtime, differential or log backup can be performed which will be small in size and can be moved quickly and restored quickly which will reduce the amount of downtime. This method is most widely used method for database refresh and migrations.

Detach/Attach: This is a good method, but involves lot of risk this not widely used. In this method, the databases are detached on the source SQL instance, the .mdf, .ndf, .ldf files are copied to the destination SQL instance and attached to the destination SQL instance. This method may take less time for moving the databases compared to the Backup/Restore, but has more risk of databases being unavailable on source server for long times. Also, if the databases contain any additional files like FullText or FileStream, then those files are to be copied as well and can become complex. In this method all connections to the source database has to be disconnected before the start of the task and will only be able to connect after all the steps are completed. This method can be used for small and non-critical databases.

Logshipping/DatabaseMirroring/AlwaysON: In this method, logshipping or database mirroring or AlwaysON Availability Groups is setup before-hand between the source and destination SQL instances and during the downtime the logshipping or database mirroring is stopped and removed and final log backup is performed on source and copied over to destination SQL instance and restored with recovery option which brings the SQL instance online. This involves very less downtime and the destination server can be prepared for migration well before and can continue even if the migration is post-poned for some days. This method is commonly used for migrating critical SQL instances from lower version to higher version or for migrating critical databases from one server to another server with less downtime.

This is applicable on below versions of SQL Server

SQL Server 2005
SQL Server 2008 R2
SQL Server 2012
SQL Server 2014

Hope this was helpful.

Thanks,
SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, SQL Server Frequently asked questions, SQL Server Trainings.

 

Steps to Uninstall SQL Server Failover Clustered Instance

SQLServerF1

Due to various reasons DBAs may need to uninstall SQL Server instances. The reasons could be due to retiring the old server after migrating to a new server, the installation got corrupted due to various problems, after failure of installation, etc. Starting with SQL Server 008, the way to uninstall SQL Server clustered instance has changed, where the uninstallation has to be performed of each node of the cluster which SQL Server instance is part of. Sometimes there can be requirement to remove only one node in which case the uninstall has to be performed on only that particular node. Below are some of the important steps to be followed to uninstall SQL Server clustered instance.

Steps to Un-Install SQL Server Clustered Instance
Browse to the SQL Server installation media folder and from the root setup media folder, double-click setup.exe by choosing Run-as-Administrator. If the media if present on network share or DVD disk, then copy the media to local drive.
Launch the SQL Server Installation Wizard which will bring the SQL Server Installation Center. To remove a node to an existing failover cluster instance, click Maintenance in the left-hand pane, and then choose “Remove node from a SQL Server failover cluster”.
The System Configuration Checker will run a discovery operation on the server. click OK.
After that Setup Support Files gets installed and then the System Configuration Checker verifies the system state of the system before Setup can continue further. After the check is complete successfully with all green, click Next to continue.
On the Cluster Node Configuration page, use the drop-down box to choose the name of the SQL Server failover cluster instance to be modified during this Setup operation. The node to be removed is listed in the Name of this node field.

The Ready to Remove Node page displays a tree view of options that were specified during Setup. To continue, click Remove.
Monitor the remove operation for successful completion. In case of any errors, review the setup logs and take appropriate action and then start from the first step of the uninstall process again.
Once the remove node operation completes, verify from control panel and SQL Server Configuration Manager to make sure the instance has been removed.
Reboot the node
Perform the same operations on other nodes from where the SQL Server instance has to be uninstalled or removed.
Delete any folders or files related to previous SQL Server instance, if not required any more.
Reinstall the failover instance if required and apply Service Pack/Cumulative Update if applicable.

SQL Server 2005 or before, uninstall has to be initiated from the control panel on active node and go through the uninstall wizard and choose the node which was to be removed. Other shared components are to be removed on both the nodes from control panel.

This is applicable on below versions of SQL Server

SQL Server 2005
SQL Server 2008 R2
SQL Server 2012
SQL Server 2014

Hope this was helpful.

Thanks,
SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, SQL Server Frequently asked questions, SQL Server Trainings.

 

Important Steps to Repair SQL Server Failover Clustered Instance

SQLServerF1

Installation Repair option was provided starting with SQL Server 2008 which is helpful in many cases during installation failure. Instead of uninstalling and reinstalling multiple times, repair option allows to fix any installation problems thus avoiding lot of duplicate work. Also the repair option comes handy during installation of service packs or CUs where repair can be used to fix any major problems left after main SQL Server install. SQL Server 2005 also had repair option which can be invoked from control panel, but it was very limited and often not very helpful. Below are some important steps which can be followed to perform repair of SQL Server Failover Clustered Instance.

Steps to Repair SQL Server failover Cluster instance
– Starting with SQL Server 2008, cluster installation has changed where installation setup has to be run on all the nodes which will be part of SQL Server Failover cluster instance. So, even Repair must be run on each individual cluster nodes that is affected or damaged.
– Launch the SQL Server Setup program from SQL Server installation media by choosing Run-as-Administrator.
– Initially there there are few setup rule check performed and then the Setup will show the SQL Server Installation Center page. SQL Server Installation Center was introduced starting SQL Server 2008 which has many options related SQL Server setup.
– Click on the “Maintenance” option in the left-hand side, and then click on “Repair” option which will start the repair operation.
– Setup will run some Setup support rules and some file routines are run to ensure that the system has all the prerequisites installed and that the computer passes Setup validation rules. Click OK or Install to continue.

– On the Select Instance page, choose the SQL Server instance which has to be repaired, and then click Next to continue.
– The repair rules will be run to validate if repair can proceed further or not. To continue, click Next.
– Ready to Repair page appears which indicates that the repair operation is ready to proceed. so click on “Repair”.
– The Repair Progress page shows the status of the repair operation. Monitor for successful completion of the repair operation.
– Repeat the same operations on the other nodes as well.
– Connect to SQL Server instance from SQL Server Management Studio and verify you are able to  connect.
– Verify SQL Server Errorlogs and Event Viewer Application and System logs to make sure there are no errors.
– Check the setup summary log file to make sure there are no errors reported during repair operation for any component which has been repaired.
– If the repair fails, then the only option that will be left with is to reinstall the SQL Server failover instance.

This is applicable on below versions of SQL Server

SQL Server 2008 R2
SQL Server 2012
SQL Server 2014

Hope this was helpful.

Thanks,
SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, SQL Server Frequently asked questions, SQL Server Trainings.

 

Oracle Database Errors or Warnings from Error ORA-01621 to ORA-01630

SQLServerF1

 

ORA-01621: cannot rename member of current log if database is open
Cause: This is a rename command for a member of the current log for an open thread. If the database is open anywhere, the log may be in use, so the rename cannot be done.
Action: Wait until the log is not current, or mount the database exclusively.
ORA-01622: thread number must be specified – default not specific
Cause: The thread was not specified when adding a log, and the currently mounted thread was chosen by default at mount time. Since the current thread was not specified explicitly the user cannot know which thread the log will be added to.
Action: Explicitly specify the thread number either in the INIT.ORA parameter “thread”, or in the add command.
ORA-01623: log string is current log for instance string (thread string) – cannot drop
Cause: A thread’s current log cannot be dropped even if the thread is closed. A disabled thread usually does not have a current log, but a half completed disable may need to be disabled again.
Action: If the database is not open then disable the thread. If the database is open and an instance has the thread open, then the instance can be requested to switch logs. If the database is closed the log can be archived or cleared to force a switch.

ORA-01624: log string needed for crash recovery of instance string (thread string)
Cause: A log cannot be dropped or cleared until the thread’s checkpoint has advanced out of the log.
Action: If the database is not open, then open it. Crash recovery will advance the checkpoint. If the database is open force a global checkpoint. If the log is corrupted so that the database cannot be opened, it may be necessary to do incomplete recovery until cancel at this log.
ORA-01625: rollback segment ‘string’ does not belong to this instance
Cause: Trying to shrink or take a rollback segment offline that does not belong to this instance.
Action: None
ORA-01626: rollback segment number ‘string’ cannot handle more transactions
Cause: Too many transactions in this segment.
Action: Choose a different rollback segment, or reduce the number of concurrent transactions.

ORA-01627: rollback segment number ‘string’ is not online
Cause: Could have been taken offline before by DBA or cleaned up by SMON.
Action: Check the status of rollback segment in undo$ or dba_rollback_segs to make sure the rollback segment is actually online.
ORA-01628: max # extents (string) reached for rollback segment string
Cause: An attempt was made to extend a rollback segment that was already at the MAXEXTENTS value.
Action: If the value of the MAXEXTENTS storage parameter is less than the maximum allowed by the system, raise this value.
ORA-01629: max # extents (string) reached saving undo for tablespace string
Cause: Save undo for the offline tablespace at max extents
Action: Check the storage parameters for the system tablespace. The tablespace needs to be brought back online so the undo can be applied .
ORA-01630: max # extents (string) reached in temp segment in tablespace string
Cause: A temp segment tried to extend past max extents.
Action: If maxextents for the tablespace is less than the the system maximum, you can raise that. Otherwise, raise pctincrease for the tablespace

Above are list of Oracle Database Errors or Warnings from Error ORA-01621 to ORA-01630 received while performing certain operation against Oracle Database or related products.

What are Oracle Database Error Messages?

Oracle Error Messages may be returned while using products which are part of Oracle Database.  Each Oracle Database Error or Warning Message mentioned above contains the Warning or Error Message Statement, a short explanation of the probable causes of the Error message, and a recommended action.

Hope this was helpful.

Thanks,
SQLServerF1 Team
Information about Oracle Database Error Messages or Warning Messages on Windows and Linux Operating Systems.

 

Oracle Database Errors or Warnings from Error ORA-01611 to ORA-01620

SQLServerF1

 

ORA-01611: thread number string is invalid – must be between 1 and string
Cause: A thread number in a command is greater than the number of threads supported by the control file.
Action: Use a thread number that is valid, or resize the thread record and/or checkpoint progress record sections of the control file.
ORA-01612: instance string (thread string) is already enabled
Cause: An attempt was made to enable a thread that is already enabled.
Action: Either use this thread or enable another thread.
ORA-01613: instance string (thread string) only has string logs – at least 2 logs required to enable.
Cause: The thread cannot be enabled because it only has two online log files associated with it.
Action: Add logs to the thread or pick another thread to enable

ORA-01614: instance string (thread string) is busy – cannot enable
Cause: The mount enqueue for the thread could not be acquired when attempting to enable the thread. This probably means that another process has already started enabling this thread.
Action: Wait and try again, or find another thread to enable.
ORA-01615: instance string (thread string) is mounted – cannot disable
Cause: Some instance, possibly this one, has allocated the thread for its use. The thread can not be disabled while in use.
Action: Shut the instance down cleany using the thread.
ORA-01616: instance string (thread string) is open – cannot disable
Cause: The thread is not closed. The last instance to use the thread died leaving the thread open. A thread cannot be disabled until it is closed. It is still required for crash or instance recovery.
Action: If the database is open, instance recovery should close the thread soon – wait a few minutes. Otherwise open the database – crash recovery will close the thread.

ORA-01617: cannot mount: string is not a valid thread number
Cause: The INIT.ORA parameter “thread” is not between 1 and the number of threads allowed by the control file.
Action: Shut down the instance, change the INIT.ORA parameter and startup, or resize the thread record and/or checkpoint progress record sections of the control file.
ORA-01618: redo thread string is not enabled – cannot mount
Cause: The INIT.ORA parameter “thread” requests a thread that is not enabled. A thread must be enabled before it can be mounted.
Action: Shutdown the instance, change the INIT.ORA parameter and startup mounting a different thread. If the database is open in another instance then the thread may be enabled.
ORA-01619: thread string is mounted by another instance
Cause: The INIT.ORA parameter “thread” requests a thread that has been mounted by another instance. Only one instance may use a thread.
Action: Shutdown the instance, change the INIT.ORA parameter and startup mounting a different thread.
ORA-01620: no public threads are available for mounting
Cause: The INIT.ORA parameter “thread” is zero, its default value. There are no threads which have been publicly enabled, and not mounted.
Action: Shutdown the instance, change the INIT.ORA parameter to a thread which is privately enabled and not mounted. If the database is open in another instance, then a thread may be publicly enabled.

Above are list of Oracle Database Errors or Warnings from Error ORA-01611 to ORA-01620 received while performing certain operation against Oracle Database or related products.

What are Oracle Database Error Messages?

Oracle Error Messages may be returned while using products which are part of Oracle Database.  Each Oracle Database Error or Warning Message mentioned above contains the Warning or Error Message Statement, a short explanation of the probable causes of the Error message, and a recommended action.

Hope this was helpful.

Thanks,
SQLServerF1 Team
Information about Oracle Database Error Messages or Warning Messages on Windows and Linux Operating Systems.

 

Oracle Database Errors or Warnings from Error ORA-01601 to ORA-01610

SQLServerF1

 

ORA-01601: illegal bucket size in clause “string” of string
Cause: The bucket size was invalid for this parameter.
Action: Correct the INIT.ORA parameter and restart the instance.
ORA-01603: illegal grouping size in clause “string” of string
Cause: The grouping size was invalid for this parameter.
Action: Correct the INIT.ORA parameter and restart the instance.
ORA-01604: illegal number range in clause “string” of string
Cause: The number range was invalid for this parameter.
Action: Correct the INIT.ORA parameter and restart the instance.

ORA-01605: missing numbers in clause “string” of string
Cause: The numbers were missing for this parameter.
Action: Correct the INIT.ORA parameter and restart the instance.
ORA-01606: parameter not identical to that of another mounted instance
Cause: A parameter was different on two instances.
Action: Modify the initialization parameter and restart.
ORA-01607: cannot add logfile to the specified instance
Cause: The limit on the number of instances supported by the control file has been reached.
Action: Use an instance name supported by the control file, or resize the thread record and/or checkpoint progress record secions of the control file.

ORA-01608: cannot bring rollback segment ‘string’ online, its status is (string)
Cause: Could have been brought online before by DBA or left as a result of process crash.
Action: Check the status of rollback segment in undo$ or dba_rollback_segs
ORA-01609: log string is the current log for thread string – cannot drop members
Cause: A member of the current log for a thread cannot be dropped.
Action: If the thread is opened, request a log switch by the instance that is using it. If it is not open, disable the thread, manually archive the log, or clear it.
ORA-01610: recovery using the BACKUP CONTROLFILE option must be done
Cause: Either an earlier database recovery session specified BACKUP CONTROLFILE, or the control file was recreated with the RESETLOGS option, or the control file being used is a backup control file. After that only BACKUP CONTROLFILE recovery is allowed and it must be followed by a log reset at the next database open.
Action: Perform recovery using the BACKUP CONTROFILE option.

Above are list of Oracle Database Errors or Warnings from Error ORA-01601 to ORA-01610 received while performing certain operation against Oracle Database or related products.

What are Oracle Database Error Messages?

Oracle Error Messages may be returned while using products which are part of Oracle Database.  Each Oracle Database Error or Warning Message mentioned above contains the Warning or Error Message Statement, a short explanation of the probable causes of the Error message, and a recommended action.

Hope this was helpful.

Thanks,
SQLServerF1 Team
Information about Oracle Database Error Messages or Warning Messages on Windows and Linux Operating Systems.

 

Oracle Database Errors or Warnings from Error ORA-01591 to ORA-01600

SQLServerF1

 

ORA-01591: lock held by in-doubt distributed transaction string
Cause: Trying to access resource that is locked by a dead two-phase commit transaction that is in prepared state.
Action: DBA should query the pending_trans$ and related tables, and attempt to repair network connection(s) to coordinator and commit point. If timely repair is not possible, DBA should contact DBA at commit point if known or end user for correct outcome, or use heuristic default if given to issue a heuristic commit or abort command to finalize the local portion of the distributed transaction.
ORA-01592: error converting Version 7 rollback segment (string) to Oracle 8 format
Cause: Look at the accompanying internal error; Version 7 database may not have shutdown cleanly.
Action: Investigate the internal error; may have to reload the Version 7 database (from backup) and shutdown the database cleanly.
ORA-01593: rollback segment optimal size (string blks) is smaller than the computed initial size (string blks)
Cause: Specified OPTIMAL size is smaller than the cumulative size of the initial extents during create rollback segment.
Action: Specify a larger OPTIMAL size.

ORA-01594: attempt to wrap into rollback segment (string) extent (string) which is being freed
Cause: Undo generated to free a rollback segment extent is attempting to write into the same extent due to small extents and/or too many extents to free
Action: The rollback segment shrinking will be rollbacked by the system; increase the optimal size of the rollback segment.
ORA-01595: error freeing extent (string) of rollback segment (string))
Cause: Some error occurred while freeing inactive rollback segment extents.
Action: Investigate the accompanying error.
ORA-01596: cannot specify system in string parameter
Cause: The system rollback segment is specified in the INIT.ORA parameter referred to in the error message
Action: change the INIT.ORA parameter

ORA-01597: cannot alter system rollback segment online or offline
Cause: Tried to online or offline the system rollback segment
Action: None
ORA-01598: rollback segment ‘string’ is not online
Cause: Could have been taken offline before by DBA or cleaned up by SMON.
Action: Check the status of rollback segment in undo$ or dba_rollback_segs to make sure the rollback segment is actually online.
ORA-01599: failed to acquire rollback segment (string), cache space is full
Cause: the amount statically allocated is not enough based on max_rollback_segments parameter.
Action: For now take another rollback segment offline or increase the parameter max_rollback_segments
ORA-01600: at most one “string” in clause “string” of string
Cause: The INIT.ORA parameter was mis-specified.
Action: Correct the INIT.ORA parameter and restart the instance.

Above are list of Oracle Database Errors or Warnings from Error ORA-01591 to ORA-01600 received while performing certain operation against Oracle Database or related products.

What are Oracle Database Error Messages?

Oracle Error Messages may be returned while using products which are part of Oracle Database.  Each Oracle Database Error or Warning Message mentioned above contains the Warning or Error Message Statement, a short explanation of the probable causes of the Error message, and a recommended action.

Hope this was helpful.

Thanks,
SQLServerF1 Team
Information about Oracle Database Error Messages or Warning Messages on Windows and Linux Operating Systems.

 

Oracle Database Errors or Warnings from Error ORA-01581 to ORA-01590

SQLServerF1

 

ORA-01581: attempt to use rollback segment (string) new extent (string) which is being allocated
Cause: Undo generated to extend a rollback segment run out of current undo block space and is attempting to write into the new extent which has not been completely allocated.
Action: The rollback segment extending will be rollbacked by the system, no more extension will be possible untill the next extent is freed up by rolling back or committing other transactions.
ORA-01582: unable to open control file for backup
Cause: An operating system error occurred while attempting to open a control file for backup.
Action: Check the error stack for more detailed information
ORA-01583: unable to get block size of control file to be backed up
Cause: An operating system error occurred while attempting to get the block size of a control file for backup.
Action: Check the error stack for more detailed information

ORA-01584: unable to get file size of control file to be backed up
Cause: An operating system error occurred while attempting to get the file size of a control file for backup.
Action: Check the error stack for more detailed information
ORA-01585: error identifying backup file string
Cause: An operating system error occurred when attempting to identify the file to be used for control file backup.
Action: Check the error stack for more detailed information
ORA-01586: database must be mounted EXCLUSIVE and not open for this operation
Cause: Attempting to DROPP DATABASE when the database is not mounted EXCLUSIVE.
Action: Mount the database in EXCLUSIVE mode.

ORA-01588: must use RESETLOGS option for database open
Cause: An earlier attempt to open the database with the RESETLOGS option did not complete, or recovery was done with a control file backup, or a FLASHBACKK DATABASE was done.
Action: Use the RESETLOGS option when opening the database.
ORA-01589: must use RESETLOGS or NORESETLOGS option for database open
Cause: Either incomplete or backup control file recovery has been performed. After these types of recovery you must specify either the RESETLOGS option or the NORESETLOGS option to open your database.
Action: Specify the appropriate option.
ORA-01590: number of segment free list (string) exceeds maximum of string
Cause: storage parameter FREELIST GROUPS is too large.
Action: Reduce storage parameters FREELIST GROUPS

Above are list of Oracle Database Errors or Warnings from Error ORA-01581 to ORA-01590 received while performing certain operation against Oracle Database or related products.

What are Oracle Database Error Messages?

Oracle Error Messages may be returned while using products which are part of Oracle Database.  Each Oracle Database Error or Warning Message mentioned above contains the Warning or Error Message Statement, a short explanation of the probable causes of the Error message, and a recommended action.

Hope this was helpful.

Thanks,
SQLServerF1 Team
Information about Oracle Database Error Messages or Warning Messages on Windows and Linux Operating Systems.

 
1 2 3