First of all, I use:
Windows 7 x64
Oracle Enterprise 11g R2 x32
I have some basic experience with SQL Server and MySQL (more with MySQL). Today I started working with Oracle, and I've been bumping a lot on the way.
The problem I'm having now is that, for some reason, I can't connect to any sys user (sysdba or sysoper). Probably I made a mistake writing the password when creating the database, but I'm not sure, so I'm trying to change it.
I've been trying, as some searches had led me to try, to use
sqlplus /nolog
connect / as sysdba
alter user sys identified by new_pass;
And it seems to work. I mean, it says "User altered". However, I still can't log in sqlplus with the new password. It's a little weird, since I can connect to "sysman" with my original password, but it doesn't have the privileges I need.
I'd appreciate any help I could get, and I thank you beforehand.
After you log in with 'sqlplus / as sysdba', try changing the password for system by issuing
ALTER USER system IDENTIFIED BY abcdef;
Then, to make sure, without quitting sqlplus:
CONN system/abcdef
That should work. After that, you can log on with system/abcdef when you start sqlplus.
The ORA-01994 error happens when you forget to use the orapwd command, and it critical to note that the name of the file must be orapwsid, and you must supply the full path name when using the orapwd command. 'orapwsid' sid is case sensitive.
A No Root password installation's the default. Now you were logged in as root#'%', but a bug exists. Compare how two SQL statements react:
ALTER USER CURRENT_USER() IDENTIFIED BY 'mariadb';
Always outputs mysql_native_password | |
alter user root#'%' identified by 'mariadb';
Job works and the root's identified by new password.
mysql_native_password | *54958E764C
I faced same problem in my server and I resolved them by following solution.
steps of solution.
1) change sys password from database connect with /as sysdba
2) down application and database and restart both 1 database 2 application
3) start listener and database then application.
now both are working fine.
Related
I am trying to create a database and each time I run the createdb [databasename], and enter the "incorrect" password, command I get the following error, createdb: error: could not connect to database template1: FATAL: password authentication failed for user "[username]".
However, the user that says the authentication has failed for doesn't exist. I can run psql -U postgres and enter the password I provided previously and log in just fine. Once logged in as Postgres user I run \du and only see the Postgres user in the table. Any reason this would be happening? I uninstalled and reinstalled and still have the same issue. Why is the default user something other than the original postgres user?
Here is the result of the \du command
List of roles
Role name | Attributes | Member of
-----------+------------------------------------------------------------+-----------
postgres | Superuser, Create role, Create DB, Replication, Bypass RLS | {}
The error message does not tell you the exact reason why authentication failed on purpose, to give attackers as little information as possible.
The cause of your problem might be that your username contains upper case letters on the operating system, but you created the database user without using double quotes, so that the upper case letters got translated to lower case.
If you want more than guessing, you have to tell us the exact command line and the output from \du.
I guess I had to add the username from my OS because that is what Postgresql defaults to, as well as add a DB with the same name.
I wrote an installation script to change the root password with this SQL command:
UPDATE user SET password='*C563415623144561...' WHERE user='root';
This doesn't work on Mysql 5.7:
http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-6.html#mysqld-5-7-6-account-management
My question is: how to change this command with another one compatible with 5.6 and 5.7 version of Mysql? I would like to update the password with a hashed string and not with a clear password.
This is no more password field in the user table as of mysql 5.7. It's now called authentication_string. You can change or set the password like this:
set password for 'jeff'#'localhost' = PASSWORD('mypass'); // this automatically hashes the password
If you you want to use your query , just change password to authentication_string,and it will work.
UPDATE user SET authentication_string='*C563415623144561...' WHERE user='root#localhost';
Hope this help.
I've used this command to reset to empty password in Mysql 5.7.22
ALTER USER 'root'#'localhost' IDENTIFIED WITH mysql_native_password BY '';
Given that 'SET PASSWORD FOR = PASSWORD('')' is deprecated as on mysql 5.7. If not done correctly you could even end up with below error in syslog.
The plugin 'auth_socket' used to authenticate user 'root'#'localhost' is not loaded. Nobody can currently login using this account.
I suggest to use below command.
ALTER USER 'root'#'localhost' IDENTIFIED WITH mysql_native_password BY 'mypass';
https://www.percona.com/blog/2016/03/16/change-user-password-in-mysql-5-7-with-plugin-auth_socket/
On Ubuntu 19.10 with mysqld version 8.0.19, none of the above worked for me. The instructions given here https://linuxconfig.org/how-to-reset-root-mysql-mariadb-password-on-ubuntu-20-04-focal-fossa-linux worked. It's for MariaDB, but it's the same if don't use MariaDB. The two key points are : the function password() is removed in mysqld 8.0+ and, for some reason, the unix socket for mysqld is not created with the --skip-grant-tables options. So, you must use these modified instructions:
$ sudo systemctl stop mysql
$ sudo mkdir -p /var/run/mysqld
$ sudo chown mysql:mysql /var/run/mysqld
$ sudo /usr/sbin/mysqld --skip-grant-tables --skip-networking &
Check that the daemon mysqld is running:
$ ps aux | grep mysqld
If it is running, then start mysql and change the password
$ mysql -u root
> FLUSH PRIVILEGES;
> USE mysql;
> ALTER USER 'root'#'localhost' IDENTIFIED BY 'N3w_p#ssw0rD.';
> quit
Important: before you (re)start mysqld, you need to kill the current process. Just stopping it the normal way does not work.
$ sudo pkill mysqld
$ sudo systemctl start mysql
Then you can test:
$ mysql -u root --password='N3w_p#ssw0rD.'
First of all look your specified mysql version security policies.
show variables like '%validate_password%';
you can change this policy if you like with
set variable_name=new_value;
Changing appropriate user password.
MySQL 5.7.5 and earlier version:
SET PASSWORD FOR 'user_name' = PASSWORD('new_password');
MySQL 5.7.6 and later version:
alter user 'user_name' identified by 'new_password';
For Server version: 5.7.25 - MySQL Community Server (GPL). Use below query as password is no more valid and replaced by authentication_string
UPDATE user SET authentication_string = PASSWORD('yourpassword'), password_last_changed = NULL
WHERE user.Host = 'localhost' AND user.User = 'username';
I'm no MySQL authority, but based on MySQL's current 5.7 documentation, the suggestions in the currently accepted and most upvoted answer strike me as inadvisable. (This is likely due to the passage of time -- the question and #mdamia's answer were both posted in 2015.)
The MySQL 5.7.6 (2015-03-09, Milestone 16) release notes linked by #Tobia's question say "ALTER USER is now the preferred statement for assigning passwords."
The question did ask if a single command could be used for both MySQL 5.6 and 5.7, but given that the ALTER USER syntax implemented by MySQL >= 5.7.6 offers a security enhancement, I would use the newer syntax when it is available. If I still had to operate a MySQL < 5.7.6 installation, I would limit my use of older and deprecated/discouraged password-updating syntax to those circumstances.
The ALTER USER statements suggested by #Carlos Alberto García Guardia and #Venkat Kotra in their answers thus seem to me like the right syntax to use for MySQL >= 5.7.6. Two examples (adapted from their answers and the ALTER USER documentation for MySQL 5.7): :
ALTER USER '<username>'#'localhost'
IDENTIFIED BY '<new_cleartext_password>';
ALTER USER '<username>'#'localhost'
IDENTIFIED WITH <auth_plugin>
BY '<new_cleartext_password>';
The second example above contains an optional WITH clause to specify an authentication plugin. The plugin specified gets written to the "plugin" field of the mysql.user table. For background on the history and future of MySQL authentication plugins, I found these MySQL Server Team blog posts helpful:
"Protecting MySQL Passwords With the sha256_password Plugin"
"New Default Authentication Plugin: caching_sha2_password"
In answer to #Tobia's question how to pass the new password to MySQL in hashed format rather than cleartext, the MySQL ALTER USER documentation indicates that this is done by using AS in place of BY in the ALTER USER statement:
ALTER USER '<username>'#'localhost'
IDENTIFIED WITH <auth_plugin>
AS '<new_hashed_password_value>';
When using AS instead of BY, the ALTER USER documentation says, the password string "is assumed to be already in the format the authentication plugin requires, and is stored as is in the mysql.user table." If a plugin requires a hashed value, "the value must be hashed in a format appropriate for the plugin. Otherwise, the value is not usable by the plugin and correct authentication of client connections will not occur." Id.
The currently accepted answer suggests using either a SET PASSWORD ... PASSWORD() statement or an UPDATE statement (the former for passing the new password in cleartext and the latter for passing it in hashed format):
SET PASSWORD
FOR '<username>'#'localhost' =
PASSWORD('<mypass_in_cleartext>');
or
UPDATE mysql.user
SET authentication_string='<mypass_as_hash>'
WHERE User='<username>';
These statements are deprecated and/or discouraged in relation to the currently preferred ALTER USER statement.
SET PASSWORD ... = PASSWORD(<cleartext>) "is deprecated as of MySQL 5.7.6 and will be removed in a future MySQL release", according to the SET PASSWORD documentation.
The SET PASSWORD ... = 'auth_string' syntax (i.e., leaving out the PASSWORD(str) encryption function) "is not deprecated, but ALTER USER is the preferred statement for account alterations, including assigning passwords." Id. See also Removal and Deprecation in MySQL 5.7:
We have deprecated the SET PASSWORD syntax and the PASSWORD() function. The existing ALTER USER statement is modified to cover the deprecated functionality. The PASSWORD() function was originally introduced as a way to manually update the mysql.user table. This is generally a bad idea and we want to leave the task of managing user authentication properties exclusively to using the ALTER USER statement which automatically determines which authentication plugin should be used and then adjusts the password algorithm accordingly.
As described by the manual, it also appears that UPDATE is less secure than ALTER PASSWORD with respect to logging. The manual indicates that UPDATE statements are written to logs as is, becoming visible to anyone with read access to the logs.[1] In contrast, the manual indicates, when MySQL writes ALTER USER ... IDENTIFIED BY ... statements (and also SET PASSWORD statements) to logs, it rewrites the contained passwords so they do "not appear literally".[1]
At least in most circumstances. The documentation for SET PASSWORD and ALTER USER warns that these statements too can be logged with visible passwords "under some circumstances",[2] although presumably not in all circumstances as apparently is the case with UPDATE.
1: See MySQL 5.7 manual on password logging ("In particular, INSERT or UPDATE statements for the mysql.user system table that refer to literal passwords are logged as is, so you should avoid such statements. (Direct modification of grant tables is discouraged, anyway.)")
2: See MySQL 5.7 SET PASSWORD documentation and MySQL 5.7 ALTER USER documentation
Disclaimer: I'm just sharing my interpretation upon reading the MySQL manual today. I haven't tested MySQL's behavior with respect to what password-altering statements it logs where in what format.
This is the only way to me in: mysql Ver 14.14 Distrib 5.7.30
UPDATE user SET authentication_string = PASSWORD('YourPassword'), password_last_changed = NULL
WHERE user.Host = 'localhost' AND user.User = 'YourUsername';
I am using oracle 10g express edition. I ran the command in sql command line and it says -- "ORA-00942: table or view does not exist"
PS: Trying to access and increase the number of processes. Cause I am facing this problem -- How to solve ORA-12516 error?
You're probably running this command as a non-privileged user. show parameter is just a fancy wrapper for select ... from v$parameter. You need SELECT privileges on this view:
grant select on v_$parameter to <username>;
(please note the _ in the view name - you cannot directly grant privileges on v$ views, you have to grant privileges on the underlying objects instead).
Of course, the simplest approach is to run show parameter as a DBA user.
I currently have an issue whereby I cannot reference a table in a linked database within a stored procedure. I get the error message:
ORA-00942: table or view does not exist
Here are the steps I took on the host machine (running oracle 10g) to set up the database link to the remote database (running oracle 11g). The steps are accurate, but some some names have been changed, though they have been kept consistent.
Update tnsnames.ora, adding a new entry:
REMOTE_DB =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)
(HOST = 10.10.10.10)
(QUEUESIZE = 20)
(PORT = 1521)
)
(CONNECT_DATA =
(SERVICE_NAME = remote_service)
)
)
Create database link, as the user who will later be creating and executing the stored procedure:
create database link remote_link
connect to "remote_user"
identified by "remote_pass"
using 'REMOTE_DB';
Prove database link is working by selecting from it:
select id from remote_table#remote_link;
id
--------------------------------------------------------------------------------
8ac6eb9b-fcc1-4574-8604-c9fd4412b917
c9e7ee51-2314-4002-a684-7817b181267b
cc395a81-56dd-4d68-9bba-fa926dad4fc7
d6b450e0-3f36-411a-ba14-2acc18b9c008
Create stored procedure that depends on working database link:
create or replace
PROCEDURE test_remote_db_link
AS
v_id varchar(50);
BEGIN
select id into v_id from remote_table#remote_link where id = 'c9e7ee51-2314-4002-a684-7817b181267b';
dbms_output.put_line('v_id : ' || v_id);
END test_remote_db_link;
Explode own head after staring at the following error message for over an entire working day:
Error(10,27): PL/SQL: ORA-00942: table or view does not exist
I have tried many things to try to sort this issue out, including:
When creating the database link, not using quotes around the username and password. Link creates fine, but selecting from it gives me this error:
ERROR at line 1:
ORA-01017: invalid username/password; logon denied
ORA-02063: preceding line from TWS_LINK
Tried various combinations of username and password in upper/lowercase. Received same error as 1.
Tried single quotes instead of double quotes around username and password. Recieved this error:
ERROR at line 1:
ORA-00987: missing or invalid username(s)
Proved I have full access to the remote db by connecting into it with sqlplus:
[oracle]$ sqlplus remote_user/remote_pass#REMOTE_DB
SQL*Plus: Release 10.2.0.1.0 - Production on Thu Oct 20 22:23:12 2011
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL>
I'm not sure what to do next. The possible next step is to start looking at issues on the remote database, and perhaps see if other databases can connect to it. Another would be to look at incompatibilities going from host 10g to remote 11g.
OK so I was able to get this working, of sorts.
It turns out that when creating the database link, the double quotes around the username and password fields were causing the issue. To summarise:
If they were present, and the link created as so:
create database link remote_link
connect to "remote_user"
identified by "remote_pass"
using 'REMOTE_DB';
The remote database could be queried via sql
The stored procedure could not be compiled, recieving the ORA-942 error
As the procedure could not be compiled, it could not be executed
When the double quotes are not present:
create database link remote_link
connect to remote_user
identified by remote_pass
using 'REMOTE_DB';
The remote database could not be queried via sql, recieving an invalid password error (detailed in the question)
The stored procedure could be compiled with no errors.
The stored procedure executes as expected, retrieving data from across the database link, and displaying it.
So, even though the remote database cannot be querued via sql, recieving an invalid password error, the procedure that uses this same connection information compiles and executes normally.
I'm sure you'll agree, this is a curious state of events, and I genuinely stumbled across making it work in my scenario. I'm not quite sure I would call it a solution, as there are plenty of unanswered questions.
Hopefully if someone comes here via google, they'll find this answer useful, and at least get their code running.
GC.
I faced the same issue on 11gR2, and I'm thankful to this forum for helping me find the problem. The way to make the db link work in both SQL and procedure is to follow the below syntax (enclose only the password within double quotes).
create database link remote_link
connect to remote_user
identified by "remote_pass"
using 'REMOTE_DB';
I think I see a problem here. Is the user who is executing the stored procedure the same user who created the stored procedure?
You said, "Create database link, as the user who will later be executing the stored procedure".
If the user creating the database link is different from the user creating the stored procedure, that may be your problem.
Try creating the stored procedure and database link as the same user, or creating a public database link.
Then, since Oracle default is definer rights, you can have anyone execute the stored procedure (assuming they have been granted execute privilege on the procedure).
In order to see all of the tables in our companies DB I have to go find the main sys account. Is there a way to default my connection so that it shows the other users tables?
Any table that your connecting account has at least SELECT privileges on will show up in the "Other Users" node of the navigation tree. If the table does not show up there then it is a database permissions issue, not a SQL Developer configuration issue.
Think you don't want to repeated type otheruser.tablename in all your queries. If that is the case you want to run this
alter session set current_schema = otheruser;
What do you mean by "see all of the tables"? Are you happy if you know they're there, or do you need to see their content. In the former case dba_tables should do. In the latter case it's a matter of the privileges assigned to you.
Change your connect to login as the main Sys user. Otherwise like dpbradley says you will have to go find them under the Other Users node.
If you connect to (e.g.) DB2 using JDBC driver, you can use this syntax:
jdbc:db2://localhost:50000/WESBDB:currentSchema=WESB;
Not only that the schema WESB will be your current schema, but it will be also the default schema in the tree on the Connections tab.
Note: It seems that it works for DB2 only.
As Ram, I also do it with
alter session set current_schema = otheruser;
It works if you want to access to the tables of a particular user