We have installed 2 instance of same application in a same datacenter. Both the app is using same oracle DB. But we are observing performance issue in one application. In AppDynamics we can see the response time of one application is much higher that other.
Is it possible to intentionally prioritise/configure the DB such a way. If yes, where should I look into the database.
Any Idea why this is happening? I am totally clueless here.
In theory, yes: if Resource Manager has been enabled it could be the case that different Resource Manager plans have such an impact but experience shows that this feature is seldom used.
In practive this kind of difference can have many cause:-
different SQL statements run
data is different
database statistics differences
different database configuration
different hardware
etc.
The first thing to look at database level is something similar to Statspack report (or AWR if licensing allows) to compare database configuration and activity.
And don't forget that application performance is not only database performance it depends also on application server, network and front-end.
Related
I am a Java guy, I can work with Oracle Database, I know PLSQL, SQL. But I am not good at managing database servers. I think it is a completely different area.
My question is related to database replication. I googled it, found millions of answers but I am still confused.
I could see many times in my professional carrier that developers create complete (complicated) applications to keep sync the source database schema to a target one. It takes time to develop sync apps and very hard to maintain them, especially in case of any data structure modification for example in tables.
I could see that apps built with JPA, JDBC, Spring, myBatis, and PLSQL as well. Usually, they sync DBs during the night, scheduled by Cron, Quartz, Spring, etc. During the sync process usually, the source DB is only available for querying data, not for inserting and DB constraints and triggers are disabled.
These kinds of custom applications always scare me. I do not believe that there is no general, easy, and official way to keep sync two databases without developing a new application.
Now, I got a similar task and honestly, I would like to write zero lines of code related to this task. I believe that there are recommended and existing solutions, cover this topic offered by the database vendors.
That would be great if you can push me in the right direction. I feel that writing another new DB sync application is not the right way.
I need to focus on Oracle Database sync, but I would be happy to know a general, database vendor-independent way.
There are many ways to perform replication in a Oracle Database. Oracle has two replication techniques in the database "Advanced Replication" and "GoldenGate". GoldenGate us the new perferred method of replication which uses the redo logs files from the database. Both methods are geared for a Oracle DBA.
Often application developers will create a "interface" that will move data from one database to other. A interface is a program ( pl/sql, bash, c, etc ) that runs on a cron (database or system) that wakes on a event to move data. Interfaces are useful when data is needed to be process during replication.
Two Spring apps each use jpa to control a single database.
Each Spring app must use a single database.
Will spring.jpa.hibernate.ddl-auto = update work properly?
In my opinion, having 2 applications using directly the same database is a poor design.
Here is a quote from this sofware engineering answer
The more applications use the same database, the more likely it is
that you hit performance bottlenecks and that you can't easily scale
the load as desired. SQL Databases don't really scale. You can buy
bigger machines but they do not scale well in clusters!
Maintenance and development costs can increase: Development is harder
if an application needs to use database structures which aren't suited
for the task at hand but have to be used as they are already present.
It's also likely that adjustments of one application will have side
effects on other applications ("why is there such an unecessary
trigger??!"/"We don't need that data anymore!"). It's already hard
with one database for a single application, when the developers
don't/can't know all the use-cases.
Administration becomes harder: Which object belongs to which
application? Chaos rising. Where do I have to look for my data? Which
user is allowed to interact with which objects? What can I grant whom?
Upgrading: You'll need a version that is the lowest common denominator
for all applications using it. That means that certain applications
won't be able to use powerful features. You'll have to stick with
older versions. It also increases development costs a bit.
Concurrency: Can you really be sure that there're no chronological
dependencies between processes? What if one application modifies data
that is outdated or should've been altered by another application
first? What about different applications working on the same tables
concurrently?
What I would suggest to you is to create a service layer which will be responsible for dealing with database access. This service can then be accessed by differents ways (a REST webservice might be an option).
#Vinod Bokare comment is correct, you must create jar of POJO's and use in both projects,
and #Heejeong Jang, It will be okay if each of our Spring apps has different table areas for insert, update, and delete.
We are having an application i.e. exposing RESTful web services and we are targeting this application to be deployed in cloud. We need to one time setup a database schema for the application on some database instance in the cloud.
Can someone tell me if it is a good approach to use migrations with liquibase for the one time database schema setup. We will be using alter scripts in case some DDL modification needed in future releases.
Someone stop me if I'm wrong, but the fact you application will be deplyed on the cloud only mean it will be on a virtual server hosted by an extern compagnie, wich in the case of your question don't chance anything.
So the question is "is the database versionning system Liquibase on a database with an aimed stable shema worth it".
In absolute it could be considered overkill, and a lot of big companies still manage database schema evolution with bare sql scripts. You could simply export the final built script of your developpement database and go with it.
But since you know Liquibase, the overhead is pretty cheap, and the comfort of using if you happen to have to modify tour shema later is important.
So yes, I think it's a pretty good pratice (safer than hand applying script under the stress of a production server problem) which cost one or two hours(given you know how to use the tool) and can save dozens when having to handle hotfixing of a production database.
I assume that you will be deploying this application in more than one place - not just production in the cloud, but also development servers, test servers, staging, etc. If that is true, then it seems to me that you definitely want to have a process around how you make changes to the database schema.
For me, over the course of my 20+ years in software development, I have seen several things that I use now that were not in common use when I started but that have now become 'baseline' practices on any project I work on. Yeah, I used to work without source control, but that is an absolute must now. I used to write software without tests, but not any more. I used to work without continuous integration, but that is yet another practice that I consider a must-have. The most recent addition to my must-have list is some sort of automated database migration process.
Also, since Liquibase is built-in to Dropwizard, I don't see any reason not to use it.
I'm trying to eliminate a slow database being the cause of some performance issues for a distributed application I'm supporting. I've done local profiling of various facets of the application and performance monitoring of the server itself, leading me to suspect that the database is at least partially responsible for the poor performance.
Currently I'm using JBoss for the back-end (using a Hibernate / JDBC layer to connect to the database), but I only have source access to some of the code.
I've found Elvyx, but this project seems to have been abandoned in 2008. Is there a newer JDBC profiler available - what's the current 'de facto' standard for profiling a database in a distributed app?
Alternatively, can anyone suggest a better / alternative approach?
Try using YourKit, it supports a reasonable degree of JDBC profiling:
You can view executed SQL after you capture a CPU snapshot.
You can also enable JDBC probes and view multiple things live, such as timings, stack traces, threads, SQL statements and many more, see attached screen shot from my colleague's computer (looks like you'll need to open this image in another browser tab/window to see it full size):
Don't really want this to sound as an ad for YourKit, but get yourself a trial license and give it a go.
I too would recommend AppDynamics. The 'Lite' version was more than adequate for my purposes.
Our Java EE application runs within JBoss and we knew we had performance bottlenecks in certain areas. By quickly and easily (and I do mean easily) installing and spinning up AppDynamics, then running some load through the application, we were able to see straight away exactly where our performance hits were located. On the clean and concise dashboard we were able to drill right down the stack to see which class needed some improvement.
Highly recommended. Definitely check it out. I heat the 'Pro' version is even better.
If you are trying to hunt down (or at least confirm) issues related to a slow database, IMO using the profiling tools provided by the database would be a good starting point.
We had done something along these lines previously by profiling JDBC calls (noting the timings) and comparing them against the time required to execute the same query "on" the database itself. This gave a pretty good idea of how much time was exactly spent by the JDBC in making the db call and getting back the result.
dynaTrace supports SQL call introspection and measures how long each sql call took. The field is called application performance management in general.
Is there a particular Use case which you feel is slow or Is it in general that you feel DB responsiveness is slow.
In case its a use case, I would suggest go for tools like AppDynamics or GlassBox.
In case its in general, Starting from DB is a better approach.
I am assuming you would have already done the analysis at distributed applications side regarding the connection metrics and at DB server OS side regarding the socket opens and IO permissible.
Arcturus Applicare does support JDBC profiling on JBoss (and other Java app servers). You can view all SQLs with min, max, avg stats aggregated across all servers on you env or on individual servers.
With full profiling enabled, you will be able to see the execution trace for each and every request/transaction processed by the server including SQLs with execution parameters. Making it pretty easy to detect expensive SQLs and where exactly they are been executed.
I am developing a web application with php that needs to synchronize a local mysql database that a java desktop version of the web application is interacting with. At the same time i also need the local db to synchronize with the remote db. How do i do this without using other software like MySQL Compare. I will really appreciate the help. Thanx guys.
You clearly have a significant architecture issue. It needs to be planned very well. Two-way replication clearly isn't going to work unless you have thought it out very carefully and understand how to do conflict resolution and what impact that will have on your application. In particular, you can forget using AUTO_INCREMENT.
For one-way replication, you can use mk-table-sync, or use mysql replication in some way (there are a variety of possiblities).
You can also run another mysql instance on the server, use mk-table-sync to periodically synchronise it locally, and use mysql replication on that. This has some benefits, particularly if there are some tables you don't want to replicate.
You really need to think about how it's going to work, if you plan to do two-way synchronisation. It is possible that you may end up writing custom code to do it, as the conflict resolution mechanism may mandate it.