The growth of Blue-Chase DBA (5): No talking about business, annoying application system

Statement ***************************************

Personal growth record on Oracle Road, with blue self-metaphor. Share the growing emotions, horizons and technology changes and growth.

Sensitive information is replaced in English and will not reveal any corporate secrets, purely for technology sharing.

Creation is inspired by self-reflection and record. If you can have a little help or sympathy for the beginning of the library friends, gratified unceasingly.

Welcome to make bricks, such as the technical details of the error, please leave a message or e-mail ([email protected]) indicated. greatly appreciated.

***********************************************************************************

If you want to jump high, you need to learn to squat down first.

--Dark blue

Preface ***************************************

This is a personal record of the growth of the notes, since the step into the blue Sea of Oracle, inevitably all the way to the rush and constant test. By this story and friends to share the blue growth process.

I do not know when the blue has a kind of can't say the obsession. Obsessed with its breadth, obsession with its depth, obsessed with being near but unreachable.

And it's unclear from when, staring at Oracle's red glare, illuminating a light in front of you. Unknown and confused at their feet at the beginning of a little bit of life of enrichment and youth feedback.

Step forward on the path to the DBA's dream.

***********************************************************************************

2014 Beijing

Two days of running around to move the problem to research and development. Have to spit groove, link, the system still need to continue to build and intact. The business layer, the field layer, the implementation layer different processing situation, subsequently produced the different field question. The appearance of this problem seems very easy, but let the implementation of staff costs a half-day time, the pain is painful to let people physically and mentally exhausted. Around for a long time, is not some sound dizzy, next, I would like to review the business layer has a close relationship with the implementation of the deployment.

Scenario rendition: Deploy the Migration project for completion. Migrate the original application and database together to the new server. Deploy the client, the environment is a 64-bit Win7 system (explain.) In the production environment, the application server, database server is separate, and this deployment as a scientific research project, the content is inconvenient to elaborate. Understand that all in one server can be in this.)

A application of Java development, B/s architecture. b, C and other applications of the client is B/s structure. But based on 32-bit system development. It is this simple technical detail that starts to trigger a continuous business problem.

In the main system a application again after the deployment is complete, seemingly everything is normal, in the background cost a little trouble, changed the password, and finally use Super Administrator user login.

However, when the task is considered complete. The problems of technical staff are now appearing. A maintenance page cannot be visited correctly, and a permission issue occurs. Continuous click Test, the business layer has emerging problems. A handler cannot be used. The surprising situation is that. There is no objection to this deployment.

Where did the problem arise? According to the hint step by step wrong. As there is no good deployment manual at hand, it is suggested that the problem is: one JDK is causing the inability to process.

Search, download, install, continue troubleshooting. Some features were found missing. At this time contact research and development, business script mail came. For the work of operations, some sweat, run scripts, problem solving. At this time a blank face to understand the business process and technology implementation of the relationship between whether there is no clear dividing line. To imagine, assuming that in the face of such a problem, through the technical aspects of the wrong, a bit of a fantasy, I am afraid, in addition to the development of a completely new out there will not be any correct solution, because this is the business needs. That's the problem with the business layer, it's that simple. The development has the business script, runs, realizes is to have some function table to create under, the Function Item Association. Permissions are given, and so on and so on. Problem solved. It is simple to say that the angle of thinking is the key, coordination, feedback sometimes more than the technology itself.

This is just a problem with the application system a leak. Not to mention annoying B, C, D application Systems. This can be said to be annoying. Client's program, access to the fault.

Once again, the developer is the one who thinks. continue to contact. The next step is to anticipate the effect. Good, email again. Replace the file and set it again. Are we done? This is a sad reminder. The business layer doesn't know what's going on. The program seems to be wrong. This is a serious problem, because in this series of business systems, there is a key "backbone" system (technical details of the inconvenience disclosed), can be understood as an upload release of the management platform, based on the main business system, maintain the consistency of all system information (there is no feeling a bit like the undo segment in Oracle. Maintain a consistent reading.

Haha, here is purely for the play talk).

Because this application deployment is not working properly, this series of migrations seems to be complete, but it is back to the starting point. This time, contact development again. The personnel in the field collapsed, and the researchers collapsed.

A couple of emails. No results are configured. Can't go on anymore.

Copy all the Tomcat logs, and this time we need to be in the field. It is reminiscent of a business problem previously due to a previous company. Project leader, implementation personnel, maintenance personnel, developers, party a all leaders, party a crowd of project division to the scene of the spectacular scene, Haha, again play talk ~ ~). Of course. The situation is still within manageable limits. There is still one day to adjust for the last business deployment. According to commonsense experience, such a client problem. After the development of the scene, according to the actual environment, adjust the corresponding package, configuration files, the problem will be resolved.

Around for a while, just hold the paragraph here.

Think back. The emergence of this problem, very much is not out of the technical.

Think about technology-related aspects, such as when a client connects to a database, it needs to configure TNS, listen. Middleware deployment, tuning. Data migration and so on, are not the solution to this problem. Problems leak in business applications. field system environment changes, different business documents adjustment, update on.

This is what is called the "business Need". Oracle technology also needs to be landed, and sometimes the idea of solving this problem may be higher than technology. The exploration of technology requires business support.

*************************************** not to be continued ***************************************

Welcome to visit: The Blog:http://blog.csdn.net/huangyanlong of Deep Blue

************************************************** ***************************************

The Blue Growth Kee series _20150820*************************************

original works. From the "Blue Blog" blog, Welcome to reprint, please be sure to indicate the source (http://blog.csdn.net/huangyanlong).

The growth of blue-chasing DBA (1): Rushing on the road. Advancing to Shandong

Blue Growth Kee-Chase DBA (2): Install! Installation. A long-lost memory, causing me another understanding of the DBA

The growth of Blue-Chase DBA (3): antique operation. Data import has been exported as a problem

The growth of Blue-Chase DBA (4): Recalling the youth, and then explore Oracle installation (Linux 10g, 11g)

The growth of Blue-Chase DBA (5): No talking about business, annoying application system

The growth of Blue-Chase DBA (6): Work and life: small technology. Big man

The growth of Blue-Chase DBA (7): Basic Command, foundation stone

The growth of Blue-chase DBA (8): Regain SP report. Review Oracle's Statspack experiment

The growth of Blue-Chase DBA (9): The national day is gradually going. Chasing DBAs. New plan, new departure

The growth of the Blue-Chase DBA (10): flying knives to defend themselves, not expertise: fiddling with middleware WebSphere

The growth of Blue-chase DBA (11): The ease of coming home, the dizzy wake up

The growth of Blue-chase DBA (12): Seven days seven harvested SQL

The growth of Blue-chase DBA (13): Coordinate hardware vendors. Six stories: what you see and feel "server, storage, switch ..."

The growth of Blue-chase DBA (14): An unforgettable "cloud" side, starting Hadoop deployment

Blue Growth Kee-Chase DBA (15): Think FTP is very "simple", who chengxiang twists

The growth of Blue-Chase DBA: The DBA also drank and was 捭阖

Blue Growth-chasing DBAs: sharing, or spending, learning to grow in the post-IoE era

The growth of Blue-chase DBA (18): A was cluster failure on a small machine. caused by the replacement of IP at one time

The growth of Blue-Chase DBA (19): The episode on the road: Touching "frame" and "software system"

******************************************************************************************************* ***********

The growth of Blue-Chase DBA (5): No talking about business, annoying application system