I just installed my oracle database and made some tables for school. My problem is that it looked kind of different because the one we use in school had no tables(clean and empty) but the one that I had installed is filled with tables that I do not understand(I did not make them either).
It is a new install I got from the official website and it had tables named like: AQ$_INTERNET_AGENT_PRIVS, AQ$QUEUES and much more. I have no idea where they come from and every time I go look at my tables I just get confused because of all these things mixed in.
Is it safe to remove them or are they important enough to keep? If removing them is a bad idea, what do I have to do so that I don't see them anymore and all that is listed are the tables that I have created myself?
Those are system tables, you're probably logging in to an account with DBA privileges. Create yourself a new schema (user_id/password) and don't give yourself dba privileges, then you can remain as ignorant as you want about what Oracle is doing under the hood.
Related
I get postgresql database at my work, it was managed by person whos not work anymore there, there is no documentation and I have very little experience with postgresql.
The thing is that one table is no longer updated, my question is how can I find in workbench what code actually updates the table. I was googling workbench documentation and also trying to find it in this program but with no luck.
I don't know anything about "workbench" but it doesn't seem as if this tool is going to help you much in your investigation.
As suggested by #AdamKG, scan your codebase.
If you have DB logs from when the table used to get updated, then you might be able to find clues from there: User IP, application name, DB user name, SQL, etc. This depends heavily on your DB logging parameters. And your logs retention policy, of course...
I want to create table automatically using new table option in oracle SQL developer,but that option is disabled in my tool.
Can any one please help me out in this issue.
Please find the below image highlighted with red mark for your better understanding.
Thanks in advance.
To quote Jeff Smitth:
SQL Developer is built by Oracle, for Oracle. It’s the database IDE.
...
But, SQL Developer is also ... a 3rd party database migration platform.
...
Since we support migrations from these other database platforms, wouldn’t it be neat if SQL Developer could connect and query those 3rd party databases too? Surprise, surprise – that’s exactly what we DO do today.
What ‘Support’ means
You can connect to, browse, and query (SELECTs only) SQL Server, DB2, Access, MySQL, and Teradata.
What ‘Support’ does NOT mean
providing debuggers
delivering database administration features
write access to the database
Sound a little harsh or spartan? Going much further in any of these areas would just open a big ole can of worms, and we’re committed to providing an optimal experience for the Oracle database. But, since we already support these limited features, there’s no real reason to hide it.
That post is from 2012, but as far as I'm aware is still mostly true.
Since creating tables would count as write access and a DBA feature, it isn't a matter of enabling the option for your MySQL database, it isn't supported. This is an area of functionality that only applies to Oracle databases. (Even though Oracle Corp. owns MySQL... this means the Oracle RDBMS).
I've recently decided to embark on a fun / educational personal project to create some data visualizations and power metrics for my fantasy football league. Since ESPN doesn't provide an API, I've decided to use a combination of elbow grease and the nfldb to pull relevant data (and am hoping to get familiar with Plotly for presenting the data). In setting up nfldb, I'm also getting my first exposure to databases, using postgresql in particular (as required by nfldb).
Since the installation guide provided by nfldb is Linux-centric and assumes a fair bit of previous database experience, I've looked to this guide for help and blindly followed its instructions in hopes of sidestepping postgresql (aka the "just make it work" "solution"). Of course, that didn't work, and I have no idea how to diagnose the problem(s), so I've decided to go ahead and use this opportunity to get a little familiar with databases / postgresql.
I've looked to the postgresql documentation for guidance. Having never worked in a server / client environment, the following text (from "18.1. The PostgreSQL User Account") has me particularly confused:
As with any server daemon that is accessible to the outside world, it is advisable
to run PostgreSQL under a separate user account. This user account should only own
the data that is managed by the server, and should not be shared with other
daemons. (For example, using the user nobody is a bad idea.) It is not advisable
to install executables owned by this user because compromised systems could then
modify their own binaries.
To add a Unix user account to your system, look for a command useradd or adduser.
The user name postgres is often used, and is assumed throughout this book, but you
can use another name if you like.
I'd really appreciate a well annotated version of these paragraphs. How does it apply to someone like me, storing and accessing date on the same machine? Do I need to create a new system user account? How do I make sure it "only owns the data that is managed by the server"? Where is the responsible location to install postgresql? Am I exposed to some sort of security risk by downloading the nfldb database? Why is the user nobody a bad idea?
Relevant: I am using a Mac (v10.11.6) and plan to install (or re-install, if necessary) postgresql using Homebrew.
While the current connection is made to db1, I want to change privileges on db2. Like:
GRANT ALL PRIVILEGES ON SCHEMA "db2"."public" TO "user";
But this results in error, and PostgreSQL does not recognize the database qualifier in the statement! Is there any way I can do this without disconnecting from db1 and reconnecting to db2?
BTW, I'm commencing these commands from a programming language and not the psql.
[UPDATE]
As I was told in comments, it seems that this feature is intentionally blocked (due to implementation challenges or security reasons - I'm not sure).
In any case, I don't see a good reason for that and that's my personal opinion. If it is hard to implement, then it's a design flaw. And I think the security argument can be easily scratched as adding steps to the process for a user who's already been authenticated and authorized to do so, is not considered a better security.
Again, just my opinion.
In any case, I'm really thankful for all the time and effort put into PostgreSQL project. Thanks guys.
First, I don't know if this is by intent or by the lack of implementation but this is a long-standing behavior in PostgreSQL. There are no cross-database references. There are a number of reasons why at present there probably never will be, especially the difficulty in doing things like making the system catalogs behave properly. Basically, database A has no knowledge of the structures in database B.
Secondly, cross-database information sharing is also a little inconsistent in PostgreSQL. pg_locks (for some strange reason) shows all across all databases. So I am thinking that this is probably an organic development rather than people sitting down and coming up with a policy on this. Similarly, as you are probably aware, roles and users are cluster-global. So I can see why this would seem a little bit inconsistent.
The correct way to do this in PostgreSQL is to connect to the DB you want to manage permissions in. There is no other way currently for PostgreSQL to get access to the appropriate catalog entries and modify them and the changes are likely to be so breaking that such seems to me to be unlikely to ever happen.
I decided to give PostgreSQL a try. It looks really interesting, but it isn't very user friendly at all.
I got some great help from the PostgreSQL e-mail list, but they insist that the tool to use is the command-line editor (PSQL). Unfortunately, it's a total disaster. When I open it, it opens at least two instances, which soon multiply into a dozen. It also seems to somehow hijack my Apple terminal on my Mac. I can type the same command into two different terminal boxes and get two different results. I don't have a clue what's going on.
Anyway, to get to the point, PostgreSQL is obviously over my head. There's a local PostgreSQL users group that meets once a month - at night, when I'm working. But I'd like to try and make the very beginning of their next meeting and drop them a note. I'd like to hire someone to help me get PostgreSQL set up on my laptop and online, fix whatever the problem is and show me how to create a database and table.
Actually, I've already created a database and table, which I can access with pgAdmin III. But I can't see them with the shell/ terminal. So that's my question: If I can hire someone to get PostgreSQL up and running, will I be able to work with it using pgAdmin III or some other tool, or am I going to be chained to the shell (PSGL)?
If the shell/terminal is indispensable, then I think I'm going to abandon it. It looks like a great program, but I just don't have time to jump through all the hoops right now.
You don't need psql to use PostgreSQL. Many experienced users prefer it, but you can use nothing but PgAdmin and get by just fine. That's what a great many users do.
PostgreSQL is fine on Mac OS X. A number of core developers use Mac OS X and do their development on it. Much like many MySQL users use phpmyadmin, etc, and never use the mysql command line tool.
There were some packaging issues on OS X related to Apple's bundling of PostgreSQL but those are resolved in more recent versions of OS X.
There are also some challenges with different packages of PostgreSQL on OS X - EnterpriseDB, Macports, Homebrew, etc. But those are mostly a matter of documentation and user misunderstanding; each package is in its self just fine. Similar issues exist on Linux, where OS packages, PGDG packages, and EDB's packages can tread on each others' toes.
Characterising the PostgreSQL community as a "Microsoft/Linux fan club" is hilarious, by the way. Windows is tolerated at best by most of the core devs and users on the mailing list.
It's really hard to tell what problem you're encountering based on the description given. Maybe you have multiple different PostgreSQL packages installed, so you have more than one server instance, and are getting them confused? Similarly, I can't tell what's going on with the psql terminal link in the dock. I'd ignore it and use psql from the usual Apple Terminal.app if you want to use psql. Otherwise just use PgAdmin.
One area where you will run into trouble is that because most experienced users use psql, if you ask questions specific to PgAdmin or other tools, rather than PostgreSQL its self, people will pretty much shrug their shoulders and say "dunno, but you do it like in psql". I haven't used PgAdmin for my own stuff in years, and have to go hunting around in the manual if I want to figure out how to do something so I can explain it to somebody. Moreso with things like Navicat, which I've never used at all. The people who use those tools are usually not the ones spending their time helping other people out, so you get help from experienced and enthusiastic users who're also the ones most likely to use the expert-oriented tools.
Relevant link: http://phili.pe/posts/postgresql-on-the-command-line/
I've been using DBeaver to write and execute my Postgres queries because I don't like neither psql nor PgAdmin. Not that DBeaver is without its faults but at least it has decent code completion and an easy way to switch databases / schemas. In the end it's also about what you're used to and I guess coming form SQL Server with Management Studio I found this an easier way in into Postgres.
It's true that in most Postgres books psql is the standard but I usually try to convert the psql specific code to queries I can run in DBeaver, which is usually an interesting (although somewhat frustrating at times) exercise...