I was able to login to sqlplus with my credentials to do the SHUTDOWN command. It worked and the database shutdown. But now when I try to login again with the same credentials to start the server back up, it says: "ORA-01033: ORACLE initialization or shutdown in progress". How can I log in to sqlplus and use the STARTUP command?
This is on Linux Debian - Oracle 12C.
EDIT: I shutdown the database to import a copy of old oradata contents.
Login with operating system credentials that don't require the database to be open:
C:\>sqlplus / as sysdba
If things are really messed up you might need to connect using the prelim option:
C:\> sqlplus -prelim / as sysdba
If the database is hung and not shutting down properly sometimes you need to do a shutdown abort and then start it back up:
SQL> shutdown abort
ORACLE instance shut down.
SQL> startup
This is also possible with the srvctl command but in my experience it's not as reliable as a SQL*Plus shutdown abort.
Related
I have installed Oracle 12c with one pluggable database namely RHQDDBPDB.
I am successfully able to connect to my container database and pluggable database as sysdba through SQL developer on my DB server
I have created one user rhqddbpdbadmin on my pluggable database RHQDDBPDB with sysdba role. I am able to connect to pluggable database with this user as sysdba.
The problem that I am facing is as follows:
When connecting to the Container or Pluggable database through SQLPLUS from another machine as sysdba, I am getting error ORA-01017.
However from remote machine, if I connect with rhqddbpdbadmin user as Normal (without sysdba), then connection is successfull.
Commands i am using from remote machine:
sqlplus rhqddbpdbadmin/xxxxxx#rhqddbpdb as sysdba
Throws error ORA - 01017
sqlplus rhqddbpdbadmin/xxxxxx#rhqddbpdb
Connected successfully.
Please help.
Thanks for your time.
Connecting as sysdba from a remote location (over tcp or tcps) requires some extra steps:
Set the database parameter REMOTE_LOGIN_PASSWORDFILE = { shared | exclusive | none }.It should be set tp shared/exclusive.
Check your password file under $ORACLE_HOME/dbs/, which is being used for authentication when users login to the database as a sysdba. If the password file does not exist then create a new one (using orapwd) and set the password.
I am a local Admin on my machine. Same old thing, my account wasnt added when SQL Server was installed, and I don't want to have to reinstall SQL Server. I went through this blog and it worked until I tried to log and run the commands via SQLCMD or SSMS. I got the error message
"Login failed for user '/'. Reason: Server is in single user mode. Only one administrator can connect at this time.."
I found this blog and added the application name after the m switch http://sqlserver-help.com/2013/12/06/help-how-to-fix-error-reason-server-is-in-single-user-mode-only-one-administrator-can-connect-at-this-time/. But no dice, I still get the above error. The User Account looks fine I guess, I am an Administrator.
Also, I had to start the cmd prompt as an Admin to start sqlserver in single user mode. OR else I couldnt have access to the log files that the instance was using and it was giving me an error to that. So I ran the cmd prompt as admin. But still, I am the same admin trying to run SQLCMD or SSMS. It shoudlnt be telling me there is already an admin logged in, because I am that admin. What am I missing?
This is on SQLExpress, I dunno if that matters
Thanks!
First login to the server: "sqlcmd –A –d master"
.
connect to the master database with the DAC because master is guaranteed to be available if the instance of the Database Engine is started.
Shut down the database server and restart it with minimal configuration:
sqlservr.exe -f -s <instancename>
If it works fine, then you have a problem with your startup configurations and you need to find out which is causing you the issues.
We have some deployment scripts that use a combination of dacpacs through sqlpackage and straight scripts using sqlcmd.
When I execute the sqlpackage dac\sqlpackage.exe /p:BlockOnPossibleDataLoss=False /p:BackupDatabaseBeforeChanges=True /a:Publish /sf:.\somedeploy.dacpac /tcs:"Data Source=MyDB;Initial Catalog=MyCatalog;Trusted_Connection=True;"
I get an error message *** Could not deploy package. Unable to connect to target server. I have login auditing turned on in sql and the message I am getting is Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. [CLIENT: 111.222.223.224]
However, I can run our sql scripts through sqlcmd no problem by using the -E argument.
sqlcmd -i Permissions\CreateSqlUser.sql -S MyDB -E
I am running from a commandline that is set to "Run As Administrator" and am currently signed in as the admin. This is running on a Windows Server 2012 VM. I am using sql 2014. We have other installs that haven't had problems but this is our first 2014 install so we are trying to determine if something changed or if we are missing something and if so what.
If I run from profiler I don't see any audit log error messages. I checked the filters and what events I'm listening for and they all look good. Inside sql when I run exec sys.sp_readerrorlog 0, 1, 'Login Failed' I do get the messgaes to show up. (I might be doign something wrong in profiler). Also they show up in the system event logs. I'm not seeing anyplace where it tells me anything about the user attempting to login though.
If don't use trusted connection for sqlpackage and instead use a username and password it works fine. However, part of what our deployment script does is create the users so our preference would be to not do this.
A database administrator has used to connect to oracle database on unix operating system by using the following:
$ sqlplus sys/sysPass1#orcl as sysdba
What are the big mistakes in the previous method to connect?
What do you suggest to avoid such mistakes?
Please help me ...
That it exposes the password to other users running a ps -e command.
I'd suggest using an Oracle wallet to avoid the need to specify a password/
It is not necessary to connect to the database in this way - unless you are using Oracle RAC.
If the environment variables ORACLE_HOME and ORACLE_SID are correctly used and the unix user is in the DBA group and you are on the DB server a
sqlplus / as sysdba
is still working.
If you are using a script it is always a good idea to connect with
sqlplus /nolog # script.sql
and in the script as first line
connect user/password#tnsnames
or, if the script is running on the database server
connect user/password
We are running deployment scripts using pstrami. Part of the deployment is to execute database migrations. The migrations are using an connection string with Integrated Security.
When the script executes on the remote machine the migrations fail with a sql error saying Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'
The person executing the script is a domain administrator. Other deployments that we run execute the remote scripts with the user who started the process.
The problem is that the credentials are not hopping to SQL Server for integrated security. You need to do the following:
On the server (the one that is making the SQL Server connection, as administrator run:
Enable-WSManCredSSP -Role server
On the client machine, as administrator run:
Enable-WSManCredSSP -Role client -DelegateComputer YOUR_SERVER_NAME
To open this up to all servers, you can run:
Enable-WSManCredSSP -Role client -DelegateComputer *
Finally, your invoke command make sure you run -authentication credssp. An example:
invoke-command -computername $remoteServer -authentication credssp -scriptblock { write-host "hello!" } -credential $credentials
This is the scenario:
You run the pstrami(deployment) script from desktopA. The script pushes your installation files to serverA. Then on serverA the scripts are run remotely as the person inititating the script from desktopA. One of the steps is to run a sql database upate with fluentmigrator using a connection string paramter using "integrated security" and the database is on serverB.
Connection string example:
$migration_db_connection = Data Source=serverB;Initial Catalog=PropertyDb;Integrated Security=SSPI;
.\migrate.exe /conn "$migration_db_connection" /db SqlServer /a $migration_assembly /profile DEBUG
Pstrami uses the powershell command invoke-command which uses the account you are running the script under as the default user. So, what happens is that when you run the script from desktopA as "jonDoe" it then authenticates on serverA. So your pstrami scripts run under "jonDoe" on serverA. When you execute the fluentmigrator script on serverA as "jonDoe", fluentmigrator returns an error Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'. In IIS, you run into an interesting situation when you need to access another resource off of the IIS server and certain fairly common situations occur. When using Integrated Security, anonymous access is disabled, and impersonation is turned on, a Windows security measure kicks in and doesn't allow your site to access resources on any network servers. (http://weblogs.asp.net/owscott/archive/2008/08/22/iis-windows-authentication-and-the-double-hop-issue.aspx)
This is how I got around the Windows Authentication and the Double Hop problem I ran into. Run your migration scripts directly on your sql database server and include it as a server target in your pstrami environments.
Example:
Environment "dev" -servers #(
Server "serverA" #("InstallWeb")
Server "serverB" #("RunMigrations")
)
More on Double Hop
http://www.spdoctor.net/Pages/message.aspx?name=login-failed-for-user-bdc
http://www.sqlservercentral.com/blogs/sqlsandwiches/2011/06/20/double-hop-of-doom/
I am not able to comment on your question and posting this as an answer. I will update the same later.
It may be due to SQL Server not having the login account for your windows login account. If that is the problem please add the logged in user to the SQL Server in the remote machine.
If this is already addressed, then you have the option of giving Rights as DB_Owner to " NT AUTHORITY\ANONYMOUS LOGON " on the SQL Server as well as on the specific database you are using.